From - Sat Aug 14 12:54:57 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA27403
	for <slinkp@ulster.net>; Fri, 13 Aug 1999 13:57:29 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA07905 for linux-audio-dev-list; Fri, 13 Aug 1999 13:14:14 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA07902 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 13 Aug 1999 13:14:09 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m1iCCzi-000dxrC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Mon, 23 Sep 2019 03:18:26 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Mon, 23 Sep 2019 03:18:26 +0200 (CEST)
To: Dave Phillips <dlphilp@bright.net>
Cc: Guenter Geiger <geiger@epy.co.at>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Mix curiosity
In-Reply-To: <37B2280B.181ADCFC@bright.net>
References: <37B2280B.181ADCFC@bright.net>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <23944.7350.274980.320242@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 6b7c2310a4e432fbcfb0030d51b2d1a9

Dave Phillips writes:
 > Greetings:
 > 
 >   While revising the Mix docs I came across the significance of the
 > csound variable. Apparently on an SGI machine it's possible to trigger a
 > Csound compilation with realtime audio output, along with any other
 > material in the track(s). I tried it, after editing the mix.c code a
 > bit, and indeed the Csound session initiates. Of course, it dies because
 > it can't access the soundcard.
 > 
 >   So I wondered: Is it at all possible to make that work in Linux Mix ?
 > I loaded the esound daemon, but playback froze and output no audio
 > anyway. I'd like to be able to do this trick: any suggestions ?

 IMO It's not easy without changing csound sources.
 I don't see the usefulness of this feature either, as the result of
 the csound session won't be saved in the resulting mix.

 Guenter


From - Tue Jan 05 13:43:04 1999
Received: from mx03.erols.com ([207.172.3.243]) by mta4.mail.erols.net
          (InterMail v03.02.05 118 121 101) with ESMTP
          id <19990105090636.VNVT21016@mx03.erols.com>
          for <zarmzarm@mta.mail.erols.net>; Tue, 5 Jan 1999 04:06:36 -0500
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by mx03.erols.com (8.8.8-970530/8.8.5/MX-980323-gjp) with SMTP id EAA11730
	for <zarmzarm@erols.com>; Tue, 5 Jan 1999 04:06:36 -0500 (EST)
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id DAA06234 for linux-audio-dev-list; Tue, 5 Jan 1999 03:39:51 -0500
Received: from cs.tut.fi (varis.cs.tut.fi [130.230.4.2]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA06231 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 5 Jan 1999 03:39:47 -0500
Received: from kalalokki.cs.tut.fi (jams@kalalokki.cs.tut.fi [130.230.14.118])
	by cs.tut.fi (8.8.8/8.8.8) with ESMTP id KAA16350
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 5 Jan 1999 10:40:44 +0200 (EET)
Received: (from jams@localhost)
          by kalalokki.cs.tut.fi (8.8.5/8.8.4)
	  id KAA28204; Tue, 5 Jan 1999 10:40:21 +0200 (EET)
To: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] [ProAud] Audio for Linux? (fwd)
From: jams@cs.tut.fi (Jarno Seppanen)
Reply-To: jams@cs.tut.fi (Jarno Seppanen)
Comment: Redistribution via Microsoft Network prohibited
X-Url: http://www.modeemi.cs.tut.fi/~jams/
Date: 05 Jan 1999 10:40:21 +0200
Message-ID: <ruv4sq6dsei.fsf@kalalokki.cs.tut.fi>
Lines: 35
X-Mailer: Gnus v5.4.66/Emacs 19.31
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 0001
Content-Length: 1009

	Perhaps there are people on this list who can help?

------- Start of forwarded message -------
Message-Id: <199901041730.SAA04863@arctica.euronet.nl>
From: "Eelco Grimm" <eelco@contekst.nl>
To: "'Pro-Audio mailing list'" <pro-audio@pgm.com>
Subject: [ProAud] Audio for Linux?
Date: Mon, 4 Jan 1999 18:29:23 +0100
Reply-To: pro-audio@pgm.com

Dear listers,

In one of our upcoming issues I will be featuring an article about Linux. I very much
like to include a list of supported (semi) professional audio hardware cards and
multitracking / sequencing software if exists. I know Sonorus supports Linux, but I
figure they're not the only one...

Thanks for any tips.

Eelco Grimm
Editor of ProAudio+Visie, Holland

| If the human brain was so simple
| that we could understand it,
| we would be so simple
| that we couldn't
|
| Colin McGinn


===For info on Pro-Audio, including unsubscribing, see www.pgm.com/pro-audio===

------- End of forwarded message -------
-- 
-Jarno

From - Wed Jan 06 23:41:33 1999
Received: from mx03.erols.com ([207.172.3.243]) by mta3.erols.com
          (InterMail v03.02.05 118 121 101) with ESMTP
          id <19990106182158.LLPV10731@mx03.erols.com>
          for <zarmzarm@mta.mail.erols.net>; Wed, 6 Jan 1999 13:21:58 -0500
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210])
	by mx03.erols.com (8.8.8-970530/8.8.5/MX-980323-gjp) with ESMTP id NAA12858
	for <zarmzarm@erols.com>; Wed, 6 Jan 1999 13:21:56 -0500 (EST)
Received: from debian (dialup56-4-6.swipnet.se [130.244.56.198]) 
          by mb06.swip.net (8.8.8/8.8.8) with ESMTP 
          id TAA10314 for <zarmzarm@erols.com>; 
          Wed, 6 Jan 1999 19:21:53 +0100 (MET)
Received: from debian.mbox314.swipnet.se (really [127.0.0.1]) by debian
	via in.smtpd with esmtp (ident root using rfc1413)
	id <m0zxxZh-0017oYC@debian> (Debian Smail3.2.0.101)
	for <zarmzarm@erols.com>; Wed, 6 Jan 1999 19:20:57 +0100 (CET) 
Message-Id: <m0zxxZh-0017oYC@debian>
Date: Wed, 6 Jan 1999 19:20:51 +0100 (CET)
From: reine@mbox314.swipnet.se
Reply-To: reine@mbox314.swipnet.se
Subject: Re: MixW wave bug still there.
To: zarmzarm@erols.com
In-Reply-To: <36935114.5C1D@erols.com>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT
X-Mozilla-Status: 0011
Content-Length: 3351

On  6 Jan, Paul Winkler wrote:

Dear Paul,

Thank you for all your work.

Here is the wave header Im using.
I hope the small comments will be of some help to you.
I dont know if you are a C programmer but incase not
a long is four bytes long and a short is two bytes long.
The places you show me that has different data is
the variables I call length and data_length.

 
typedef struct {
   unsigned long main_id;          /* 'RIFF' : 1179011410 */
   unsigned long length;           /* File-lenght	*/
   unsigned long wave_id;          /* 'WAVE' : 1163280727	*/  
   unsigned long fmt_id;           /* 'fmt' :  544501094		*/
   unsigned long fmt_length;       /* length of fmt_chunk, 16 bits? */
   unsigned short format;          /* 1 for PCM code	*/
   unsigned short channels;        /* 1=MONO, 2=STEREO	*/
   unsigned long sampleRate; 
   unsigned long byte_per_second;
   unsigned short samplesize;      /* 1 or 2 bytes */
   unsigned short bit;             /* ?? 8,12,16 bit */
   unsigned long data_id;          /* 'data' : 1635017060	*/
   unsigned long data_length;      /*  sample count	*/
} WAV_HEADER;


In mixw the following is done:
First the header is created and written to disk.
The function is calles AFopenfd().
As the program doesn't know about the final length of the files
the length (file-length) and data_length (nr of samples) is
set to zero. 

When mixw closes the file (the function is called AFclosefile) it
writes the header again now with updated and correct
length and data_length.

It seems to me that this update is not done the same on our both
mashines. Here is what soundinfo says about a test.wav just done here: 

~/Ljud#sndinfo test.wav 
test.wav: WAVE, 28672 stereo samples
        WAVE soundfile
        srate 44100, stereo, 16 bit shorts, 0.65 seconds
        headersiz 44, datasiz 114688 (28672 sample frames)

>From the little i know about .wav format i guess that there is one
info about the total file-length and one about the sound that mixw uses,
and most of us i guess. If a file with text-info and several sounds
or loops where used i guess there would be a great difference
in the meaning of length and data_length. Now mixw only uses a very
small subest of the RIFF format. I only studied this as far as I was
able to make it work :).

My question is why is this update of the header not correctly done
on some computers but on others?

I have here a Debian 2.0 setup. Kernel version 2.0.35 compiled with 
gcc version 2.7.2.3. The same compiler as mixw uses. I compile it 
with lesstif (lesstif-0.87.0-linux-glibc2.tar.gz).

What do you use?
Have you used a precompiled version or have you compiled it locally?

Whatelse could be of importance ?

I have got one report that it works and one other (from the older pre
dec 1998 version) that is does not work.

Maybe I should do a kind of debug version an send to you
and you could send me the results back?
What do you say about big (about the size of mixw.tar.gz) emails?


Otherwise I'm writing an piece for the Helsingborg Symphony orchestra,
about 30 minutes of music. There is only one program I use in Windows
and that is Finale, to write my score. I cant make it work under
Linux, if you know anything about please tell me.


Bye for now

Reine 




From - Fri Jan 15 16:21:52 1999
Received: from mx06.erols.com ([207.172.3.248]) by mta3.erols.com
          (InterMail v03.02.05 118 121 101) with ESMTP
          id <19990115204924.TZO13319@mx06.erols.com>;
          Fri, 15 Jan 1999 15:49:24 -0500
Received: from marvin.jcu.cz (marvin.jcu.cz [160.217.1.3])
	by mx06.erols.com (8.8.8-970530/8.8.5/MX-980323-gjp) with ESMTP id PAA28446;
	Fri, 15 Jan 1999 15:49:21 -0500 (EST)
Received: (from petidomo@localhost)
	by marvin.jcu.cz (8.9.1a/8.9.1) id VAA09531;
	Fri, 15 Jan 1999 21:25:24 +0100
Received: from entry.jcu.cz (IDENT:perex@entry.jcu.cz [160.217.1.111])
	by marvin.jcu.cz (8.9.1a/8.9.1) with SMTP id VAA09527;
	Fri, 15 Jan 1999 21:25:21 +0100
Date: Fri, 15 Jan 1999 21:25:20 +0100 (CET)
From: Jaroslav Kysela <perex@jcu.cz>
To: Patanjali <patanjali@mindless.com>
cc: alsa-user@alsa.jcu.cz
Subject: Re: full duplex programming
In-Reply-To: <010101be0239$74fd47a0$7c5036ca@pentium200>
Message-ID: <Pine.LNX.3.96.990115212336.20470A-100000@entry.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: alsa-user@alsa.jcu.cz
Sender: alsa-user-owner@alsa.jcu.cz
Precedence: list
X-Mozilla-Status: 0011
Content-Length: 1024

On Wed, 28 Oct 1998, Patanjali wrote:

> I would like to do a program 
> which reads, processes and writes
> suond using the full duplex capabilities of 
> the SB 16 and my ALSA driver.
> 
> how do i go about it ?
> currently i am doing something like :
> while(1)
> {
>     read some bytes into buffer;
>     write same bytes into buffer; // write only number of bytes actually read
> }
> 
> this code doesn't seem to be giving me the right results.
> the sound input doesn't always appear at the output,
> also the quality is very bad.
> 
> is there any demo prog which does the above ?

Yes, look to alsa-lib/test/latency.c... Your algorithm is bad (playback
underruns)...

							Jaroslav

-----
Jaroslav Kysela <perex@jcu.cz>
Academic Computer Centre, University of South Bohemia
Branisovska 31, C. Budejovice, CZ-370 05 Czech Republic

------
To unsubscribe from <alsa-user@alsa.jcu.cz> mailing list send message
'unsubscribe' in the body of message to <alsa-user-request@alsa.jcu.cz>.

From - Thu Jan 28 00:35:29 1999
Received: from mx02.erols.com ([207.172.3.242]) by mta1.erols.com
          (InterMail v03.02.05 118 121 101) with ESMTP
          id <19990125214005.DEW9755@mx02.erols.com>
          for <zarmzarm@mta.mail.erols.net>;
          Mon, 25 Jan 1999 16:40:06 -0500
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by mx02.erols.com (8.8.8-970530/8.8.5/MX-980323-gjp) with SMTP id QAA09258
	for <zarmzarm@erols.com>; Mon, 25 Jan 1999 16:40:02 -0500 (EST)
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA19518 for linux-audio-dev-list; Mon, 25 Jan 1999 16:26:53 -0500
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA19515 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 25 Jan 1999 16:26:46 -0500
Received: from localhost (user: 'kouhia', uid#241) by nic.funet.fi id <15767-2280>; Mon, 25 Jan 1999 18:54:51 +0200
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: audiotechque@fmc-container.mach.uni-karlsruhe.de,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Reverbs
Message-Id: <19990125165451Z15767-2280+3258@nic.funet.fi>
Date: 	Mon, 25 Jan 1999 18:54:51 +0200
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 0001
Content-Length: 1821

I have written a reverb: look at "http://www.funet.fi/~kouhia/reverb/"
for samples but not for code.

It looks like a set of N delaylines with feedbacks to each other
is patented. Or is it? That was claimed by Jean-Marc Jot owning
a patent for a reverb. My reverb doesn't use the optimization method
described in Jot's papers.

Is simple delayline patented? Can we have any delay at all?
What combinations of several delaylines are not patented?
If I don't make a full feedback from delay line to delay line
but leave some out, the Jot may claim I just have full feedback
matrix with 0 entries.

What if I make a new, a different invent related to full feedback
system, then should I still pay to Jot? Or would my patent be safe?

Sonic Flow uses some network. Is that patented? What if I convert
that to matrix form and get combinations of several full feedback
matrix forms? Then patent apply to it?

What delay networks were used before 1991? I guess I could use those
even not optimized by Jot's method. I could use a different method to
optimize it and be safe. Right? Or is the optimum situation patented
as well -- i.e, the mathematical rules on that situation?

Now I make the matrix differently than Jot. It gives pleasant reverb
but perhaps not optimal. I plan to analyze the system further if
I can use the full feedback system in my "invent".

Is the rule that "distinct delay lines should have prime/relatively prime
lengths" patented?

What about a system where I have one delay line with multiple outputs
along the delay line, all feedback to delay input? To different inputs
along the delay line?

Note that a wave display with edit operations is also patented, making
a plenty of free software illegal. Where is the line of using patented
ideas?

Yours,

Juhana

From - Thu Jan 28 00:35:34 1999
Received: from mx06.erols.com ([207.172.3.248]) by mta1.erols.com
          (InterMail v03.02.05 118 121 101) with ESMTP
          id <19990126123306.KPLX9755@mx06.erols.com>
          for <zarmzarm@mta.mail.erols.net>;
          Tue, 26 Jan 1999 07:33:06 -0500
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by mx06.erols.com (8.8.8-970530/8.8.5/MX-980323-gjp) with SMTP id HAA21776
	for <zarmzarm@erols.com>; Tue, 26 Jan 1999 07:33:04 -0500 (EST)
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id HAA25550 for linux-audio-dev-list; Tue, 26 Jan 1999 07:24:39 -0500
Received: from cs.tut.fi (varis.cs.tut.fi [130.230.4.2]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA25547 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Jan 1999 07:24:35 -0500
Received: from kalalokki.cs.tut.fi (jams@kalalokki.cs.tut.fi [130.230.14.118])
	by cs.tut.fi (8.8.8/8.8.8) with ESMTP id OAA27705
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Jan 1999 14:24:30 +0200 (EET)
Received: (from jams@localhost)
          by kalalokki.cs.tut.fi (8.8.5/8.8.4)
	  id OAA01713; Tue, 26 Jan 1999 14:24:29 +0200 (EET)
To: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Call for volunteers: cross-platform audio i/o library
From: jams@cs.tut.fi (Jarno Seppanen)
Reply-To: jams@cs.tut.fi (Jarno Seppanen)
X-Url: http://www.modeemi.cs.tut.fi/~jams/
Date: 26 Jan 1999 14:24:29 +0200
Message-ID: <ruv1zkite6a.fsf@kalalokki.cs.tut.fi>
Lines: 34
X-Mailer: Gnus v5.4.66/Emacs 19.31
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 0001
Content-Length: 1014


------- Start of forwarded message -------
Date: Tue, 26 Jan 1999 04:04:25 -0800
Message-Id: <006401be4923$02da5a60$10cd38cb@RossBencina>
Reply-To: music-dsp@shoko.calarts.edu
From: "Ross Bencina" <rossb@audiomulch.com>
To: Multiple recipients of list <music-dsp@shoko.calarts.edu>
Subject: Call for volunteers: cross-platform audio i/o library

"An Open Source Portable Real-Time Audio I/O Library"

The goal is to develop an open source, cross-platform C language, real-time
streaming audio i/o library to be used in the implementation of software
synthesis and signal processing systems.

We are calling for volunteers to contibute to the development of the library
on each platform.

More details and a draft of the proposed api header file are available at:

http://www.audiomulch.com/portaudio/

Please forward this message to any forums to which it may be of interest.

Best Regards,

Ross Bencina
rossb@audiomulch.com



------- End of forwarded message -------
-- 
-Jarno

From - Thu Jan 28 00:35:35 1999
Received: from mx04.erols.com ([207.172.3.244]) by mta4.mail.erols.net
          (InterMail v03.02.05 118 121 101) with ESMTP
          id <19990126132341.BIEH21016@mx04.erols.com>
          for <zarmzarm@mta.mail.erols.net>;
          Tue, 26 Jan 1999 08:23:41 -0500
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by mx04.erols.com (8.8.8-970530/8.8.5/MX-980323-gjp) with SMTP id IAA25928
	for <zarmzarm@erols.com>; Tue, 26 Jan 1999 08:23:40 -0500 (EST)
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA25614 for linux-audio-dev-list; Tue, 26 Jan 1999 08:14:51 -0500
Received: from cs.tut.fi (varis.cs.tut.fi [130.230.4.2]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA25611 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Jan 1999 08:14:48 -0500
Received: from kalalokki.cs.tut.fi (jams@kalalokki.cs.tut.fi [130.230.14.118])
	by cs.tut.fi (8.8.8/8.8.8) with ESMTP id PAA01864;
	Tue, 26 Jan 1999 15:14:42 +0200 (EET)
Received: (from jams@localhost)
          by kalalokki.cs.tut.fi (8.8.5/8.8.4)
	  id PAA01836; Tue, 26 Jan 1999 15:14:42 +0200 (EET)
To: Audiotechque <audiotechque@fmc-container.mach.uni-karlsruhe.de>
Cc: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Modular audio
From: jams@cs.tut.fi (Jarno Seppanen)
Reply-To: jams@cs.tut.fi (Jarno Seppanen)
X-Url: http://www.modeemi.cs.tut.fi/~jams/
Date: 26 Jan 1999 15:14:41 +0200
Message-ID: <ruvzp76rxa6.fsf@kalalokki.cs.tut.fi>
Lines: 100
X-Mailer: Gnus v5.4.66/Emacs 19.31
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 0001
Content-Length: 5217

	Hello!  As I'm about to spend two weeks abroad, I'll post some
thoughts and answers to previous topics (on the Audiotechque list).
	
	I personally have been speculating about the possibility to have a
"streaming" or "flowing" functionality in the operating system, kinda like
what the BeOS Media Kit has.  At this level, audio inputs and outputs and
software would be depicted with blocks and wires.

	For example, every line out channel of a soundcard would be a consumer
block and e.g. the microphone input would be a producer block.  The software
running on the computer would plug to these blocks as needed.  Some filter
application could be seen as just another block on the "audio desktop" and
could be wired to between the microphone and the line out.  A software synth
would be a producer block and could be wired either directly to the audio
outputs or via an arbitrary number of filter blocks.

	EsounD (and SGI libaudio) implement real-time mixing of outgoing audio
streams.  Now this would be a mere adder block, placed just before the "line
out" block.  How would this sound to you?  Comments?  This is exactly what the
BeOS has currently; how would it be if Linux had it also?

         ------------------------
           An Audio Application        - an audio editor, patchbay, etc.
         ------------------------
 - - - - - - - - - - - - - - - - - - - - - -  "above driver-level" interface
       ---------------------------
         Flowing/streaming layer       - e.g. BeOS, Sonic Flow, Sig++, etc.
       ---------------------------
       ----------------------------
         Portable sound I/O layer      - PSL, EsounD, what?
       ----------------------------
 - - - - - - - - - - - - - - - - - - - - - -  kernel interface
 -------------- ------------- ------------ ---------
   Linux/ALSA     Linux/OSS     SGI IRIX     SunOs
 -------------- ------------- ------------ ---------
 analog, digital, multichannel etc. physical audio interfaces

Stefan Westerfeld <stefan@space.twc.de> writes:

> As to the flow system aRts currently uses, it doesn't do blockwise
> calculations. (Singe sample - which is of course slow, but correct).

	Correct calculations can be done using frames as well; samplewise
calculations are just frames with a length of 1. :-)

> I would consider it a restriction if you have fixed size blocks, because
> they don't allow you to do real short feedback loops. I'd rather have
> something like flexible size blocks, which autoadapt on the fly to have
> the right size.

	But this would add a lot of complexity and buffering in order to split
and join different-length frames, right?  (BTW, I prefer to use the term
"frame" for a short bit of a signal and "block" for a signal processing
algorithm).  If there is a need for short feedbacks, the global frame duration
should be shortened.

> Besides that, it might be a great idea to fit Sonic Flow as flow system
> into aRts (inventing new flexible blocksize scheduling), and perhaps to
> use PSL as sound library. This would really avoid duplicated (and in-
> compatible) work, since aRts has the Flow GUI builder already.

	Yes, I have been imagining about having one core dataflow library used
by multiple applications.  I would like to co-operate with you in Arts, within
the very small time window I have.  I also think that it is important to
separate the GUI from the workings of the dataflow system with a well-defined
API.

Andrew Clausen <clausen@alphalink.com.au> writes:

> Yep.  That's what was going through my mind.  I was originally thinking Esound, but
> everyone told me it wasn't a good idea, because its slow (its meant for TCP/IP isn't
> it?).  So I wrote PSL.  I only have access to ALSA and OSS.  When I went back to

	But EsounD is currently being included in Gnome and is being actively
(?) developed and this makes it a better idea?  I think it would be optimal if
we could join all these various small projects into an unified framework, see
e.g. the diagram on the top of this mail.

> So this is a problem.  Esound doesn't seem to be much better - it supports other
> systems, but they're untested.  Actually, I think the esd should depend on PSL or even
> Sonic Flow for portable I/O.  It doesn't seem right to have the server directly
> talking to the kernel.

	In order to get things right, there should be a well-defined API
between the different layers.  We want higher-level functionality (right?),
but we don't want the higher-level functions to flip bits directly in the
soundcard (right?) but via device drivers etc.

	Joel Dinolt: have you had any advances with the C language API for
Sonic Flow?  Are you still planning to investigate on the matter?  How about
the GUILE support?

	Speaking for myself, I remember saying that I would have the support
for hierarchical networks ready in a few days.  Well, now the time estimate
has been multiplied by pi and rounded up to the nearest multiple of ten, and
there's still no results.  After coding two days I noticed there was a flaw in
the design and had to start all over.  I'll get back to the subject after 2
weeks.
-- 
-Jarno

From - Thu Jan 28 00:35:36 1999
Received: from mx01.erols.com ([207.172.3.241]) by mta1.erols.com
          (InterMail v03.02.05 118 121 101) with ESMTP
          id <19990126180928.QBSS9755@mx01.erols.com>
          for <zarmzarm@mta.mail.erols.net>;
          Tue, 26 Jan 1999 13:09:29 -0500
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by mx01.erols.com (8.8.8-970530/8.8.5/MX-980323-gjp) with SMTP id NAA24365
	for <zarmzarm@erols.com>; Tue, 26 Jan 1999 13:09:23 -0500 (EST)
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA26849 for linux-audio-dev-list; Tue, 26 Jan 1999 12:47:38 -0500
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA26846 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Jan 1999 12:47:34 -0500
Received: from localhost (user: 'kouhia', uid#241) by nic.funet.fi id <7059-2277>; Tue, 26 Jan 1999 19:46:47 +0200
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: audiotechque@fmc-container.mach.uni-karlsruhe.de
CC: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <ruvzp76rxa6.fsf@kalalokki.cs.tut.fi> (jams@cs.tut.fi)
Subject: [linux-audio-dev] Re: [atech] Modular audio
Message-Id: <19990126174652Z7059-2277+3475@nic.funet.fi>
Date: 	Tue, 26 Jan 1999 19:46:47 +0200
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 0001
Content-Length: 2463

>From:	jams@cs.tut.fi (Jarno Seppanen)
>
>> I would consider it a restriction if you have fixed size blocks, because
>> they don't allow you to do real short feedback loops. I'd rather have
>> something like flexible size blocks, which autoadapt on the fly to have
>> the right size.
>
>	But this would add a lot of complexity and buffering in order to split
>and join different-length frames, right?
[ ... ]
>If there is a need for short feedbacks, the global frame duration
>should be shortened.

No. Flexible frame size is the way to go. But then the network must
be analysed before a run. For example, if a loop containing many blocks
wants an 1 sample delay, then the frame sizes of each block in the loop
must be adjusted to 1 sample. We need to find loops and there must
already be some efficient method for that available.

Frame sizes of a module and its blocks depends on frame sizes of other
modules if we really want to be precise.

Things gets complicated when time is considered: frame sizes may change
if an effect module is removed on the fly. The change would be toward
faster computations and it would not be a good idea to not alter the
frame sizes. Adding a module may change the frame sizes toward slower
computations.

Each block would have a control rate, maximum allowable delay between its
output and input if in a loop. To consider time, each block would have
a time-sequence of these values. There is no a need to set these values
and sequences -- the system then would just be an ordinary flow network.
Only a partial network (such as some time-critical section) could have
these values and sequences. Those values and sequences could inherit
to children modules/blocks on the fly. If wanted, there is no need to
readjust anything on the fly -- there can be compromises.

In an audio software we have two cases:
 -we know the mixer sequence before playing and we can compute everything
before execution;
 -we don't know the mixer sequence completely and we may make quick
computations everytime we add and/or delete an instrument from the
system.

>> (inventing new flexible blocksize scheduling)

I would like to discuss about various ideas. I try to find out my paper
notes on the above system because there still must be more.

There was some flexible flow scheduling method mentioned among OMT people.
It was written by Stefan of Arts (ex-KSynth). How it works?

Yours,

Juhana

From - Thu Jan 28 00:35:42 1999
Received: from mx05.erols.com ([207.172.3.245]) by mta4.mail.erols.net
          (InterMail v03.02.05 118 121 101) with ESMTP
          id <19990127060711.QMMK21016@mx05.erols.com>
          for <zarmzarm@mta.mail.erols.net>;
          Wed, 27 Jan 1999 01:07:11 -0500
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by mx05.erols.com (8.8.8-970530/8.8.5/MX-980323-gjp) with SMTP id BAA19551
	for <zarmzarm@erols.com>; Wed, 27 Jan 1999 01:07:11 -0500 (EST)
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA28617 for linux-audio-dev-list; Wed, 27 Jan 1999 00:56:45 -0500
Received: from mail.alphalink.com.au (mail.alphalink.com.au [203.24.205.7]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA28614 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Jan 1999 00:56:29 -0500
Received: from alphalink.com.au (IDENT:andrew@ppp14-7-Melbourne.alphalink.com.au [202.161.96.205]) by mail.alphalink.com.au (8.9.2/8.6.9) with ESMTP id QAA17671; Wed, 27 Jan 1999 16:56:28 +1100 (EST)
Message-ID: <36AEA9B4.53B63FB3@alphalink.com.au>
Date: Wed, 27 Jan 1999 16:52:53 +1100
From: Andrew Clausen <clausen@alphalink.com.au>
X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.35 i586)
MIME-Version: 1.0
To: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>,
        rossb@audiomulch.com
Subject: Re: [linux-audio-dev] Call for volunteers: cross-platform audio i/o library
References: <ruv1zkite6a.fsf@kalalokki.cs.tut.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 0011
Content-Length: 362

Hi,

I've started on a cross-platform audio library, called PSL: Portable Sound
Library.  It currently supports OSS and ALSA.  You can get it at
www.alphalink.com.au/~clausen/atech/psl.tar.gz

It isn't too impresive, but perhaps worth a look...
It does automatic conversions, and splitting/joining of audio streams (all
customisable).

Andrew Clausen

From - Thu Jan 28 00:35:45 1999
Received: from mx03.erols.com ([207.172.3.243]) by mta2.erols.com
          (InterMail v03.02.07.03 118-128) with ESMTP
          id <19990127195136.TSY16519@mx03.erols.com>
          for <zarmzarm@mta.mail.erols.net>;
          Wed, 27 Jan 1999 14:51:36 -0500
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by mx03.erols.com (8.8.8-970530/8.8.5/MX-980323-gjp) with SMTP id OAA26507
	for <zarmzarm@erols.com>; Wed, 27 Jan 1999 14:51:36 -0500 (EST)
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA00530 for linux-audio-dev-list; Wed, 27 Jan 1999 14:33:34 -0500
Received: from sasami.anime.net (anime.net [205.139.105.150]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA00527 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Jan 1999 14:33:29 -0500
Received: from localhost (goemon@localhost)
	by sasami.anime.net (8.8.8/8.8.8) with SMTP id LAA04641;
	Wed, 27 Jan 1999 11:32:58 -0800
Date: Wed, 27 Jan 1999 11:32:58 -0800 (PST)
From: Dan Hollis <goemon@sasami.anime.net>
To: Benjamin GOLINVAUX <golinvaux@benjamin.net>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] audio chips datasheets
In-Reply-To: <013a01be4a0a$89fadc80$47010180@pcbg>
Message-ID: <Pine.LNX.3.96.990127113226.4578B-100000@sasami.anime.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 0011
Content-Length: 437

On Wed, 27 Jan 1999, Benjamin GOLINVAUX wrote:
> We'll then have a quick overview of companies reluctant to share programming
> specs for their card and which indirectly support M$ and disregard Linux.
> So, do you know any good audio chipsets and datasheets available (or not) ?

I started such a list (of all hardware, not just soundcards) a long
time ago. You can see it here:

http://www.anime.net/~goemon/hardware/

-Dan

From - Sun Feb 07 21:27:24 1999
Received: from mx06.erols.com ([207.172.3.248]) by mta3.erols.com
          (InterMail v03.02.05 118 121 101) with ESMTP
          id <19990206124813.EZFX424@mx06.erols.com>
          for <zarmzarm@mta.mail.erols.net>; Sat, 6 Feb 1999 07:48:13 -0500
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by mx06.erols.com (8.8.8-970530/8.8.5/MX-980323-gjp) with SMTP id HAA01926
	for <zarmzarm@erols.com>; Sat, 6 Feb 1999 07:48:12 -0500 (EST)
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id HAA06369 for linux-audio-dev-list; Sat, 6 Feb 1999 07:35:40 -0500
Received: from pefletti.saunalahti.fi (mail.sci.fi [195.74.0.53]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA06366 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 6 Feb 1999 07:35:31 -0500
Received: from sci.fi (MCCCXL.dyn.saunalahti.fi [195.197.4.140])
	by pefletti.saunalahti.fi (8.9.1/8.9.1) with ESMTP id OAA04668;
	Sat, 6 Feb 1999 14:36:23 +0200 (EET)
Message-ID: <36BC36E8.17A0F9AB@sci.fi>
Date: Sat, 06 Feb 1999 14:34:49 +0200
From: Matti Koskinen <mjkoskin@sci.fi>
X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.35 i586)
MIME-Version: 1.0
To: LAD <linux-audio-dev@ginette.musique.umontreal.ca>
CC: cmdist@ccrma.Stanford.EDU
Subject: [linux-audio-dev] denoiser series continues...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 0001
Content-Length: 532

hello all

	got a new denoiser working quite well, if i may say so.
	it has much less impact on audio than anoi. it uses same
	kind of approach as anoi.ins, filtering and fft, but
	also thing like getting "noiseprint" as in sound forge.
	sound forge's noise reduction made me think of denoi
	but denoi has nothing else to do with sound forge.
	(just a legal announcement)

	you can get denoi from http://www.sci.fi/~mjkoskin/denoi.tar.gz
	(270k) 

	bug reports, comments, suggestions welcome!

-matti
mjkoskin@sci.fi

From - Sat Mar 20 18:57:30 1999
Received: from mx01.erols.com ([207.172.3.241]) by mta4.mail.erols.net
          (InterMail v03.02.05 118 121 101) with ESMTP
          id <19990318071055.LHDQ27305@mx01.erols.com>
          for <zarmzarm@mta.mail.erols.net>;
          Thu, 18 Mar 1999 02:10:55 -0500
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by mx01.erols.com (8.8.8-970530/8.8.5/MX-980323-gjp) with SMTP id CAA14814
	for <zarmzarm@erols.com>; Thu, 18 Mar 1999 02:10:54 -0500 (EST)
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id BAA07518 for linux-audio-dev-list; Thu, 18 Mar 1999 01:58:46 -0500
Received: from cs.tut.fi (varis.cs.tut.fi [130.230.4.2]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA07515 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 18 Mar 1999 01:58:43 -0500
Received: from kalalokki.cs.tut.fi (jams@kalalokki.cs.tut.fi [130.230.14.118])
	by cs.tut.fi (8.8.8/8.8.8) with ESMTP id IAA24857;
	Thu, 18 Mar 1999 08:59:19 +0200 (EET)
Received: (from jams@localhost)
          by kalalokki.cs.tut.fi (8.8.5/8.8.4)
	  id IAA07108; Thu, 18 Mar 1999 08:59:17 +0200 (EET)
To: audiotechque@fmc-container.mach.uni-karlsruhe.de
Cc: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Re: RFC: real-time design.
References: <ruvvhg3jajt.fsf@kalalokki.cs.tut.fi> <36EE2DC9.F299F9B0@alphalink.com.au>
From: jams@cs.tut.fi (Jarno Seppanen)
Reply-To: jams@cs.tut.fi (Jarno Seppanen)
X-Url: http://www.modeemi.cs.tut.fi/~jams/
Date: 18 Mar 1999 08:59:17 +0200
In-Reply-To: Andrew Clausen's message of "Tue, 16 Mar 1999 21:09:13 +1100"
Message-ID: <ruvbthrtha2.fsf@kalalokki.cs.tut.fi>
Lines: 57
X-Mailer: Gnus v5.4.66/Emacs 19.31
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001

	Hi,

	Since there doesn't seem to be very many answers, I would like to ask
another question:

	What kind of a design you guys use in your real-time Linux sound
	applications?

	Then, some fine-tuning:

Andrew Clausen <clausen@alphalink.com.au> writes:


> > // Get the current (system etc.) time in microseconds.
> >
> > unsigned int SF_Timer::get_time ();
> 
> Yep.  What do we do about over-flows?  Does get_time() return how long sincethe timer was

	Oops, you're right.  32 bits isn't enough.  Perhaps we should use
POSIX timers, see clock_gettime() or timer_create().  There's a time_t for
seconds and a long for nano(!)seconds.

> Looks pretty good to me :-)  I've been thinking about interruption from the kernel.  Two
> main
> times this occurs:
> 
> 1)  Context switches.  This can be avoid by calling:
> priority_level_struct.sched_priority = <something greater than 0>;
> sched_setsched(pid, SCHED_FIFO, &priority_level_struct);
> 
> 2)  Memory swapping.  This can be done by page locking:
> mlock (ptr, size);

	This is good.  Only I think that the following POSIX functions should
be used: sched_setparam() or sched_setscheduler().  The mlock() is fine.
These functions can all be found on SGI IRIX 6.5, Sun Solaris and Digital UNIX
machines.

	There's one more thing to take into account:

3)  File I/O.  This should be asyncronous, i.e. non-blocking.

> Both require root access.  If Sonic Flow were to use these, there would have to be a lot of
> 
> security features.  Eg, a block could intentionally lock up the system.  The sched_setsched

	Would it be possible to release the root privileges after the call to
these functions?

	There's some discussion on priorities on the IRIX man pages.  Namely,
it is said that digital media applications need low latency response times
from the operating system and that changing interrupt thread behavior is
undesirable, i.e. that priority range 110...199 should be used.

-- 
-Jarno

From - Sat Mar 20 18:57:37 1999
Received: from mx03.erols.com ([207.172.3.243]) by mta2.mail.erols.net
          (InterMail v03.02.07.03 118-128) with ESMTP
          id <19990318130325.UWKV12324@mx03.erols.com>
          for <zarmzarm@mta.mail.erols.net>;
          Thu, 18 Mar 1999 08:03:25 -0500
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by mx03.erols.com (8.8.8-970530/8.8.5/MX-980323-gjp) with SMTP id IAA24479
	for <zarmzarm@erols.com>; Thu, 18 Mar 1999 08:03:24 -0500 (EST)
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id HAA08253 for linux-audio-dev-list; Thu, 18 Mar 1999 07:41:21 -0500
Received: from vipunen.hut.fi (vipunen-a.hut.fi [130.233.249.7]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA08250 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 18 Mar 1999 07:41:16 -0500
Received: from raita.hut.fi (tilmonen@raita.hut.fi [130.233.248.52])
	by vipunen.hut.fi (8.9.2/8.9.1) with ESMTP id OAA335854
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 18 Mar 1999 14:41:48 +0200
Date: Thu, 18 Mar 1999 14:41:49 +0200 (EET)
From: Tommi Ilmonen <tilmonen@cc.hut.fi>
To: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: RFC: real-time design.
In-Reply-To: <ruvbthrtha2.fsf@kalalokki.cs.tut.fi>
Message-ID: <Pine.HPX.4.10.9903181431580.4848-100000@raita.hut.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011

> 
> > Both require root access.  If Sonic Flow were to use these, there would have to be a lot of
> > 
> > security features.  Eg, a block could intentionally lock up the system.  The sched_setsched
> 
> 	Would it be possible to release the root privileges after the call to
> these functions?
> 
> 	There's some discussion on priorities on the IRIX man pages.  Namely,
> it is said that digital media applications need low latency response times
> from the operating system and that changing interrupt thread behavior is
> undesirable, i.e. that priority range 110...199 should be used.

I had similar problems. I do not have root privileges on my machine and I
still need to get real-time priority.

I made a small priority control app (<200 lines) that can give priority to
my processes. That app is accessed via sudo so it has root privileges. 
My app calls the sudo'ed program automatically -> Now
my app never gets the root privileges, but it does get real-time priority.
It think this is relatively secure way to go.

I can put the small app to web, but it needs some improvements to be
really usefull general purpose priority controller (right now I am the
only person it will talk to....). Besides, it works properly only in IRIX
(it uses 'ps' for certain things and the ps output format depends on
platform....)

As long as the small app has no bugs this is pretty secure solution. The
worst I could do to harm system is crash it (with busy-looping program). 

Many IRIX media apps 1) start as root-privilege 2) get the resources
(priorities etc.) 3) drop the root provileges 4) Start executing the real
app. 

Tommi.

From - Sat Apr 17 03:07:49 1999
Received: from mx05.erols.com ([207.172.3.245]) by mta2.mail.erols.net
          (InterMail v03.02.07.03 118-128) with ESMTP
          id <19990416083643.QEQF12324@mx05.erols.com>
          for <zarmzarm@mta.mail.erols.net>;
          Fri, 16 Apr 1999 04:36:43 -0400
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by mx05.erols.com (8.8.8-970530/8.8.5/MX-980323-gjp) with SMTP id EAA14229
	for <zarmzarm@erols.com>; Fri, 16 Apr 1999 04:36:43 -0400 (EDT)
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id EAA25644 for linux-audio-dev-list; Fri, 16 Apr 1999 04:22:10 -0400
Received: from aus-e.mp.campuscwix.net (aus-e.mp.campuscwix.net [208.140.84.25]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA25641 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 16 Apr 1999 04:22:06 -0400
Received: from merlin (mike@s21-pm13.snaustel.campuscwix.net [207.49.121.170])
	by aus-e.mp.campuscwix.net (8.9.0/8.8.8) with SMTP id EAA18839;
	Fri, 16 Apr 1999 04:21:12 -0400 (EDT)
Date: Fri, 16 Apr 1999 04:21:12 -0400 (EDT)
Message-Id: <199904160821.EAA18839@aus-e.mp.campuscwix.net>
From: Mike Petersen <snoopy@cu.campus.mci.net>
To: dlphilp@bright.net
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] questions concerning Java 2 for Linux
In-Reply-To: <370C993A.D8CFAD8D@bright.net>
X-Mailer: XCmail 0.99.6 - with PGP support, PGP engine version 0.5
X-Mailerorigin: http://www.fsai.fh-trier.de/~schmitzj/Xclasses/XCmail/
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011

---Reply to mail from Dave Phillips about [linux-audio-dev] questions concerning Java 2 for Linux
 
>   I've had the Blackdown port of the JDK 1.2 installed for a while, but
> any time I try to run something under it I receive the following error:
> 
> Exception in thread "main" java.lang.UnsatisfiedLinkError:
> /mnt/hdc2/jdk1.2/jre/lib/i386/libfontmanager.so:
> libstdc++-libc6.0-1.so.2: cannot open shared object file: No such file
> or directory

Hello,

I have come across some replys in the blackdown list that that might
help...

>>>>>>>>
<QUOTE>


>  I have installed the Java1.2 on Redhat 5.2.
> Every time I try to run a Swing demo I get the message:
> 
> uncaught exception: java.lang.UnsatisfiedLinkError:
> /usr/local/jdk1.2/jre/lib/i386/libfontmanager.so:
> libstdc++-libc6.0-1.so.2: cannot open shared object file: No such
> file or
> directory java.lang.UnsatisfiedLinkError:
> /usr/local/jdk1.2/jre/lib/i386/libfontmanager.so:
> libstdc++-libc6.0-1.so.2: cannot open shared object file:
> 
> How do I find this odddly named file?
>     JDO
> 
> 
> 
> ----------------------------------------------------------------------
> To UNSUBSCRIBE, email to java-linux-request@java.blackdown.org
> with a subject of "unsubscribe". Trouble? Contact
listadm@java.blackdown.org
> 

(Linux with the JDK 1.2)
The JDK 1.2 port uses a strangely named stdc++ library. If you
are running on a non Debian Linux (like RedHat) you will need
to run these two commands as root after making sure that
/usr/local/lib is entered into your /etc/ld.so.conf file.

% g++ -shared -o /usr/local/lib/libstdc++-libc6.0-1.so.2 -lm
% ldconfig


</QUOTE>
<<<<<<<<<

There is evidently other variables which might require the use of
LD_PRELOAD as described in the README.linux



From - Sat Apr 17 03:07:50 1999
Received: from mx06.erols.com ([207.172.3.248]) by mta4.mail.erols.net
          (InterMail v03.02.05 118 121 101) with ESMTP
          id <19990416113321.XHXX14661@mx06.erols.com>
          for <zarmzarm@mta.mail.erols.net>;
          Fri, 16 Apr 1999 07:33:21 -0400
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by mx06.erols.com (8.8.8-970530/8.8.5/MX-980323-gjp) with SMTP id HAA28375
	for <zarmzarm@erols.com>; Fri, 16 Apr 1999 07:33:21 -0400 (EDT)
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id HAA25829 for linux-audio-dev-list; Fri, 16 Apr 1999 07:19:00 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA25826 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 16 Apr 1999 07:18:57 -0400
Received: from bright.net (find1-cs-5.dial.bright.net [209.143.26.6])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id HAA21753;
	Fri, 16 Apr 1999 07:18:34 -0400 (EDT)
Message-ID: <37172092.4DDC3227@bright.net>
Date: Fri, 16 Apr 1999 07:35:46 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i586)
MIME-Version: 1.0
To: Mike Petersen <snoopy@cu.campus.mci.net>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] questions concerning Java 2 for Linux
References: <199904160821.EAA18839@aus-e.mp.campuscwix.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011

Mike Petersen wrote:

> (Linux with the JDK 1.2)
> The JDK 1.2 port uses a strangely named stdc++ library. If you
> are running on a non Debian Linux (like RedHat) you will need
> to run these two commands as root after making sure that
> /usr/local/lib is entered into your /etc/ld.so.conf file.
> 
> % g++ -shared -o /usr/local/lib/libstdc++-libc6.0-1.so.2 -lm
> % ldconfig
> 
> </QUOTE>
> <<<<<<<<<
> 
> There is evidently other variables which might require the use of
> LD_PRELOAD as described in the README.linux

Well, what finally worked for me was a simple link:

ln -sf /usr/lib/libstdc++.so.2.9.0
/jdk1.2/jre/lib/i386/libstdc++-libc6.0-1.so.2

I've been able to load and run Schroeder (couldn't get it to run at all
under JDK 1.1.7) and Rocky (much better under JDK 1.2), but not Silence
or HPKComposer. I'm still working on them...

Thanks, Mike !

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Sat May  1 16:16:26 1999
Received: from mx02.erols.com ([207.172.3.242]) by mta1.mail.erols.net
          (InterMail v03.02.07.03 118-128) with ESMTP
          id <19990501200411.JVQB508@mx02.erols.com>
          for <zarmzarm@mta.mail.erols.net>; Sat, 1 May 1999 16:04:11 -0400
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by mx02.erols.com (8.8.8-970530/8.8.5/MX-980323-gjp) with SMTP id QAA04588
	for <zarmzarm@erols.com>; Sat, 1 May 1999 16:04:10 -0400 (EDT)
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA17129 for linux-audio-dev-list; Sat, 1 May 1999 15:40:29 -0400
Received: from ax-nicb.axnet.it (ax-nicb.axnet.it [194.184.60.149]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA17126 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 1 May 1999 15:40:24 -0400
Received: (from nicb@localhost)
	by ax-nicb.axnet.it (8.8.8/8.8.8) id TAA07227;
	Sat, 1 May 1999 19:40:01 +0200
Date: Sat, 1 May 1999 19:39:59 +0200 (ROM DST)
From: Nicola Bernardini <nicb@axnet.it>
To: Csound Linux/Unix Development Group <csound-unix-dev@ilogic.com.au>,
        Linux Audio Development Mailing list <linux-audio-dev@ginette.musique.umontreal.ca>
cc: "J.P. Fitch" <jpff@maths.bath.ac.uk>
Subject: [linux-audio-dev] [ANNOUNCE] unofficial linux csound 3.53.0.1d available
Message-ID: <Pine.LNX.4.10.9905011937560.190-100000@ax-nicb.axnet.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001


The unofficial 3.53.0.1d ('Venice - Salvatore Sciarrino' edition)
distribution of linux csound is available from the AIMI server

ftp://musart.dist.unige.it/pub/CSOUND/csound-3.53.0.1d-*.tar.gz

in binary form (dynamically linked), binary form w/o X11 support (dynamically
linked) and source form.

	*THIS IS NOT THE OFFICIAL DISTRIBUTION*

The official distribution can be found at
ftp://ftp.maths.bath.ac.uk/pub/dream/newest. The official 3.53 sources
are maintained by J.P.Fitch (jpff@maths.bath.ac.uk).

Together with Scott Lindroth we were able to cook up a set of patches
to accomodate compilation and linking on the LinuxPPC platform. It
should be host-dependent, so it should not break anything else ... :)
Also, some long-distance hacking with Dave Phillips helped establishing
the cause for MIDI delay (which should now be fixed forever).

Thanks to all.

Enjoy.

------------------------------------------------------------------------
Nicola Bernardini
E-mail: nicb@axnet.it
 
Re graphics: A picture is worth 10K words -- but only those to describe
the picture.  Hardly any sets of 10K words can be adequately described
with pictures.

From - Fri Jun 04 22:04:20 1999
Received: from mx06.erols.com ([207.172.3.248]) by mta3.mail.erols.net
          (InterMail v03.02.07.03 118-128) with ESMTP
          id <19990603202005.UPFO462@mx06.erols.com>
          for <zarmzarm@mta.mail.erols.net>; Thu, 3 Jun 1999 16:20:05 -0400
Received: from mailhost.pemail2.net (mailhost.pemail2.net [195.92.25.8])
	by mx06.erols.com (8.8.8-970530/8.8.5/MX-980323-gjp) with SMTP id QAA14226
	for <zarmzarm@erols.com>; Thu, 3 Jun 1999 16:20:04 -0400 (EDT)
Received: (qmail 10990 invoked by uid 1120); 3 Jun 1999 20:20:03 -0000
Message-ID: <19990603202003.10989.qmail@mailhost.pemail2.net>
From: Jeroen Asselman <jeroen.asselman@pmail.net>
Subject: Re:  Your soundcard wishlist
To: Paul Winkler <zarmzarm@erols.com>
Cc: jeroena@dds.nl
Date: Thu Jun 03 20:20:02 GMT 1999
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Mozilla-Status: 8013

Ouch, it seems not all messages seemed to be forwarded to me, I am terrible sorry I reply about 15 days later.

Cascading: When 2 of these soundcards are used, doubles the number of channels, or can have some extended 3d (not just left right, front back, also below and up etc...)

Dac: I am not quite sure what you mean with this...

subject: Your soundcard wishlist
Date: Sat, 15 May 1999 04:42:58 
From: Paul Winkler <zarmzarm@erols.com>
To: jeroen.asselman@pemail.net
CC: 


Hi,

I came across the nightingale page via a link on Dave Phillips' linux
audio site (www.bright.net/~dlphilp/).

One thing that is mentioned on your specifications page is the ability
to "cascade" cards. I'm not sure what you mean by this-- you seem to be
talking about MIDI channels-- but it put me in mind of an important
feature that is lacking from nearly all available soundcards: clock
synchronization for the ADC's and DAC's.

Many people buy two soundcards in the hopes of doing low-budget
multitrack recording (getting two input channels from each card). The
problem they encounter is that the sample rate clocks on the two cards
are not synchronized, so the audio from one card drifts out of time with
the audio from another card. Even a little bit of drift is disastrous
when you record anything more than a few seconds long. So when you buy
almost any soundcard, you are committing yourself to a non-expandable
two-channel system. That sucks.

So, as long as you're taking suggestions... please think about this! The
added production cost would probably be very small.

BTW, I know for a fact that many of the codecs used in soundcards (e.g.
many Crystal Semiconductor chips) do have the capability of running from
an external clock, but the soundcard manufacturers ignore this pin on
the codec, so you can't do anything with it. WHat a waste.

Good luck on your project... I hope to own one someday! Thanks for
supporting LInux (and Alsa).

--PW
-- 

-------------------   paul winkler   --------------------
slinkP arts: music, sound, illustration, web design, etc.

zarmzarm@erols.com      http://members.tripod.com/~slinkP
=========================================================
_______________________________________________________
The Web's BEST free email.......
Get your FREE account at http://www.pmail.net

My Pmail address is: 
Jeroen Asselman <jeroen.asselman@pmail.net>


From - Fri Jun 04 22:58:16 1999
X-Mozilla-Status: 0001
Message-ID: <37589242.41B4D4D6@hotmail.com>
Date: Fri, 04 Jun 1999 22:58:10 -0400
From: abby <abigoo@ulster.net>
X-Mailer: Mozilla 4.05 [en] (Win95; I)
MIME-Version: 1.0
To: Jeroen Asselman <jeroen.asselman@pmail.net>
Subject: Re: Your soundcard wishlist
References: <19990603202003.10989.qmail@mailhost.pemail2.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jeroen Asselman wrote:
> 
> Ouch, it seems not all messages seemed to be forwarded to me, I am terrible sorry I reply about 15 days later.
> 
> Cascading: When 2 of these soundcards are used, doubles the number of
> channels, or can have some extended 3d (not just left right, front
> back, also below and up etc...)

That is exactly what I was hoping for. Excellent! Just make sure they're
synchronized!

 
> Dac: I am not quite sure what you mean with this...

Digital-to-Analog-Converter, opposite of ADC
(Analog-to-Digital-Converter). Soundcard people don't seem to use these
terms much, instead they refer to CODECS which usually contain both
converters and maybe some other stuff (DSP's or whatever). But I started
learning about professional audio before I started learning about PCs
and Linux, so I still think in those terms.

--PW
zarmzarm@hotmail.com

From - Mon Jun 07 00:00:48 1999
Received: from deimos.worldonline.nl (deimos.worldonline.nl [195.241.48.136])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id OAA32526
	for <abigoo@ulster.net>; Sat, 5 Jun 1999 14:07:57 -0400
Received: from Jeroen.Thuis (vp179-15.worldonline.nl [195.241.179.15])
	by deimos.worldonline.nl (8.8.5/8.8.5) with ESMTP id UAA21519
	for <abigoo@ulster.net>; Sat, 5 Jun 1999 20:05:02 +0200 (MET DST)
Received: from pmail.net (localhost [127.0.0.1])
	by Jeroen.Thuis (8.9.3/8.9.3) with ESMTP id UAA01175
	for <abigoo@ulster.net>; Sat, 5 Jun 1999 20:05:00 +0200
Sender: jeroen@Jeroen.Thuis
Message-ID: <375966C9.53273A18@pmail.net>
Date: Sat, 05 Jun 1999 20:04:57 +0200
From: Jeroen Asselman <jeroen.asselman@pmail.net>
Organization: The Nightingale Project
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.9 i586)
X-Accept-Language: nl, en
MIME-Version: 1.0
To: abby <abigoo@ulster.net>
Subject: Re: Your soundcard wishlist
References: <19990603202003.10989.qmail@mailhost.pemail2.net> <37589242.41B4D4D6@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-UIDL: e3efdb58483665434ae301a7502bcaa5
X-Mozilla-Status: 8013

abby wrote:

> Jeroen Asselman wrote:
> >
> > Ouch, it seems not all messages seemed to be forwarded to me, I am terrible sorry I reply about 15 days later.
> >
> > Cascading: When 2 of these soundcards are used, doubles the number of
> > channels, or can have some extended 3d (not just left right, front
> > back, also below and up etc...)
>
> That is exactly what I was hoping for. Excellent! Just make sure they're
> synchronized!

I think that would be quite neccessary...

> > Dac: I am not quite sure what you mean with this...
>
> Digital-to-Analog-Converter, opposite of ADC
> (Analog-to-Digital-Converter). Soundcard people don't seem to use these
> terms much, instead they refer to CODECS which usually contain both
> converters and maybe some other stuff (DSP's or whatever). But I started
> learning about professional audio before I started learning about PCs
> and Linux, so I still think in those terms.

I know what an ADC and a ACD is ... (I don't think the soundcard would ever get finished if I don't know the terms
ADC and DAC and son on.),
My problem is, I don't see your problem with 2 ADC not going sync. When should this happen? I assume as soon as we
are converting the signal from analog to digital, however, I also assume your are thinking of more than 1 line in?

--
+--   Greetings, Jeroen            --+--  ICQ UIN : 4331855       --+
| E-mail: Jeroen.Asselman@pemail.net | etv.hshaarlem.nl/~jeroena    |
+-                                 --+--                           -+
  +--    Have a nice LinuX, currently running kernel 2.2.9      --+



From - Tue Jun 22 13:02:10 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA20979
	for <slinkp@ulster.net>; Tue, 22 Jun 1999 12:13:04 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA16834 for linux-audio-dev-list; Tue, 22 Jun 1999 11:02:31 -0400
Received: from braille.uwo.ca (speech.braille.uwo.ca [129.100.109.30]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA16831 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 22 Jun 1999 11:02:25 -0400
Received: from localhost (572 bytes) by braille.uwo.ca
	via sendmail with P:stdio/R:inet_hosts/T:smtp
	(sender: <kirk>) (ident <kirk> using unix)
	id <m10wS3D-0013oAC@braille.uwo.ca>
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 22 Jun 1999 11:01:27 -0400 (EDT)
	(Smail-3.2.0.102 1998-Aug-2 #2 built 1998-Oct-13)
Message-Id: <m10wS3D-0013oAC@braille.uwo.ca>
Date: Tue, 22 Jun 1999 11:01:27 -0400 (EDT)
From: Kirk Reiser <kirk@braille.uwo.ca>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] audio libraries
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: a029837e0626e49cfd9eefd1bbc178ff

Hi Folks:  There was a gentleman that posted an article here about a
library of audio routines he had written.  I thought I had kept the
article, but it appears not.  If anyone can remember any pointers to
his work, I'd like the reference.  I need to have some library
functions for opening and manipulating audio data for the awesome
project.  Thank you very much for any help you can lend me.

  Kirk

From - Tue Jun 22 21:50:22 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA25359
	for <slinkp@ulster.net>; Tue, 22 Jun 1999 16:38:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA19662 for linux-audio-dev-list; Tue, 22 Jun 1999 15:52:49 -0400
Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA19659 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 22 Jun 1999 15:52:42 -0400
Received: from hendrix (cartman99.zip.com.au [61.8.20.227])
	by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id FAA18366;
	Wed, 23 Jun 1999 05:47:48 +1000 (EST)
Message-ID: <376FE947.7518D3DB@zip.com.au>
Date: Wed, 23 Jun 1999 05:51:35 +1000
From: Erik de Castro Lopo <erikd@zip.com.au>
Organization: Eric Conspiracy Secret Labs
X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.2.9 i586)
MIME-Version: 1.0
To: Kirk Reiser <kirk@braille.uwo.ca>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] audio libraries
References: <m10wS3D-0013oAC@braille.uwo.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f93a15db03481e94fdc4eac1852778da

Kirk Reiser wrote:
> 
> Hi Folks:  There was a gentleman that posted an article here about a
> library of audio routines he had written.  I thought I had kept the
> article, but it appears not.  If anyone can remember any pointers to
> his work, I'd like the reference.  I need to have some library
> functions for opening and manipulating audio data for the awesome
> project.  Thank you very much for any help you can lend me.

Libsndfile possibly?

    http://www.zip.com.au/~erikd/libsndfile/

While I'm replying to this, I may as well mention that I have just
released version 0.0.12 of the library. New to this version is the 
ability to read MS-ADPCM WAV files. Write capabilities for this format 
will be coming soon.

Cheers,
Erik
-- 
+-------------------------------------------------+
     Erik de Castro Lopo     erikd@zip.com.au
+-------------------------------------------------+
Microsoft owns Hotmail. Hotmail runs Sun Solaris on their
servers, not Windows NT. Does NT have problems?

From - Wed Jun 23 14:15:57 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id DAA29654
	for <slinkp@ulster.net>; Wed, 23 Jun 1999 03:13:32 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id CAA05416 for linux-audio-dev-list; Wed, 23 Jun 1999 02:38:26 -0400
Received: from cs.tut.fi (varis.cs.tut.fi [130.230.4.2]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA05413 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 23 Jun 1999 02:38:23 -0400
Received: from kalalokki.cs.tut.fi (jams@kalalokki.cs.tut.fi [130.230.14.118])
	by cs.tut.fi (8.8.8/8.8.8) with ESMTP id JAA19509;
	Wed, 23 Jun 1999 09:38:02 +0300 (EET DST)
Received: (from jams@localhost)
          by kalalokki.cs.tut.fi (8.8.5/8.8.4)
	  id JAA23249; Wed, 23 Jun 1999 09:37:43 +0300 (EET DST)
To: Kirk Reiser <kirk@braille.uwo.ca>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] audio libraries
References: <m10wS3D-0013oAC@braille.uwo.ca>
From: jams@cs.tut.fi (Jarno Seppanen)
Reply-To: jams@cs.tut.fi (Jarno Seppanen)
X-Url: http://www.modeemi.cs.tut.fi/~jams/
Date: 23 Jun 1999 09:37:43 +0300
In-Reply-To: Kirk Reiser's message of "Tue, 22 Jun 1999 11:01:27 -0400 (EDT)"
Message-ID: <ruv4sjz777s.fsf@kalalokki.cs.tut.fi>
Lines: 17
X-Mailer: Gnus v5.4.66/Emacs 19.31
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 603aeb149611f281a6f8ac0ae4e40098

	Hello.

	I'm not sure which library you meant, but we've been building a
library for the construction of generic signal processing networks from basic
building blocks.  We've got some example networks you could use to manipulate
audio, such as chorus/flanger, parametric equalizer, wah-wah etc.

	It's called Sonic Flow and the home page is at
http://www.cs.tut.fi/sgn/arg/sf/.

Kirk Reiser <kirk@braille.uwo.ca> writes:

> his work, I'd like the reference.  I need to have some library
> functions for opening and manipulating audio data for the awesome
> project.  Thank you very much for any help you can lend me.
-- 
-Jarno

From - Wed Jun 23 14:16:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id IAA15864
	for <slinkp@ulster.net>; Wed, 23 Jun 1999 08:39:10 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA06012 for linux-audio-dev-list; Wed, 23 Jun 1999 08:06:11 -0400
Received: from braille.uwo.ca (speech.braille.uwo.ca [129.100.109.30]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA06009 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 23 Jun 1999 08:06:08 -0400
Received: from localhost (921 bytes) by braille.uwo.ca
	via sendmail with P:stdio/R:inet_hosts/T:smtp
	(sender: <kirk>) (ident <kirk> using unix)
	id <m10wlmR-0013oRC@braille.uwo.ca>
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 23 Jun 1999 08:05:27 -0400 (EDT)
	(Smail-3.2.0.102 1998-Aug-2 #2 built 1998-Oct-13)
To: jams@cs.tut.fi (Jarno Seppanen)
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] audio libraries
References: <m10wS3D-0013oAC@braille.uwo.ca> <ruv4sjz777s.fsf@kalalokki.cs.tut.fi>
From: Kirk Reiser <kirk@braille.uwo.ca>
Date: 23 Jun 1999 08:05:27 -0400
In-Reply-To: jams@cs.tut.fi's message of "23 Jun 1999 09:37:43 +0300"
Message-ID: <x74sjz6s1k.fsf@speech.braille.uwo.ca>
Lines: 10
User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) Emacs/20.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 450d78f5ce4ac86bfb6cede68919a45c

I'd like to thank everyone for writing with all the pointers. They're
great and will make getting awesome off the ground that much easier.

  Kirk

-- 

Kirk Reiser				The Computer Braille Facility
e-mail: kirk@braille.uwo.ca		University of Western Ontario
phone: (519) 661-3061

From - Wed Jul  7 01:00:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA13253
	for <slinkp@ulster.net>; Mon, 5 Jul 1999 19:31:08 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA01413 for linux-audio-dev-list; Mon, 5 Jul 1999 18:41:49 -0400
Received: from fep08-svc.tin.it (pop04-acc.tin.it [212.216.176.67]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA01410 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 5 Jul 1999 18:41:45 -0400
Received: from tin.it ([212.216.162.176]) by fep01-svc.tin.it
          (InterMail v4.0 201-221-105) with ESMTP
          id <19990705190208.LAXB14443.fep01-svc@tin.it>;
          Mon, 5 Jul 1999 21:02:08 +0200
Message-ID: <3780FFA7.C15ACCF5@tin.it>
Date: Mon, 05 Jul 1999 20:55:35 +0200
From: Maurizio Umberto Puxeddu <umbpux@tin.it>
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Pitchtracking software
Content-Type: text/plain; charset=x-user-defined
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 0f56e0cc757b6812fec9a787ff80346b

Hello all,

	the new releases of my pitchtracking software for Linux are ready:

Libpt 1.0 (a multipurpose pitchtracking engine)
Pitchtrack 1.2 (make a pitch track, in several formats, of an audio
file)
Chromatictuner 0.2 (here the name says it all).

This software needs Pruett's audiofile and FFTW libraries.

A release 1.1 of Pitchtrack that doesn't need Libpt, runs with or
without FFTW and has _almost_ the same features of 1.2 is also
available. The 1.1 code is very different (one for all: it's C, while
1.2 is C++) and will not be maintained.

The sources are downloadable from

ftp://mustec.bgsu.edu/pub/linux

The small file

thePitchtrackingSuite-1.0.tar.gz

(pardon the name...) contains the libpt library and the applications.

Thanks,
Maurizio Umberto Puxeddu

From - Wed Jul  7 01:00:37 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA17139
	for <slinkp@ulster.net>; Mon, 5 Jul 1999 20:14:06 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA01477 for linux-audio-dev-list; Mon, 5 Jul 1999 19:29:46 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA01474 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 5 Jul 1999 19:29:44 -0400
Received: from bright.net (find5-cs-3.dial.bright.net [209.143.26.72])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id TAA08957;
	Mon, 5 Jul 1999 19:28:19 -0400 (EDT)
Message-ID: <37813D9F.D2956DCA@bright.net>
Date: Mon, 05 Jul 1999 19:19:59 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Maurizio Umberto Puxeddu <umbpux@tin.it>
CC: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Pitchtracking software
References: <3780FFA7.C15ACCF5@tin.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: a6bfa56df592d0de45378f86fe5654e0

Maurizio Umberto Puxeddu wrote:

> The sources are downloadable from
> 
> ftp://mustec.bgsu.edu/pub/linux
> 
> The small file
> 
> thePitchtrackingSuite-1.0.tar.gz
> 
> (pardon the name...) contains the libpt library and the applications.

My apologies to Maurizio and anyone else who looked and didn't find. The
package is indeed now located at the URL above.

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Wed Jul  7 19:36:02 1999
Received: from fep10-svc.tin.it (mta10-acc.tin.it [212.216.176.41])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id DAA28232
	for <slinkp@ulster.net>; Wed, 7 Jul 1999 03:20:22 -0400
Received: from tin.it ([212.216.171.120]) by fep10-svc.tin.it
          (InterMail v4.0 201-221-105) with ESMTP
          id <19990707071217.AVD27735.fep10-svc@tin.it>
          for <slinkp@ulster.net>; Wed, 7 Jul 1999 09:12:17 +0200
Sender: umberto
Message-ID: <3782FC42.323FFF18@tin.it>
Date: Wed, 07 Jul 1999 09:05:38 +0200
From: Maurizio Umberto Puxeddu <umbpux@tin.it>
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Winkler <slinkp@ulster.net>
Subject: Re: wavezip
References: <3782EEF5.1685313C@ulster.net>
Content-Type: text/plain; charset=x-user-defined
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: a3a93d62328f5b962bc350edc5c5e571

Hi,

Paul Winkler wrote:
> 
> Hi,
> 
> I browsed to your homepage while reading my Csound mail today, and
> noticed the entry for "wavezip". Currently I have several hundred MB of
> audio files clogging my drives, so I was curious to try it out and see
> how well it works. Unfortunately I can't seem to compile. First I didn't
> have wavstream.h, but I found it on your page and put it in the wavezip
> source directory. Now I'm still missing some header files:
Wavezip is source is a bit out of date. I didn't build it in recent past
so I never noticed this problems.
 
> [pw@slink source]$ egcs wav2wdf.cpp
> wav2wdf.cpp:6: String.h: No such file or directory
> In file included from wav2wdf.cpp:11:
> wavstream.h:13: String.h: No such file or directory
You haven't String.h because GCC/EGCS people now uses Standard Template
Library strings and simply removed String.h...

> In file included from wav2wdf.cpp:11:
> wavstream.h:16: common.h: No such file or directory
This is a wavstream header and you should have it. But don't take
care...

...I ask you to wait until this night (your late afternoon?) or
tomorrow. I'll send you a new release of wavezip that will fix this
problems and allow you to use b2zip instead of gzip (reaching higher
zipping rates).

In my recent programs I started using Pruett's AudioFile Library instead
of my libwavstream. Pruett's lib can read several formats and I think
that the wavezip zipping method could work with any PCM file. 

Thank you,
Maurizio Umberto Puxeddu

From - Sun Jul 11 12:34:11 1999
Received: from fep02-svc.tin.it (mta02-acc.tin.it [212.216.176.33])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id LAA08357
	for <slinkp@ulster.net>; Sat, 10 Jul 1999 11:09:46 -0400
Received: from tin.it ([212.216.171.99]) by fep02-svc.tin.it
          (InterMail v4.0 201-221-105) with ESMTP
          id <19990710150122.NEDE29249.fep02-svc@tin.it>
          for <slinkp@ulster.net>; Sat, 10 Jul 1999 17:01:22 +0200
Sender: umberto
Message-ID: <37875EB4.B9A5393A@tin.it>
Date: Sat, 10 Jul 1999 16:54:44 +0200
From: Maurizio Umberto Puxeddu <umbpux@tin.it>
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Winkler <slinkp@ulster.net>
Subject: audiozip [was Re: wavezip]
References: <3782EEF5.1685313C@ulster.net> <3782FC42.323FFF18@tin.it> <3783FCD7.7FAE6EEC@ulster.net>
Content-Type: multipart/mixed;
 boundary="------------A76E11BC78EEFF18F5E198DC"
Status: U
X-Mozilla-Status: 8003
X-Mozilla-Status2: 00000000
X-UIDL: a4158330ddf5ccc0186c61751bf0aea7

This is a multi-part message in MIME format.
--------------A76E11BC78EEFF18F5E198DC
Content-Type: text/plain; charset=x-user-defined
Content-Transfer-Encoding: 7bit

Hi Paul.

I attached audiozip 1.0 (=wavezip 2.0). The main program (audiochew) has
been rewritten in C (instead of C++) using AFL and now
audiozip/audiounzip are plain sh script (instead of TCL/TK).
The configure script will set up audiozip/audiounzip so that they use
bzip2 instead of gzip, if present.
Using bzip2 effectively leads to better zipping ratios.

I tested it only on RIFF/WAVE audio file, altough it should work on any
signed 16 bit PCM file.

Please tell me if you find audiozip useful and what zipping ratios you
obtain. Feel free to report problems and your hints for improving this
software.

Mauruzio Umberto Puxeddu
--------------A76E11BC78EEFF18F5E198DC
Content-Type: application/x-gzip;
 name="audiozip-1.0-src.tar.gz"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="audiozip-1.0-src.tar.gz"

H4sIAANehzcAA+xce3MbN5LPv0Ldh0BkV5nMUbSoh7Wxy1WmZdnmri2pRGqzvk0qBc6AJOLh
DG8wI4lO5T779QOYwfBhJ3te71WtWUkkzQCNRj9/3QCjythkH8xir9fdf/jNP+cjj/ZPjo/l
N1LKk0dH9LN3xD/dZ1/KRydHvUfHJ/v7h/D2oHdy8I08/ifx0/iUtlC5lN+U87HOi+wj43Ru
vwRDX/ajQv1HWTox0zLXXZN+xjV6+/uPnL436f/g4ODE6b93sN87wLfHqP/9z8jD1s+/uf7j
NJGXeRZpa2UxM1ZOTKLlrSlmUpVFhhYhi0wu8iwuIy2VrGxE2ig3i6Ir+qc/D84HoxaZUjTT
t92oLQQSPp3p6D2QzHIkMM3V3NLwy6uLVz+fnuKvp6/PTv9CD1r/Nbi8PLvqyDGY40H1Y3e3
LQzwoG0h91J5/1ce9pt8AvzqdIXG9XlFpUwdHf8LUpoYUVP7EFDbU/y3J/DbRvKe+BQo+v8i
2X+IwykxVv90/G1nMVthMVjg7fDVz2dXVxdXrb+fZxLILUw6fUiE8TdZFiYxxVK2kOeHvKIE
tZCQHzoRtUFTZRp/+1NTTjUHT+Uuzt9FaYV84HMisetZOvvb6Ox8OLg4fzr9IHRitbzHawVv
xh8OaB20lEFqCpmVxaIs5I3KjRon2q4ZUWLGObzUbEUs1DeD5615R86VSTuyI5uyGBYqjVUe
w2swaJ6+lGlWVDttNymRDaMLbKP4tnuZl7ooHlhZjV0n3P2p3ZF7yXzdD2ZaxTonL+NdvD7r
vzi7+nk4ehH4Az8cthIzN4XtztbpFMuFjvXEdqQt8jIqwCHhd9gtOOh8AdRzGc1UrqJC58YW
JoLVNotzKSdlGhUmS/2Qt+q9BmXk0pZjmFqU+LJWC7E9vH4+HDl/aNcPvE0EjyqFwybg4cX1
6PJ61MI1SHY+AfEvZEUw8F8dFv9tPo3875XyedP/p/J/7/DokPP/0dHJSa+Hbw+P9r/m/y/x
6V+/GFy8fNN/NXwKAasOaRC8xOB8OOq/eXPZH71+Kp8tcrCNu2cPxyYVQiXJY1klfAcFIGBX
j4K33Ujs3G+dnrYxg9VzgvfyfqvmA7zfkXssdqLZPIvlf95VYWL1EQUMyFUpqJF4ShIYspB7
k2Cp+61gK+3G+2bkWR0pytRTFjv5HGc1RzysFvnYe6S88YXjXuXRzNzoxzJKtEoPJFjkGDci
5iY1zZeH9Uv3C0oplt0upN4fPROhV+/ZPOrC2O70Aw9Be49uPsy2Dwufy709fRclZazlbiNY
fNe9VTe7QhBblXi+62byu/+RP977DhJRrlf13RS3m3zg9uZpMMTsRgrmySpRuKdJNvW/gmKK
0joih156TSqQF//VLvb/+tNQaa2Zz5oBPlX/He4fuPrv6GT/COu/4/3946/x/0t87n2LAf2h
nYl74t5O4Jr3dk6zxTI301khWxC7e99//6c9+M/34JFlbj6YTF6zyORleafjuOzIAUTKJcyE
f0ZYS7qiT2JZmWuoGLNJcaty/UQus1JGKpW5jgGd5mZcFlpCCQAA9iEgU4jwZoKU4BHAaQCz
UFVANZLPrcwm9Mer82v5Sqc6V1DAluPERPKNiXQKpYaClfGJnelYjpEMTniJHAwdB/IlwnSF
wPaJ1FDtwhI3oGAEugd+CUevA4US0GipAtnOZbbAaW3gdSkTVdQzu5u3Xu8wliYlyrNsAduZ
AUXY4K1JEjnWEixsUiYdoABj5Q+D0WvAyrJ//k7+0L+66p+P3j2hwhzKJKlvNFMy80VigDBs
KlcpVHjZBAi8Pbs6fQ0z+s8Hbwajd1jpvRyMzs+GQ/ny4kr25WX/ajQ4vX7Tv5KX11eXF8Oz
rpRDjUxpmP8R4U5IPSDBWBfKJNZt+h0o1AJrSSxn6kaDYiMNWSumjsFi+WmtofUlGZSq1Hso
Ahk+kVCJQmnVkbe5ATMBi1vTJ8yuNQqGmEbdDoSUYzBWa2X/BpR4qubj3MRT+PVtX+4f9A6/
78jrYR82IAT8fHU2+tvo6e61VVNItvdbY2V1quZa3t9vy7/7OImp6KfdoIp9Vv36rFm391wt
LAUGOR3NMqyZ3Tq/8cM7U1AJbCe40tP7vZrEtwQmfuU3Vam/s0OEdpvsPa4HPpZQ/9symnEj
B5QVG9BFkeXLXZztV4zdii14zWQ8hfbDkHjFQDfuBltti+IPE2hMF898qfissdEaQco9A48L
N/v+r7Eb4GCWf/O1VPw/fdbz/+fO/p/O/496J3X+P9ynt8df678v8tmQ/79m/6/Z/2v2D7P/
j7/u7VnYl12oSP/4m0MDvw8KAA54KneD+bt1Lg/hwkEFF3Z2XJYP4QI9xOS9swPpGzvqK/N7
f2Q+IoBh/69nw8v+6dnTj/BasVqPfnc2hL89YjnwvATk6rc9WslBhd0qye924y8GdIIuULVG
DR6EE1TF/W/BsUf9sObKow8PV3CJZw0gU5FuHOL8TlpfPP438v/pxeW7wfmrz73Gx/P/0WGv
d+T6v72TE8QCvcPD48Ov+f9LfHZ2UAcUmM/Oz676byAjPH8zOJXwL8SyM8ED4PNXnyA78s9l
qhESQLkiV3HCnyCu4qutGZfjM9U/8vh7OdKQw7S8TCDcyD05LDHIHx7ud+TzzBY4nON1r7fX
O9w/cUFbnkHWXWbABmYKQAamwAQLyYHyDZ6DBdACxo5h7Tm+NNoKzkcwM3FpLc6icq7TAk+L
Czw4S6d4agrpGQbhqZ5KkuxWx12BgRQ5v8w1ZJREgwTkaKY9JesyJLi9hztSUbq0ZpoyhwUe
r6lbtSRAIRAbxdkc39gZjcdDPGQBMREk5udL7GUWubLA3+Y0Knx+BnZNWmgATbTUtFSIC0AR
hF0+thS+E57nvT0YMkc+LZ7046LVdjycw42CWIBHK8k5uigJY8U2XLZArGJxcZKPwwTNRF6b
yQMbSDCl3SDkygiseXx1O8uQcgmwKLd48gl2ACNFaVl9wFJrmEHu4GnbTLKxuSgDc2Ho6IX9
xh2UbtkZHhFoFXfbUr5zyBY3u5TMDIne338ADWZZF63mB0zWtyDYhVbvURoNkNzBV8hRric6
z3E7IAGnwA7apFjksD7s8ALIb+bMrtleqFNGtIIAG+40sI7Ad9hl1viTLWc7+ZRMQZA/gRnc
wNII2RDj3wIIb3eqpTwsBCJlHiHpmBI3CmyqEQ0LPxGMFv4MpuIYZ6kNa4TpYHwSeIyYSySS
yhTyPfHr5f6EjciTe59mtxXdmCClRcogZ0vaGdGdlwIABbsOhThLWkl1IMtco6T4+JzJgzDG
JhZgrBieUJg6JVd3izAlZBxN2r7nV4hl8lxX1Q6P6ooRz2msAi5tsfSgcAdJSxkspewCXpox
3vMwLg4hZZao2KjRUJJY53i9cQGG/oOieAkv9J3CMN3xIzaSIzSmvMhBVjONbifgr8LQjilm
yIkGQrQOJF85Nc7+wDoMkEpBOBhXaimQXNGNqLjospfR3BVzhilLcrBOZWqBeWFxE1ge0OmD
SVR8QP1yi2Pm3hio3rRkG0s2GPjN5MKrBn1Yb7ISV8Tcgk4LvbCPZavXprzEebIpdTBL0Tpo
g/zAz52ZBJnpdmZAqCgjSy8TPQU3p4xnKR27lNcJNdyooxvrEdf9xIKEUBdaRTMXPh9YvxWk
is4CG2KDJ2/0Bu8MTpDAtc/CVKZbvG1jK1VwOE2zujqliyszl0CqZAOKGEzWcgwxbygOw/O5
xlXoIhGytoC6Dl4hOrjVwkULG1oQsOtUBszceuPg6tTldFwxA5WYVCUdWIO3hEkGBAGpfU65
lC++ERuURCxX7EgAQnOCqs/SBi3h8tEDGLAoC+Wv1oAn4etk2aFFwvCELBUzgBSQujVe4cFD
57SAFEK7d8lxga8LzLM/aIqtFEFuMhPT+jFGx5x3HHRWMDOCcyoWepU5cRMmjc2NiUtkSmZj
CiS8SIVnOti00GCbEXkb5aFZTQZ+QhrSAKGXXRc0sTlRkJrJeEjicxVTgwdPaB2HIAK3IXa/
cYWhYjZNZ1oPHNzAKA+PUe7VOEXArOsx2AL1X3ku34WCHXLURJroKLCDTh2+nK0LtraI0cAk
Q7TXFf8hPomO4e3o7OrtUPbPX8jTi/MXgxGU/9xncdVUR74YDEdXg+fX+IoGvr14MXg5OO3j
A2R+v0vIaRNUcuZIwoYdMI65zfL3LjIgMgS1WaFQNJh7F4ikyV7RKOqwM8sSTC5WLR20nQMC
BakHDSqxsdsGjG2GF10W++4l87cL6FmD4DqCMEvFPqWFYA/IPV9VU3KXtoIlfuzdyFMTcw15
zrfngjdIA+kCq+YGNAb2RVSY+XrDibp9zD5tiBfYOSzLY53YnDk3KMtFlpMZEJjoiLo/yDUE
7gDje2gy1ofcKjdjs4/2TxoTCfhmqaYostZriIwQCCYg4k41ARck8E5XLeKq1Uc3AN3rVHjN
yN1w9V1EnmcYyp1nUIhTcQyggNzEyl3IHbvgKH0I7zcMEDInVwRW2/yisUkCkwg8a4TM1uHM
4QmHWEJlZWENuTxkUKDuTUVhtJyIvEzXRO+Cskc6Ou44xKb9vdBJns3DKSIA61mKcHtCC6Ju
KQdQGMXri9qrPTQ04VduQRjUC4ReKVUlELGQubEGfE6BC/a5geN2V/zAAEdWRpaXCLeRlsVV
fN6pNhlnmjNBr8sgRi1/T8HqsZoj88CGOAbVG4JrhM0mJQ+ZQxYoAYiB80GY1zX+FSiahYnK
rLQJrw4xh2I52C48cR103ARhBMdkOErUnuYij9tElCgzB6kA0z7zP5HvtV6gS6AFOHQneJr1
GQvxD3V3w0jIlR9uXo2tTmEVzGWwt4q0wDEEIuv6MAACTdE1GtL1OqLRfK5Gg6oqLXGlQ+DV
4RgItbOlBedInF2zM/tyjVdigLd0VJqHCA7zVfAowF+YdO98Ze5BM1nOQW05Dt8RRd5Vvtlg
fMR0kU1wZIMRJeXFObO7NRT7e8VspyHQpNDeDIQuwG86uBm6zfWEGmfYlF+zSzANANxzrdlI
eBdWB3n8saDOkWrXRUCkSssVRIUZ6Xo1QWOQLQkW9oju7UyOaOD1MfZpX2OSvDnmMAUfgWKs
tpzh8agu8zFe44NsEwVQkQ3khV+EYM9ypS3EdCRzC8mZ3hIAy4sqrdMzy6kO97USAp1iiQbN
I9idTbAIaiAqiBHKraJQCt6eMUWRN5o8rqigAW1DAj718/ajtofuleh9ok/BrghXAqqNuTdD
1QG2p/BaOuwnWbrNQ6CFABvUhCxKtFF6iS1aTKk+CqNHoOnR9IAggUR3yMY9pjyGTJtjtKDC
ELgzGOTxsMACUEKDZntK06yE6IJNQJeEySkaEU9ujHiKCLgH22ufFmLaBM8THQKr7MN5AfNR
TWjXDQvqrpHHNw5MKQI5aZO6iMKqw7g0qpPE5y8kJ6nYzeSNwZuZjZhIVGqE1zq7izSFq8eY
YBspu7A6mfieo9cB8EYkMNdRSq8sgYXPXYK0IfIOB7FGBPK7WUcI/12anFswTHGFWLcNyN33
TWjsnJsK1JNz2aSyV1qzdg8qRoVBLADv8fsO0mrXeCEBYTlJUxgMbXXNDuUl7D2MkQ9lsxSo
USsXoVFOCLHGHTjYavA+tDNcwDq8NwcZ32AdRod7oQ+yZhHxkIt2sI9Fvep6nxmktop9cqWV
gET9DmVXlsamc1lUE8SK0Vk8javI4nk7hh6qMTnEcGlibCOpiNWkQoE1BJwuaTENXxS6WT4K
iaYEuAFct0O4zmMQ4MEw1BB32BJ3qheo2twt40FmSdmC2yHwgIpP3laupyqPE/x+HAKaGbg0
pmlujo1gYic4JqAzeUKfVcB0cqJkhMAo6P8RULWFCFtHMIyruxxPNAAFELPcCIBxTyRoaUaF
Q70UlTdC3+mcy1/fOOPeELYwko3CDgqoLAc4l2A3w5dTdiMUgD0PUiwtDB/lzDHSqekUpeTJ
upqH94FS2URIrGItCpD8vcPtSKSNfyt5kyUlNvUnUPXaIsuhsHIxvd4fY986Co1zH/8C7jhs
kk1jlbIxyx1+HKqvbmGVeywhOZl6+HPQxhyVjX/BnorvgYP2orKgeIOIbEP+FUPvcT3i4UAS
itoGoiAYYMvM+RS3NEACNX7qR/hNMYQrdAvFaQOfJZpyXc49ZUqEc/AMQFB7mMyRSQZQdRHS
cT7vvTa89bIdCXKuaW6HFOyUFwG1bK5yA/Zf+sZQ3STEpMNo7AmIsFMhsvWdqcqfCHJ35I1K
DJMDmSUQnQvqv/G+llrldFBTlxUEkCggLDsOkDsElWZ8IYYKaTrQI2DkTrh8hYDZT+ceazvB
hfbaoSzMsicKqxJvXKRpKqehBwJ+nIB/nw62y5938g/oINpmXSZFEXCkCGpWwqcuMZOCOPev
nENt2TJiFOqeqQR4STmeORjjjm25PTCh9mGKSBQjJZRta+0O30bApIfzK/5CrPVp56X9VgBV
VVaHZTnIJef2jhyWY58dxix9gC6IXBoHZJM6qHBHjHmhY0FWx7zKnDgID+Ncp7ZZmYE86UT0
JRUNIdPckatcn1cXtDov6c9j1viC57BIibWSqasWqOyS0lJloqzNIuMbYuACeMwf64lJDfda
sc5y4zkO01e/2NQgq/n8xd9qVZWm3NeyVAgc6h3BLl+D4m9Q6IjthF1o0rj2YLaztp/QXeiI
D7OG68fhaR4dDlatngrUhtNaWLZzu9BRxq9YUwUiUE/t2hPm6hdCAHOwaEKnLf+93Y58D2as
E4YmFsN42+1QQI7KuWi1S1sAdKMmEwbe5v6xUgKplmnC3+tXRb2UcLBdOQ+lRnNTepDkJ2to
IaCOECvwADytcX0yMnTgTwB1WtpdyCB0rNxRNFkDtakdqvWzJMJ1CM3I5QqBNevzcJvAKBGD
FyXhfCs2wcpGlHQ3KLNyOgtiu3En5tzknC+gaAoulQREVtpFgTDw1EDKoxozoBVxI4jbNR38
VnVS3y3dgiUEWypar75bYCOXCiiX6n04D6AKnmZigwmsYlEIwji3hAazrctvXx3jJ54rsQ3S
WRH+3yAwcnMywyxiUJGNc88NbInKD72AEUI3L4lyz4qE4Y/ZSb2YITxCC3qC1fmbv7lg8vr6
TcUYuQ6pCcsbjMWeAagH8aAL/pmUCUeWxCgoHgnuHbPqfHkXVptokotipQazBpuS/nCaTMdd
t6BgW20fQTGZOJ5hTrHE57Zt8yjXtfQghG9RDPaDCrt69sF3b7DiVb4qy+mQbmbGpuBWfaJu
q9N7Vyiu74fpQHLJ8Gx6vOSDMepXNAD2SvO+5RqMW5vsbW7u4IFjVFkNr69cU7eh44IALB5T
Y8fRXzP6Iwd7zHHFvlgR4kqJ4646POryOUph5toBlI9B/U/suAgvNaw4kDN+LJG9N/qQJvxB
snvDN0XYiZu9xOCA3/MF3k2xqMDjbL3lMNRfoXDhyUBmcJ3LSZnTeVXjwomrweqm+gNZFZsu
uLoAQHYNopjREVdXND3J3VBhlASVLfw3Qj3VHuiOlIJwTPtYqchOunIw4cRO7RRw0epkAJMA
VO2/lPGUenkMUoLqlM+cBSBRzDjaD5o4ffrzA+zXyBafNs+Nu1vozqvBXUtt2x0RWCGBYZIj
GQLaTsvdf8FNMVeA/AiRQLnsF64jddvnabzqB25SOKRfLbHiIx0+bmNfxnSBzU9ct0qN2+fy
lQt3/wmnhz39zKFxi7d2wLysmZcJuKnmwyI+wIAcMnW4so76Ijy2CW7radAltd+DaS71rykR
obc3zC2+5479128mKa/d6vYMfSUBSfEdUZlnSygTlnt0pSBw7gAn+FUg+DHszegaTlYdsLkj
Fr5uniy5bV/9BWUkoQrYB2+RIg8VFu7KJxoDcOXFOwYhuS+/NGMgMz/GYIgn6jkmraodREr+
CPuM4YJDn7WGFPw60wkiaS6G8SZdyk6pCeVx6iUS6IxRmeD/OMDkUTm3FLU5wo1V8r/tXXt3
2siS/9v6FH2ZM2NIMBjnOX7dxVi22cHgAeyMTyYnVwZhdIwlVgI7ZG7ms2+9utUCnJe9M7t7
zMmJQequLnVXV1dX/6qUqnDfJm8hUR12SurzFF3IOpaYQ64KgDJkEXLsZvEEtZ5xuY2nMWmw
JT43GJmprM/0i2e9hT5JUlgFOvpBVGfiPSN3nQbqia+OHQcBRdoQEfJmc8mtbONDT3Y0+HQW
h/qUT5A0+NCXsVCcCAwz3WBnhpiN/qLxrzoY/0OahJf4McMztPSPySWPHabUMY2jHyHW2kBy
nEvEdcC0Zq0jzZit+C0e4cd0BonovgWW/L6jpZ1Ul+xJCI0o+jwK2eGdkOIkXEvP2rN5YCxR
pS1xok7H5riXQFTlfhTyAPRh9ekTspSgVioZksygMUjLe8ZZYHjV/KXKSJhk+InBS4galJWQ
FfEwCsgm7M7NGltMCRKHjGIr6N0ngNOtbBIvoBv8G54AF/7iasWrajJZUM+0iXhd0odr836K
sqBe5zRWkFjwCTw+0OBQ2hhh3iy9O0VZSaX/YpaebNn7dNbRqTmygCVCrUhbryTDx+I2gDS6
1++z3wGFAIb70sfi4yGdoGce0QK9cO4RNuCixE8fpcjQTG+SrZoJB2B3TkhGwDVsBZy0I1h1
TBNpwO/jkhjy4VTP49XV0sVg5Ecwg/GIJCGFbrEI8xykUjsY5fjxIuovoAzIePm5REiYO6Ho
2FMafRH7NwGd3vKQI6hZgg0TR4fU3RGnRzYAWrE4neAvBvjhs9k0aPKgYMIKH6ByB96TcRAT
bF27mRKcuFKDwyOQQ7A7EboAFTgQkFQ8A46oCYOg5GMOEESCQJJxrSMtoWPQv4r+RhxCGOMp
PDTqRV0ipKCcFB+q98bkzRnQbn2u7MJGglWlBaiTlTaHyjsTv5krprs4WrI1RiN1nlsO1KxB
rUFi+oRQMxXFGjWQaSoToEpEURycJeKw8OzpgQZ3wmxZF8wdks0MhiXSdr6ugnvT5dwsi8lg
6NJ6SRuPGoNqzQ6yFRbwJ4SFY/1ro1ATOb/LzOA5o5oljc6IMwGgvD44gqGnFJNmJy2moVkF
zHmkrea+0POfizfNxA9jCEd07eMkSxxaD4yTMTGIZwnTwEWM+l1H/YLI91NeEDJ+GXkjmt00
9+IbLXZsFlDGI5IpqJ86AeiSjvDJxM0wpeg6Mnt2jPxhbEMfFIwsI6bKJeuT0SwNdWq2TAgy
jX+lpPbcWvW046rukaswq2W7eqzqHY2K3VcHbddVrQNVO6q2D90ilmu7WMKmhRhZiwCUatFv
iqLtqhO3fVzvdoHa3rmqnpwA8epew1WN6hvoTfe3mnvSVW+O3KbTQvJv6sBPp1vFCvWmetOu
d+vNQyKIQNx2/fCoq45aDcyriCDcMrROFTka2u04wMdZfT/7ULlqB9jOmXhszTw+HMZm/1Jv
7heVWydC7m8nbbcDz+8A7foxcOzCzXqz1jjdJyDwHlBotrrQT/BkwGe3RV2jy2rqwAzQd+bD
uBE5/BVx3NSFQAQ6vF3v/KKqHUc69tfTqiEEvQs0jqvNGg3U3EDi46rz1imuGvDcjX0s4OgC
2FGu2ncP3Fq3fgbDCyWhmc7psSv93elSBzUaqunWgN9q+1x13PZZvYb94LTdk2oduh8x0u02
Umk1WbdslHDwQErcM5SB02YDn7bt/noKz7NEEpBG9RCkDTvTGnfnTR0axxGaH/wiVYEb6eCf
gxi11HH1nIHZ5yIewKZBbmelAoQilc7qXgv7YA/4qRNbwAh2CA7RfvW4euh2io4RAmpawORF
1Tlxa3X8AvdB9GCsG9wrMIt+PcVRhAtCRFVhOPHRUA5lyHAOoqw1tYxA2/PzMp+2PSd/KBeN
VgeFDRrpVhVxDH/3XCzddpvQXzSdqrXaaRumFpbAGsBN5xQmW71Jg+Lg89Jsrrf39XyiflYH
1XrjtL0gY9ByC7oQSZKsmQHRQtYpFEkGVP0AmqodyeipzKw9V0cwFHsuFKvun9VR83A7DsyF
Tl36pCUUpB9JsVH0KTwflV8C4Efsf3WM4JzgwyY6cXEdqNKelP2sXbIC4OI5qt0mmDyy1iUo
x7I+9mF5HUVjWKLFJkrRlFaUm2D1ZMm8pCiQZOLAToSdZdPErEK8wZN9N24c0KVAnukhbjTY
9GG0O61EGAOfWRF4JTRhOwtJOKyAUHNkrJ2IOi5OO2YnE08OnlIDyUB6tf3IzgjoEdoQJd4A
Hw05NrWvdWFC+dFJE96RkxYK7tchoxyHwshBMBNu/JmcXIEJn4ixlkKOCcjj6QQBdnoKfeZP
lnzOGAU5sOpDcV6pcUT7IALkEJ6PHnTKRw8U45hIrl8+897G/qT6GjdgdcAqmGx4TsWkL2AH
MlCw8HsMKeJEIIQN3yVa8zHVsxnQJwK48pPhs8utPkiiFUJRPkSqFY3Yu1+yFaTyNelWlnbA
t6ZbIcjI/RKuIIn7pVwxQUZfm3SFatw/6QpDJL477YptLRMtTrzy3UH9DgYmkpvAxomgK431
L8ELONQSLWYf4WpxFMIDcUwgbAAwa/eIfZ8ZyEYGolrUylFHlnjYj7FB9Y6CK1alDiEgoRyp
poTDKjJgV5hBvkCqDkOwsm/YvNfy/fLn4rLJnJ3KC7V7sJ2QINLqXqfVAPOjcW6bzlskEiIN
lApc/YvCV29XS+msmFcH6cJDK4E/wnawX+e0A1GQYCrjQNJ7si27ud6qzUiJsSvD2Rh3enTQ
lcK+NX/Eg6kt4qtDbzPhJZmN5J0BaK0Bna3IcUjaHp0dJ+jmnKGHAw/d6EgYNmrkYrCin5ay
JsFM7Kqn6X/hO9cRkFzrAQdX5Nm49sMpdJh/naytoRqn3XQyDfho1wT9SxiJPCyh8zAemYrg
RIlmUC2vQ98NHllqX/txQXEwd+wkuIcf8WFHyJB2PG3GSLrUO5fG4OTSUBVtfAQDJ8RY+YRD
No8Equ4hkALm7BbDqKgOiikHXJxHs6g/C32dWwkXxIuZaYgBQikDNEPQPBENLI0DoX9Zcr6K
J2QEGoTZmHBMb6IEqoJImKRgvGrQ2H8iN+rI6135MWnAbcaSYPQ3SEl3BjMtCneLqgKGWhyM
KBcJWix8o4gpO5JAB3mdgQSJa/cOrWscLXJ0lDo5UH7s8SX3hmOFwqZvu9CmYGyrIg9PaeMI
D6nNuwOMl8bRAHEK0UStz0sVnT8yJ2BlELzLbtFyrScGmOIIce1FYqVwq3GiOq67D9acDqFZ
ku7CWZ7uYtG7+Xfnsnn8fPtnMf8jp2R/yDY+n/+psvFq/ZXJ///iGeX/f/7sMf/zX/IpP3FW
Mpn6qyZfGkiE891pIFech0kC+TA5IB8gBeRXZYBc8tTfuiG5b/rHe2Z//Lbkj/C899+F3Cvz
4z0SPz4pO84PAvAFY2ICcl8a7lqX8KVB2Sv6fTy72YqwzGavgXkHUoLXrIsmaSRdlxf4KDAh
r9Uf+3V0g6If8Mxtd9xP6Il0t8gWoHxksXrSOumiM7J5iDka+8Foc3j2MbflOHz3ekag3h3V
PG008KpVU2eBxIrqDxbf5JN6yy6Wd+pt38fjN+rEd7+Hud+dXEvOLyjLE7DpTUeTpLDJN9f6
yv7sE/QFRw3NSjRM8lKjIOWDTPl6iPPFtypIsZF6G74zxTpgIl9M6Zhx5IeXEzppwgKDmCzB
/MvnTyrrG891Ix8zjRx5FH7JHiMpcZYpcUKxgzJ1pcRwSQkSyWs0mC/ZgYOpJfGgGJlHh9CM
K/+Ox2/j6Yf/gK4sBdgmDAOCaJ0TD/aoeRknJlRw/gDTlMIXB3mV+zHZVD8mv+MZJA9kUbdY
2HI4T3h+rQLfPwlJylOaR/aI1IpQ0vlLf0zgn0VMSwBQoMyYed+ixeOX5y3wE+7yoqoeUD/T
ibmCucW3e8w4hU735NpoDIIFW/uY/iK/ch0uQXsZQgH0yUoCU703zAOtlRXgfQXP21VlE8+b
UMXkA6KjArWtQDkHT58WKH3pH/T/ygjuMpNvg3dqDZrfkhvjzB25ml7YUSO+RtlQL2Lfu9rS
rW8sb/1JD7883VEbX8dCbN1QT1UFb8af5y8ez9e5m3Fz7WkFr8bLHkemHj0PC16u5oWriJYO
+xhXaYKVNsjTG/qgyHMoGEBIi4RM0f87MpHt2h1s/2l64aGG/WtaWTKgOFR2SWuUH3bsQAc4
iG0nxeDFl72irADw/ebtO9IUfCEIcSHCDX5RPQGbQv8CUrjykF8L2OZlCS5S1Px4ggMJYweF
hSOmU1RCYn5o+YmT4CMSE31dZAVewwJFAeMTdjvk2hgQ5E+mY3HOdfB7KkAii8IS+ywOyFdY
lF9vgv5kWNT9Q81IaV6A+/JrILWwQf1dVgNsrh9NCakcM15rhkJqFlnqz/V3eK1cRoOqg6ee
x8d4iNSoN11n5XaIhw75PHQalGd7IM9DgpWLyiznhYL6x45yWwda9PVcgBq2+JHArvZXN1nM
5kdoxRYkXTqYKy3mxV3FR7p4Zty8SRQgM8B34a6aZ7qmXogy2whY2HRNWn3Wl9CxZX9lhdc3
WvKWNzhczZRcRpELfjTPNH9nU+7wr3+uLm8aZ+inFaOhFA0iqHU0o8J+Rl2tEwXdA/WQXMuU
SI/zF8kcSyi8zO+XTLdkm8yqqEqGaOs+pFjbpVNfCzI/CmskSxdkbz8VlbVUWWn23ngxzuVN
8gx6MYVqYmKBa3+CCWINl/fj4dMWbjyYBhYYtMZ+eAA/8rZay8VgAKE1jE2mKocqHPqTA3Ml
r5VY9eD9vntQPW1033fb1dovWNFWI7pqTVTvZytSyY6ln+4sXVQ/ZfXYT5YiI+aNhjLMBwtU
fxLdxU8rSkuXb8M29XPcohrTY0hdxThLMCT7ZJSm3UeFYV+Wt3hE/VV5qf7974w+xqvQVKd6
fHJwDE29aXVARZ7gjEnXNr2yScgUULkA4/qkdiwJeBDBiSuc4kYzo7HLy/MisWsKfI8x+2bs
RwuUYEs2UO/36ofv3eZ+vdp8f9TqdN/jiMFacxbEk6k32ptN/BZGa3xm1ODK3nnXbbXx/a1A
jqlBB/3AKfHvRQ+27t2Ga5EM+8EAut5aFGlwm/4tCgNdyLPc4bt0LQGxatiLXVqWhCNTapE3
I1FpNTMLvlDVHjOsLbM7O3GtKQ8z9zZXtFd/bhP3/emjZm87Sm8Vd5Q2WgsYnxv18tZa9iTD
DPzEq9GAaxQKpFZk8cUFM6PceaFN7UVjuECT6fTYSg0akM91++fajgoz5mSIzNrFU04L/7R+
bKZEZJHzBm3f65MGu1sJFZU220O9OPL/st8zdxeHiNt4g14XaUTG52taWWJmi9nx/6Hz9M7o
f7L3PqEceoPaKEp8e3bwPEgvM/O0k/9u/2/G/3/r3fj4+qfh5Hr0gD7mL7z/6dWzV/r9vy/W
Nzae492Xj+9/+ms+2//oRz060sdB1xFEubVy+fZZr1zuT/p843lpndMbEgzAG5XLfpjbdbbx
Jv6BKUXYpW0w9TyoMhmvUTD/Tq7G6TjXutBITifn3MlN/A+TMtbeoj0qbPl2giRae/36xc9r
lZxFi98dw5DJbqttkTgGwR2NvPLz0gv11g/fqfxvlcqWqm+pRhBOP6iN0nrp2UsVvHj9sqDe
Nv0J2KRj/x2yXWaGtylMA1nZyf2wTp+curjsRaMohiu12gF8CBZ2JQVc+Hkjv19UKq9fuznl
ye+DAyKw6zjbPYzJirFjKvhzGKs39f3u0U4O5sKPud3tATyD0s3oenoubpfx9i4wWYH/NClD
NFu5VuPKfBVV3s7Tym4VzO7elSfZI4HmmCDf2IAjqQ3hqSaTEeIIJ0DVtEl/lnBs+PgpvEjG
W/b/AsKSBiXPTZLadGjSUdOMxMtPw4Jw5Eh2Hkq3lVA0m0KERiTZjCh/i44K+/P5+o+UtipI
rhS9noiisHXSTQcR+AUwQQkyT4S3p7uhvHKaQAUYngLSu12e7krGZZ1Rxcra54RRBn8E6jbh
kxs+mqC0FCY3H55I0AtTx5J2Uh/oSA45BMHozDY6jgrMU3k9tvovsA0x9o/DlgYcQirIf4xJ
ohdqSKJmA9tAbggPeT3l9KOW651yhsxChG0GSQYVQO8SkKjV+Ug8ytwO+zUjKZMoGiUqfwm/
YY2C/zeKanxFv3RHFpwRZXZEcCZleI4wf4Of4EmByv9ZeWENFo9JhJ58qFhytse2vK5VdpcI
VX2ghsHlEGEkC31F2Qt0YFHR0SxJOhxvkkiWQRjg6RomPsBuqdI3jYeJxhTPenziHj6TNH2O
JJ3BI8lpz9ehd1cmxxgLXSapIMeNW+KNcenOrY8ZM2iSRbeUdBtP6jBzpdmZyTEnsB2Nphzq
g+OTkxHIKY4146zskhBa0Lg8Qzg8Jh8NEB+DI1Dg/opNlK0WVhQh9BwOMM0VQdo46h+zPEEj
JTPpx8vGAbnavlhQWbXas2dLVNbFLs1rmcQYB+pLAoGAMpn4cYAdB0I78HqwwbSydUp7OT4J
zeGha04kPEcxeYkk7aFNpoTch4TpIhx0DhcGUPzRFI8+TE7moe/oGKIeabtbn2LOmIzVWf5N
gKGwMDtTVRvsbk8mu/18WAB7s4N/1vDPWqWwXZ7g8waWZqTM1zQcyTUFqEPXzVZjX2taP+RY
WYJ74zvW6ESYUvRcBPyaC04hIRkKE4lsp/Neyb3Zn8F6CCu0CculQF08eKVEUPjmCExLBlPs
Il42mp0IA5YMxghrw0OmHZSQEONzifIhnYbQbYkRXKLMVH7i94ahZLag99mQQ5dDenmEHcrT
Q8TElYHn3Hi4n/DrBxI8x014JTAxX6NZgcoRGm0Nk2pRlzgyLjggZhwcCn/NZr+3Bt4aSlMF
GEdQdxAn2pWMcwXM+Aimk98vlPRrBVgyTHx4ZtUIuMt0qk9ZCnC6Okat3ngx5xKVk0zgKOK8
ejKVOaM86ixejo0iRZlw5ju8hKGqgr1CQ8eEgXtpaqtvmbKOzrqVzlfS+agscQm4U5q+VTc4
2kigWDxJl3GBMYy1FKGIw2QgKTRWRWlOJ8gAIZmAZGKMK4u+BAnMizFNbnohEW7aPAbAomjg
q1mGqKPlwYuOaZQYhh+UvtVcpSV+kRfJ6QLN6YVTMnRRkhXsHdw2OFrGcYJIUgC7dVoPa4xc
5RACXMG9D5t3aOTFDlLZ1XTxjN95i+57f/LO6PrlA7rQDXOUrTdffi2ltOuW0tLv1P78IsQh
GF/iRcCVZHc6bHdqV6LSwznf6kRXo1J6rsNg8UR2UDqlBqmLWRohnCv1SxcfN3Clou+XH3Oc
apb8sCVVhSFOvd/4WqoEbBh4jovYu/InvILhoHv41kqSAppQC2NwhyhmpYisFIRIXSNIFTPO
kZ0vC2x5cj1O35DJbSHycxOzME0pcpc6wPCfsDcV/Sb0OgKM072m3GmUIYS+b7GGW0MAj2/g
U8jt4WmdlcbiToIuH4gZZrqW5TQpGpA/6TDYScb+YCeHqP5JtJkBWKCCQfj8dtnb5bZMcUys
/IG8GLndIzAPpEgZd3u0+aNN69+99f5f8cn4f+rNTrfaaDx0G1/w/1TWtf/n5YuXr9Zf0vs/
n208+n/+is/aXR+nqqcmSIYSySAd4dxdx+lGGr2fTm2sb6XsFDgnWy4IAuX36cF0Pw56Q88f
qZN4CkbQaqKMgtcoeZVHz9JmuXx7e1t6+fqqFMWXpfKf11yxbMqXC9arO4g+RV1oICIu26Bn
Bgo2XrSllOCLuRTSmMFnFcsFl9PYLwXhKhmjYGFeEQg1vbda4Jgjk0AiIN8FJl28MW8ksKda
qop5AzIbYxiR5ssxhDmhgOM0rdcVUh4iziyUxvmbN/NR8BK93QNoOlxfet5xdCpLk38BLpSn
SVweRWCb4Jvg4Tnugvaq7Yz+3f27Rffx8/h5/Dx+Hj+Pn8fPd37+GwIXvicAoAAA
--------------A76E11BC78EEFF18F5E198DC--

From - Mon Jul 19 19:13:41 1999
Received: from fep10-svc.tin.it (mta10-acc.tin.it [212.216.176.41])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id TAA10970
	for <slinkp@ulster.net>; Mon, 19 Jul 1999 19:10:33 -0400
Received: from tin.it ([212.216.180.211]) by fep10-svc.tin.it
          (InterMail v4.01.01.02 201-229-111-106) with ESMTP
          id <19990719230030.CRG4802.fep10-svc@tin.it>
          for <slinkp@ulster.net>; Tue, 20 Jul 1999 01:00:30 +0200
Sender: umberto
Message-ID: <3793AC70.E47C1539@tin.it>
Date: Tue, 20 Jul 1999 00:53:36 +0200
From: Maurizio Umberto Puxeddu <umbpux@tin.it>
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Winkler <slinkp@ulster.net>
Subject: Re: audiozip [was Re: wavezip]
References: <3782EEF5.1685313C@ulster.net> <3782FC42.323FFF18@tin.it> <3783FCD7.7FAE6EEC@ulster.net> <37875EB4.B9A5393A@tin.it> <3793A2EC.7B2ACF54@ulster.net>
Content-Type: multipart/mixed;
 boundary="------------CA044C69D5789099C204F684"
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 4e98cb86f0db6c857d0eb30cc4f11e68

This is a multi-part message in MIME format.
--------------CA044C69D5789099C204F684
Content-Type: text/plain; charset=x-user-defined
Content-Transfer-Encoding: 7bit

Paul Winkler wrote:
> 
> Maurizio Umberto Puxeddu wrote:
> 
> > Please tell me if you find audiozip useful and what zipping ratios you
> > obtain. Feel free to report problems and your hints for improving this
> > software.
> 
> First big problem-- if audiochew fails, the input file is deleted.
mmm... I hope that file wasn't your favourite one.
I hacked the audiozip script so that it should never happen in future (I
made some test with a dummy audiochew executable and it seems to be
safe).

>	 I
> encountered this because I forgot to make sure libaudiofile would be
> found.
Just for curiosity, what do configure said about libaudiofile?

> I'll write more when I get it to work...

Ciao!
Umberto
--------------CA044C69D5789099C204F684
Content-Type: application/x-gzip;
 name="audiozip-1.0p1-src.tar.gz"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="audiozip-1.0p1-src.tar.gz"

H4sIAKKrkzcAA+xce3MbN5LPv0Ldh0AU15rMUbQoydLGLleZlmWbd7akEqnN+tZbKXAGJBEP
Z7iDGUl0KvfZrx/ADIYPO9lyvFe1ZmUtaQZoNPr56wa4qoxN9sEs9nrd/UXvwTd/xEce7Z88
fCi/kVKeHB/Rz94R/3SffSmPT46OTg4eHh8dwNuDo6PDb+TDP4SblU9pC5VL+U05H+u8yD4y
Tuf2SzD0ZT+qqf8oSydmWua6a9LPtkZvf//Y6XuT/g8ODk5I/73j3sF+D/X/cP8Q9L//2Tj4
yOffXP9xmsjLPIu0tbKYGSsnJtHy1hQzqcoiQ3uQRSYXeRaXkZZKVhYibZSbRdEV/dOfBueD
UYtMKZrp227UFgIJn8509B5IZjkSmOZqbmn45dXFy59OT/HX01dnp/9ND1r/M7i8PLvqyDGY
40H1Y3e3LQzwoG0h91J57xce9qt8DPzqdIXG9XlFpUwdHf8LUpoYUVP7EFDbU/y3J/DrRvKe
+BQo+n+R7D/F4ZQYq386/razmK2wGCzwZvjyp7Orq4ur1t/OMwnkFiadPiDC+JssC5OYYilb
yPMDXlGCWkjID5yI2qCpMo2//XtTTjUHT+Quzt9FaYV84HMisetZOvvr6Ox8OLg4fzL9IHRi
tfyO1wrejD8c0DpoKYPUFDIri0VZyBuVGzVOtF0zosSMc3ip2YpYqK8Hz1rzjpwrk3ZkRzZl
MSxUGqs8htdg0Dx9KdOsqHbablIiG0YX2EbxTfcyL3VR3LeyGrtOuPv3dkfuJfN1P5hpFeuc
vIx38eqs//zs6qfh6HngD/xw2ErM3BS2O1unUywXOtYT25G2yMuoAIeE32G34KDzBVDPZTRT
uYoKnRtbmAhW2yzOpZyUaVSYLPVD3qj3GpSRS1uOYWpR4staLcT28PrZcOT8oV0/8DYRPKoU
DpuAhxfXo8vrUQvXINn5BMS/kBXBwH91WPy3+azkf6+Wz5n+P5X/e4dHh5z/AQGe9Hr49ni/
9zX/f4lP//r54OLF6/7L4RMIWHVIg+AlBufDUf/168v+6NUT+XSRg2XcPX0wNqkQKkkeySrh
OygAAbt6FLztRmLnXuv0tI0ZrJ4TvJf3WjUf4P2O3COxE83mWSz/864KE6uPKGBArkpBjcRT
ksCQhdybBEvdawVbaTfeNyPP6khRpp6y2MnnOKs54kG1yMfeI+WNLxz3Ko9m5kY/klGiVXog
wSLHuBExN6lpvjysX7pfUEqx7HYh9b7zTIRevWfzqAtju9MPPATtPbr5MNs+LHwu9/b0XZSU
sZa74fMH33dv1c2uEMRWJZ7vu5n8/n/lu+++h0SU61V9N8XtJh+4vXkaDDG7kYJ5skoU7mmS
Tf2voJiitI7IoZdekwrkxX+1i/2//qzE/1o3nzEDfKr+O+wdV/X/4fEh1n8Hx1/j/xf5fPct
BvQHdia+E9/tBJGQ7AEenWaLZW6ms0K2IIL3fvjhz3vwzw/gl2VuPphMXrPg5GV5p+O47MgB
xMslzIT/RlhRutJPYnGZa6gbs0lxq3L9WC6zUkYqlbmOAaPmZlwWWkIhADD2AeBTiPNmgpTg
EYBqgLRQW0BNks+tzCb0x8vza/lSpzpXUMaW48RE8rWJdAoFh4KV8Ymd6ViOkQxOeIEcDB0H
8gWCdYXw9rHUUPPCEjegZoS7B34JR68D5RLQaKkC2c5ltsBpbeB1KRNV1DO7m7de7zCWJiXK
s2wB25kBRdjgrUkSOdYS7GxSJh2gAGPlj4PRK0DMsn/+Vv7Yv7rqn4/ePqbyHIolqW80UzLz
RWKAMGwqVynUedkECLw5uzp9BTP6zwavB6O3WO+9GIzOz4ZD+eLiSvblZf9qNDi9ft2/kpfX
V5cXw7OulEONTGmY/xHhTkg9IMFYF8ok1m36LSjUAmtJLGfqRoNiIw25K6a+wWL5aa2hDSYZ
FKzUgSgCGT6WUI9CgdWRt7kBMwGLW9MnzK41CoaYRt0OBJaHYKzWyv4NKPFUzce5iafw65u+
3D/oHf7QkdfDPmxACPj58mz019GT3WurppBy77XGyupUzbW8t9+Wf/PREhPS33eDWvZp9evT
ZvXecxWxFBjqdDTLsHJ26/zKD+9MQYWwneBKT+71ahLfEqT4hd9UBf/ODhHabbL3qB74SJ5n
UL1FM27ngLJiA7oosny5i7P9irFbsQWvmYyn0H4QEq8Y6MbdYKttUfxuAo3p4qkvGJ82N/qn
PwXIYc/Am8K9ufdLXI9xkMu//Fo2/u7Ppvz/ebP/p/P/8cPDOv+fYP6H3772f7/IZ0P+/5r9
v2b/r9l/Pfu/+2Vvz8K+7EJF+t2vDg38NigAOOCJ3A3m79a5PIQLBxVc2NlxWT6EC/QQk/fO
DqRv7KuvzO/9nvmIAIb9v5wNL/unZ08+wmvFaj367dkQ/vaI5cDzEpCr3/ZoJQcVdqskv9uN
vxjQCXpB1Ro1pgAk8Qt2RnbqI49qIwEvO77FU7NJguS2ys7TBpIJaL9bUdI6cRqygTw9hwXe
iV//oJ74Sv4/vbh8Ozh/+XnX+Hj+Pzrs9Y5c/7d3ctI7wY7wce/oa/7/Ep+dHdQBheSz87Or
/mvIBc9eD04l/A+i2JngAfD5i0+NHflfZaoRDEChIlcRwp8houKrrbmWIzNVPvLhD3KkIXtp
eZlAoJF7clhieD883O/IZ5ktcDhH6l5vr3e4f+LCtTyDfLvMgA3MEYAJTIGpFdICZRo8BwtA
BYwdw9pzfGm0FZyJYGbiElqcReVcpwWeFhd4cJZO8dQUEjMMwlM9lSTZrY67Av0UOb/MNeSS
RIME5GimPSXrciN4ugc6UlGitGaaMocFHq+pW7UkKCEQFcXZHN/YGY3HQzxkAdEQpORnS+xl
FrmywN/mBCp8ZgZ2TVpogEu01LRUiAhAEYRaPrYUvhOe5709GDJHPi2e9OOi1XY8kMONgliA
RyvJObooCWPFNkS2QJRicXGSj0MDzRRem8l9G0gwpd0g2MoIpnlkdTvLkHIJgCi3ePIJdgAj
RWlZfcBSa5hB1uBp20yysbkoA3Nh0OiF/dodlG7ZGR4RaBV321K+dZgWN7uUzAyJ3t9/AA1m
WRet5keM+7cg2IVW71EaDXjcwVfIUa4nOs9xOyABp8AO2qRY5LA+7PACyG/mzK7ZXqhTxrKC
oBruNLCOwHfYZdb4ky1nO/mUTEGQP4EZ3MDSCNYQ3d8C/G53qqU8IAQiZR4h6ZhSNgpsqhEH
Cz8RjBb+DKbiGGepDWuE6WB8EniMmEskksoUMj3x6+X+mI3Ik3ufZrcV3ZjApEXKIGdL2hnR
nZcCoAS7DoU4S1pJdSDLXKOk+PicyYMwxiYWYKwYnlCYOiVXd4swJWQcTdq+51eIYvJcV3UO
j+qKEc9prAIubbHooHAHSUsZLKLsAl6aMd7zMC4OIWWWqNio0VCSWOF4vXHphf6DongBL/Sd
wjDd8SM2kiMcprzIQVYzjW4n4K/C0I4pZsiJBkK0DiRfOTXO/sA6DJBKQTgYV2opkFzRjais
6LKX0dwVc4YpS3KwTmVqgXlhWRNYHtDpg0lUfEDlcotj5t4YqNK0ZBtLNhj4zeTCqwZ9WG+y
Ele+3IJOC72wj2Sr16a8xHmyKXUwS9E6aIP8wM+dmQSZ6XZmQKgoI0svEz0FN6eMZykdu5TX
CTXcqKAb6xHX/cSChFAXWkUzFz7vW78VpIrOAhtigydv9AbvDE6QwLXPwlSgW7xtYytVcDhN
s7oupYsrM5dAqmQDihhM1nIMMW8oDsPzucZV6CIRsraAig5eITq41cJFCxtaELDrVAbM3Hrj
4LrU5XRcMQOVmFQlHViDt4RJBgQBqX1OuZQvvhEblEQs1+pIAEJzgqrP0gYt4fLRfRiwKAvl
r9aAJ+HrZNmhRcLwhCwVM4AUkLo1XuHBQ+e0gBRCu3fJcYGvC8yzP2qKrRRBbjIT0/oxRsec
dxz0VDAzgnMqFnqVOXETJo3NjYlLZEpmYwokvEiFZzrYrtBgmxF5G+WhWU0GfkIa0gChl10X
NLEtUZCayXhI4nMVU2sHT2gdhyACtyF2v3GFoWI2TWda9x3cwCgPj1Hu1ThFwKzrMdgC9V95
Lt+Fgh1y1ESa6Ciwg04dvpytC7a2iNHAJEO01xX/IT6JjuHt6OzqzVD2z5/L04vz54MRFP7c
YXG1VEc+HwxHV4Nn1/iKBr65eD54MTjt4wNkfr9LyGkTVHLmSMKGHTCOuc3y9y4yIDIEtVmh
UDSYexeIpMle0SjqsDPLEkwuVi0dtJ0DAgWpB60psbHPBoxthhddFvvuJfO3C+hZg+A6gjBL
xT6lhWAPyD1fVVNyl7aCxX3s3chTE3MNec435oI3SAPpAqvmBjQG9kVUmPl6w4m6fcQ+bYgX
2Dksy2Od2Jw5NyjLRZaTGRCY6Ii6M8g1BO4A43toMtaH3Co3Y5uP9k8aEwn4ZqmmKLLWK4iM
EAgmIOJONQEXJPBOVy3iqslHNwDd61R4zcjdcPVdRJ5nGMqdZ1CIU3EMoIDcxMpdyB274Ch9
CO83DBAyJ1cEVtv8orFJApMIPGuEzNbhzOExh1hCZWVhDbk8ZFCg7k1FYbSciLxM10TvgrJH
OjruOMSm/b3QSZ7NwykiAOtZinB7QguibikHUBjF64vaqz00NOFXbkEY1AuEXilVJRCxkLmx
BnxOgQv2uYHjdlf8yABHVkaWlwi3kZbFVXzeqTYZZ5ozQa/LIEYtf0vB6rGaI3PfhjgG1RuC
a4TNJiUPmUMWKAGIgfNBmNc1/hUomoWJyqy0Ca8OMYdiOdguPHG9c9wEYQTHZDhK1J7mIo/b
RJQoMwepANM+8z+W77VeoEugBTh0J3ia9RkL8Q/1dcNIyJUfbl6NrU5hFcxlsLeKtMAxBCLr
+jAAAk3RNVrR9Tqi0XauRoOqKi1xpUPg1eEYCLWzpQXnSJxdszP7co1XYoC3dFSaxwcO81Xw
KMBfmHTvfGXuQTNZzkFtOQ7fEUXeVb7ZYHzEdJFNcGSDESXlxTmzuzUU+3vFbKch0KTQ3gyE
LsBvOrIZus31hBpn2I5fs0swDQDcc63ZSHgXVgd5/JGgzpFq10VApErLFUSFGel6NUFjkC0J
FvaI7u1Mjmjg9TH2aV9jkrw55jAFH4FirLac4fGoLvMxXuODbBMFUJEN5IVfhGDPcqUtxHQk
cwvJmd4SAMuLKq3TM8upDve1EgKdYokGzSPYnU2wCGogKogRyq2iUArenjFFkTeaPK6ooAFt
QwI+9fP2o7aH7pXofaJPwa4IVwKqjbk3Q9UBtqfwWjrsJ1m6zUOghQAb1IQsSrRReoktWkyp
PgqjR6Dp0fSAIIFEd7zGPaY8hkybY7SgwhC4Mxjk8ZjAAlBCg2Z7StOshOiCTUCXhMkpGhFP
box4igi4B9trnxZi2gRPEh0Cq+zDeQHzUU1o1w0L6q6RxzeOSikCOWmTuojCqsO4NKqTxOcv
JCep2M3kjcGbmY2YSFRqhNc6u4s0hatHmGAbKbuwOpn4nqPXAfBGJDDXUUqvLIGFz12CtCHy
DgexRgTyu1lHCP8oTc4tGKa4QqzbBuTu+yY0ds5NBerJuWxS2SutWbsHFaPCIBaA9/h9B2m1
a7yQgLCcpCkMhra6ZofyEvYexsiHslkK1KiVi9AoJ4RY4w4cbDV4H9oZLmAd3puDjG+wDqNz
otAHWbOIeMhFO9jHol51vc8MUlvFPrnSSkCifoeyK0tj07ksqglixegsnsNVZPGkHUMP1Zgc
Yrg0MbaRVMRqUqHAGgJOl7SYhi8K3SwfhURTAtwArtshXOcxCPBgGGqIO2yJO9ULVG3ulvEg
s6Rswe0QeEDFJ28r11OVxwl+Pw4BzQxcGtM0N8dGMLETHBPQaTyhzypgOjlRMkJgFPT/CKja
QoStIxjG1V2OJxqAAohZbgTAuMcStDSjwqFeisoboe90zuWvb5xxbwhbGMlGYQcFVJYDnEuw
m+HLKbsRCsCeBymWFoaPcuYY6dR0ilLyZF3Nw/tAqWwiJFaxFgVI/t7hdiTSxr+VvMmSEpv6
E6h6bZHlUFi5mF7vj7FvHYXGuY9/AXccNsmmsUrZmOUOPw7VV7ewyj2WkJxMPfw5aGOOysY/
Y0/F98BBe1FZULxBRLYh/4qh97ge8XAgCUVtA1EQDLBl5nyKWxoggRo/9SP8phjCFbp/4rSB
zxJNuS7nnjIlwjl4BiCoPUzmyCQDqLoI6Tif914b3nfZjgQ51zS3Qwp2youAWjZXuQH7L31j
qG4SYtJhNPYYRNipENn6zlTlTwS5O/JGJYbJgcwSiM4F9d94X0utcjqoqcsKAkgUEJYdB8gd
gkozvgpDhTQd6BEwcidcvkLA7Kdzj7Wd4EJ77VAWZtkThVWJN67QNJXT0AMBP07Av00H2+XP
O/kndBBtsy6Togg4UgQ1K+FTl5hJQZz7V86htmwZMQp1z1QCvKQczxyMcce23B6YUPswRSSK
kRLKtrV2h28jYNLD+RV/Idb6tPPSfiuAqiqrw7Ic5JJze0cOy7HPDmOWPkAXRC6NA7JJHVS4
I8a80LEgq2NeZU4chIdxrlPbrMxAnnQi+oKKhpBp7shVrs+rC1qdl/TnMWt8wXNYpMRaydRV
C1R2SWmpMlHWZpHxDTFwATzmj/XEpIZ7rVhnufEch+mrX2xqkNV8/uJvtapKU+5rWSoEDvWO
YJevQPE3KHTEdsIuNGlcezDbWdtP6C50xIdZw/Xj8DSPDgerVk8FasNpLSzbuV3oKONXrKkC
Eaindu0Jc/UzIYA5WDSh05b/3m5Hvgcz1glDE4thvO12KCBH5Vy02qUtALpRkwkDb3P/WCmB
VMs04e/1q6JeSjjYrpyHUqO5KT1I8pM1tBBQR4gVeACe1rg+GRk68CeAOi3tLmQQOlbuKJqs
gdrUDtX6WRLhOoRm5HKFwJr1ebhNYJSIwYuScL4Vm2BlI0q6u5NZOZ0Fsd24E3Nucs4XUDQF
l0oCIivtokAYeGog5VGNGdCKuBHE7ZoOfqs6qW+VbsESgi0VrVffLbCRSwWUS/U+nAdQBU8z
scEEVrEoBGGcW0KD2dblt6+O8RPPldgG6awI/98gMHJzMsMsYlCRjXPPDWyJyg+9gBFCN6+H
cs+KhOGP2Um9mCE8Qgt6gtX5m7+5YPL6+k3FGLkOqQnLG4zFngGoB/GgC/6blAlHlsQoKB4J
7j1k1fnyLqw20SQXxUoNZg02Jf3hNJmOu25BwbbaPoJiMnE8w5xiic9t2+ZRrmvpQQjfohjs
BxV29eyD795gxat8VZbTId3MjE3BrfpE3Van965QXN8P04HkkuHZ9HjJB2PUr2gA7JXmfcs1
GLc22dvc3MEDx6iyGl5fuaZuQ8cFAVg8psaOo79m9HsO9pjjin2xIsSVEsdddTju8jlKYeba
AZSPQf1P7LgILzWsOJAzfiyRvTf6kCb8QbJ7wzdF2ImbvcTggN/zBd5NsajA42y95TDUX6Fw
4clAZnCdy0mZ03lV48KJq8Hqpvp9WRWbLri6AEB2DaKY0RFXVzQ9yd1QYZQElS38G6Geag90
R0pBOKZ9rFRkJ105mHBip3YKuGh1MoBJAKr2n8t4Sr08BilBdcpnzgKQKGYc7QdNnD79+QH2
a2SLT5vnxt0tdOfV4K6ltu2OCKyQwDDJkQwBbafl7r/gppgrQH6ESKBc9gvXkbrt8zRe9QM3
KRzSr5ZY8ZEOH7exL2O6wOYnrlulxu1z+cqFu/+E08OefubQuMVbO2Be1szLBNxU82ERH2BA
Dpk6XFlHfREe2wS39TToktrvwTSX+teUiNDbG+YW33PH/us3k5TXbnV7hr6MgKT4jqjMsyWU
Ccs9ulIQOHeAE/wqEPwY9mZ0DSerDtjcEQtfNE+W3Lav/oIyklAF7IO3SJGHCgt35RONAbjy
4h2DkNzXXpoxkJkfYzDEE/Uck1bVDiIlf4R9xnDBoc9aQwp+nekEkTQXw3iTLmWn1ITyOPUS
CXTGqEz+r71r707jWPJ/az5FX3ISgc1DyJbj6HUXoZHERgIFkBQdx8d3BIOYIzTDzoBknOt8
9q1X9/QA8iPSJrt7zPGxYKbfXV1VXf2ragwcEMS96W1CXJs53JU3Slm4bxdvIVEdNkrq8xSd
yDqWmEOuCoAyZBJy7GrxBLWRMbmNpzFxsCU2N5iZqchn+sWr3kKfJCmsAg39QKozsZ6RuU4D
9cRWx4aDgHxsqBCyZnPKrWzlQ092NNg7q4X6lE+QNNjp61hKnAgMM91gZ6aYlf6isa866PlD
nIRF/JjhGZr6x2SSxwFT6oTm0Y8Qa20gOc414jpgWTPXkWrMVvwej/BjOoNEdN9Ck/y+o6md
WJfsSQiNKPw8CtngnRDjJFxLz9qzeaAsUaYtMaJOx+a4l0BUlX4U8gT0Qfr0CVlKUCuVDIlm
UBkk8Z4xFpi26valzEgayfATg5cQNiiSkBnxMApIJ+zOrRqbTAkShw3FWtC6TwCne9kkXsEw
+He8AK78RWnFUjWZLLBn2kS8LuvDtXk7RUVQr3McK0gs+AQeH2hwKG2MMG6W3p0iraTUfzVL
T7bsfTrz6FQdWcASIVekrVeSacfiNoA4utfvs90BiQCm+9rH5OMhnaBnumiBXjj2CCtwUeKn
XSkyNNObZLNm3AHYnBOSEnALWwEnHQhmHdNEKvD7KBJDPpzqeSxdLV4MSn4EKxiPSBJi6FYT
YZ0DVWoDoxw/XkX9BZQBKS8/lQkJ8yAUHUdKoy9i/y6g01uecgQ1i5th4mhnugc89EgHQC0W
lxP8Rdc+7JtdBi0eJEyQ8AEyd2h7Mg5igq1rM1OCC1dysHsEthD0ToQuQAZ2ASQWz4AjqsIg
KPmYAwiRIJCkXGsfSxgYtK+ivRGnEOZ4Cp1GvqhThOSUk+JD9d6YrDkD2q3PpV3YSDCrtAB1
ImlzyLwznpu5YrqLI5GtMRqp8dwyoGYVag0S0yeEulFRrFEDmaoyrqlUKJKDs4QcFvqeHmjw
IMyWDcHcIdnMYFgirefrLLg3Xd6aZT4ZDF1aK2vlUWNQrdVBusIC/oSwcMx/bRRqIud3mRU8
p1QzpdEZccb1k+WDIxh6CjFpdtKiGhopYM4jbTb3mZH/lKdpxnMYXTiiWx8XWeKQPDBGxsQg
nsVNA4UYjbv29wWS76dtQcj4deSNaHXT2ovvNNmxWkARj4imIH9qBKBH2sMn4zfDJUW3kdmz
o+cPYxv6wGBEjJgs18xPRrPU1anZMs7HNP/Vstpz67Wzjqu6R67CqJbt2olqdDQqdl8dtF1X
tQ5U/ajWPnSLmK7tYgq7LMTIWgVAqhb9Jv/Zrjp12yeNbhdK27tUtdNTKLy2d+yq49oFjKb7
a9097aqLI7fptLD4iwa0p9OtYYZGU120G91G85AKRCBuu3F41FVHrWOMq4gg3ArUThnZD9rt
ONCO88Z+tlO5WgeanTOe2Lrx2Dn0yv650dwvKrdBBbm/nrbdDvTfgbIbJ9BiF142mvXjs30C
Au9BCc1WF8YJegbt7LZoaHRaXTo0Bsp35h24ETn8BR7cNIRQCAx4u9H5WdU6jgzsL2c1UxCM
LpRxUmvWaaLmJhK7qy5bZyg1oN/H+5jA0QlwoFy17x649W7jHKYXUkI1nbMTV8a706UBOj5W
TbcO7a21L1XHbZ836jgOTts9rTVg+BEj3W5jKa0m85b1Mk4eUIl7jjRw1jzG3rbdX86gP0so
AcuoHQK14WBa8+5cNKBynKH5yS9SFniRTv4lkFFLndQuGZh9KeQBzTTI7SxVAFGk1Fnba+EY
7EF7GtQsaAgOCE7Rfu2kduh2io4hAqpawORF1Tl16w38Au+B9GCuj3lUYBX9coazCA+kEFWD
6cSuIR3KlOEaRFprahqBuufXZT6te47+kC6OWx0kNqikW1PUYvi752LqttuE8aLlVKvXz9qw
tDAF5oDWdM5gsTWaNCkO9pdWc6O9r9cTjbM6qDWOz9oLNAY1t2AIsUiiNTMhmsg6hSLRgGoc
QFX1I5k9lVm1l+oIpmLPhWS1/fMGch6ux4G10GnImLSkBBlHYmzkfQr9o/RLAPyI/a+NEZwT
vN9EIy7KgRrtSdnO2iUtAB5eItttgsojsi5BOhb52AfxOorGIKJFJ0rRlJaXm2D1RGRekxdI
MnFgJ8LGsmlipBBv8GTfjRsHNCmQZXqIGw1WfRjtTpIIvd8zEoEloXHbWQi/YTmEmiNjbUTU
fnHaMDuZeHLwlCpIBtKr9Uc2RsCI0IYo8QbYNWyxyX2rExPKj06a8I2ctJBbv3YZZT8URg6C
mnDnz+TkClT4RJS1FHJMQB5PhwawA1PoM3/S5HNGKciBVh+K8UqNI9oHESCH8HzU0SkfPZCP
YyKxfvnMexvHk/Jr3IA1AKugsuE5FRd9BTuQgQLB7zGkiEOAEDZ8l8qa96mezaB8KgAlPyk+
u1zrk4RYIRTlUwRZ0Yi9x4VZwVK+JNDK0gH42kArBBl5XKgVLOJxwVaMk9GXhluhHI8Pt8IQ
iT8dcMXWlqksDrnyp536HXRMJDOBjRNBUxrzX4IXsKslasw+wtXiKIQOsU8gbAAwaveIbZ8Z
yEYGolrUzFF7lng4jrFB9Y6CG2alDiEgIR2xpoTdKjJgV1hBvkCqDkPQsu9Yvdf0/eqn4rLF
nF3KC7l7sJ0QJ9LaXqd1DOrH8aWtOm8RSQg1UChw9S9yX71fLaerYp4dpIKHJIE/wnpwXOe4
A5UgzlTGgKT3ZFt2db1VuyFlxq4MZ2Pc6dFBVwr71u2jNpjcQr7a9TbjXpLZSD7ogNYa0NmK
HIek9dHZcYJmzhlaOPDQjY6EYaNGJgbL+2lp08SZiU31tPyvfOc2giJLPWjBDVk2bv1wCgPm
3yalErJx2k0n04CPdo3Tv7iRSGcJnYf+yJQEF0o0g2x57fpu8MiS+9aPC4qduWMnwT38iA87
Qoa042kzetKl1rnUByeXuqpo5SMYOCH6yifssnkkUHUPgRSwZrcYRkV5kEzZ4eIymkX9Wejr
qEooEK9mpiIGCKUNoBWC6olwYKkcCvqXReereEJGoEFYjQn79CZKoCqIhEkKxqoGlf0ntkYd
eb0bPyYOuM1YEvT+BirpzmClReFuUVVBUYuDEcUiQY2FXxQxZEcSaCevc6AgMe0+wHWNoUWO
jlIjB9KPPb9k3nAsV9j0tgutCsY2K/LwlDaO8JDa3B1grDSOBoiTiyZyfRZVdP7ILQEtg+Bd
do2WaT0xwBRHCtdWJGYK9xonqv26+6DNaReaJeEunOXhLhatm393LJtvn6//LIv/yEHZn66O
T8d/qq7/uPajif/4UuL//7jxLf7TX/GpPHNWMpH6ayZSGlCE86cDQK44TxP+8WmiPz5B8Mcv
iv24pNdfuyF5bODHR8Z9/Lqwj9Dfx+9CHhXz8REhH59VHOc7AfiCMjEBui8Pd61HeGlQ9om+
j2c3mxHEbPYZqHdAJfjMemjCRdJzucBHgQp5q37fb6AZFO2A5267435ES6S7RboAxSOL1bPW
aReNkc1DjM7YD0abw/MPuS3H4be3MwL17qjm2fExPrVy6viPmFH9zuSbfFRv2MTyVr3p+3j8
RoP49rcw95uTa8n5BUV5gmZ609EkKWzyy1Jf2Z99gr7grKFaiYpJXnIUJH2QSd8Icb34VgZJ
NlJvwrcmWQdU5KspHTOO/PB6QidNmGAQkyaYf/XyWXVt/aWu5EOmkiOP3C/ZYiQpzjMpTsl3
UJaupBguSUEkeYsK8zUbcDCoJB4UY+PRIDTjzL/h8dt4+v4/YCjLAdYJ04AgWufUgz1qXuaJ
Cyo4v4NqSu6Lg7zKfZ9squ+T3/AMkieyqGssbDkcITxfqsL3j1IkRSjNY/OoqBUpSUcu/T6B
f1ZhmgKgBIqJmfetsnj+8rwFfsZDXlS1AxpnOjFXsLb4dY8bTq7TPXk2GgNhwdY+pr/YXnkO
j6C+TEEBjMlKAku9N8xDWSsr0PYVPG9X1U08b0IWkw+oHBWobQXMOXj+vEDRMX+n/1dG8JYb
+SZ4q0pQ/Za8GGfeyNP0wY4a8TOKg3oV+97Nlq59fXntz3r45fmOWv+yJsTWC/VcVfFl/On2
xeP5PA833Dx7XsWn8bLuyNKj/jDh5epeuIpo6bCPfpXGWWmdLL2hD4w8h4QBBWmSkCX6f4cm
skO7g/U/Tx881bR/SS1LJhSnyk5pzfLTzh3wAAex7cQYvPi6VxQJAN/v3rwlTsEPghAFEW7w
i+oZ6BT6FxSFkofsWtBsFkvwkLzmxxOcSJg7SCwt4nKKSoqYn1rucRJ8wMKEXxeZgdcxQVHA
+ITdDjk3OgT5k+lYjHMd/J4SkNCiNIltFgdkKyzKr4ugPxkW9fhQNZKaBXBffg0kF1aov4s0
wOr60ZSQyjHjtWZIpEbI0niuvcVnlQoqVB089Tw5wUOk40bTdVbuh3jokM/DoEF61gfyPCWY
uaiMOC8U1D92lNs60KSv1wLksMmPCHa1v7rJZDY/Qys2IenUwVxqUS8eSj7SyTPz5k2iABsD
7S48lPNc59SCKLONAMGmc5L0WVtSjk37Kyss30jkLa9wuJpJuaxETvjB9Gn+zaa84V//XF1e
Na7QjyuGQymaRGDrqEaF/Qy7WqMS9Ag0QjItUyA9jl8kaywh9zK/XzbDkq0yy6KqmUJbjymK
uV269DUhc1eYI1m8IPv6ubCspcxKN+/Ci3Etb5Jl0IvJVRMDC9z6EwwQa1r5uDZ83MKNB5eB
CQatsR8ewI+8zdZyMShAqA1jlSnLoQyH/uTAPMlrJlY7eLfvHtTOjrvvuu1a/WfMaLMRnbUu
rPeTGSllx+JPD6Yuqh+yfOwHi5FR4w2HMo0PFkr9QXgX91aYlk7fhm3qp1qLbEzPIQ0V4yxB
keyTUpoOHyWGfVneaiPyr+or9e9/Z/gxPoWqOrWT04MTqOqi1QEWeYorJpVtWrKJyxSUcgXK
9Wn9RALwIIITJZziSjOzscviebGwW3J8jzH6ZuxHCyXBlmyg3u01Dt+5zf1GrfnuqNXpvsMZ
A1lzHsSTqTfam038FnprfGLW4MneZddttfH+ViiOS4MB+o6D4T+qPNi6d49dq8iwHwxg6C2h
SJPb9O+RGOhBnukO79K1CMTKYQu7NC0RRybVYtsMRaXZzCr4TFZ7zjC3rO7swrWWPKzc+1zR
lv5cJ+77065mXztKbxV3lFZaC+ifG/Xylix7lmkM/MSn0YBzFArEVkT4osDMMHcWtKm+aBQX
qDJdHlupQgP0uWb/LO2oMKNOhthYO3na0sI/rR+baSEi5LxB2/f6xMEeZkJFpdX2UAtH/l/2
e+bt4hRxHRdodZFKZH6+pJYlaraoHf8fBk/vjP4nR+8j0qE3qI+ixLdXB6+D9DE3nnbyf9r+
O2f/v/fufLz+aTi5HT2Zjfkz9z/9SHc+0f0PG2vr6y/x/sdq9dv9j3/JZ/sf/ahHR/o45dqD
KFeqVO5f9CqV/qTPL16W1zi8IcEAvFGl4oe5XWcbX+IfWFKEXdoGVc+DLJNxiZz5d3J1DsdZ
6kIlOR2ccyc38d9PKph7i/aosOXbCZKo9Pr1xk+las4qi2+NYchkt9W2ijgBwh2NvMrL8oZ6
44dvVf7XanVLNbbUcRBO36v18lr5xSsVbLx+VVBvmv4EdNKx/xabXeEGb5ObBjZlJ/fdGn1y
6uq6F42iGJ7U6wfwIVjYjSRw4eed/AYqff3azSlPfh8cUAG7jrPdQ5+sGAemij+Hsbpo7HeP
dnKwFr7P7W4PoA9KV6Pz6bW4XcHXu9DIKvynizKFZjPX65yZnyLL23le3a2B2t278SR6JJQ5
Jsg3VuBIaEPo1WQyQhzhBEo1ddKfJS027fghvErGW/b/AsKSCiXOTZLqdKjSUdWMxMtPw4K0
yJHoPBRuKyFvNoUIjUiiGVH8Fu0V9sfLte8pbFWQ3Ci6mIi8sHXQTQcR+AVQQQkyTwVvT3dD
uXKaQAXongLUu12Z7krEZR1RxYra54RRBn8E7Dbhkxs+mqCwFCY2H55I0IWpYwk7qQ90JIYc
gmB0ZBvtRwXqqVyPrf4LdEP0/WO3pQG7kAryH32S6EINCdRsYBvYGsJD3k45/KhleqeYIbMQ
YZtBkkEF0F0C4rU674lHkdthv2YoZRJFo0Tlr+E3yCj4f72oxjf0Sw9kwRlRZEcEZ1KE5wjj
N/gJnhSo/B/VDWuyeE4itORDxrKzPbbptVTdXUJUjYEaBtdDhJEsjBVFL9CORUVHN0nC4XiT
RKIMwgRPSxj4AIelRt80HiYakz/ryal7+ELC9DkSdAaPJKc9X7ve3ZgYY0x0maCC7DdukTf6
pTv3PkbMoEUW3VPQbTypw8iVZmcmx5zQ7Gg0ZVcfnJ+czEBOsa8ZR2WXgNCCxuUVwu4x+WiA
+BicgQKPV2y8bDWxIgmh5XCAYa4I0sZe/xjlCSopm0U/XjYP2KrtqwWWVa+/eLGEZV3t0rqW
RYx+oL4EEAgokokfBzhwQLQDrwcbTCtap9SX45PQHB665oTCc+STl0jQHtpkist9SJguwkHn
UDAA44+mePRhYjIPfUf7EPWI29375HPGxViD5d8F6AoLqzNltcHu9mSy28+HBdA3O/inhH9K
1cJ2ZYL9DSzOSJGvaTqSW3JQh6Gbrca+5rR+yL6yBPfG29XoRJhC9FwFfM0Fh5CQCIWJeLbT
ea/E3uzPQB6ChDZuueSoiwevFAgKb47AsGSwxK7iZbPZidBhyWCMMDd0Mh2ghIgY+yXMh3ga
QrfFR3AJM1P5id8bhhLZgu6zIYMuu/TyDDsUp4cKE1MGnnPj4X7C1w8keI6bsCQwPl+jWYHS
ERqthEG1aEgcmRecEDMPDrm/ZqPfWxNvTaXJAg1HUHcQJ9qUjGsF1PgIlpPfL5T1tQJMGcY/
PCM1Ah4yHepTRAEuV8ew1Tsv5liicpIJLYo4rp4sZY4ojzyLxbFhpEgTzvyAl9FVVbBXqOgY
N3AvDW31NUvW0VG30vVKPB+ZJYqAB6npa3mDo5UE8sWTcBlX6MNYTxGKOE0GkkJzVZTqdIAM
IJIJUCb6uDLpi5PAPBnT4qYLiXDT5jEAFkkDr2YZIo+WjhcdUyk1GH5Q+FbzlET8YlskpgtU
pwWnROiiICs4OrhtcDSN4wKRoAB27SQP64xcZRcClODe+80HOPLiAKmsNF0843feoPnen7w1
vH75hC4Mw1zJ1p2XX1pSOnRLy9K3aX9aCLELxufaIuBK0jsd1ju1KVHp6ZyvdaKzUSq91mGy
eCE7SJ36Vtz8xNwhQ54j5X756sM6Sir6fv0hx6FmyQ5bVjWY4tT6jddSJaDDQD+uYu/Gn7AE
w0n38L5KogJaUAtz8AApZqmItBSESN0iSBUjzpGeLwK2Mrkdp3djcl2I/NzEKExT8tylATDt
T9iainYTuo4A/XRvKXYaRQih71vM4UoI4PENfApbe3jWYKaxuJOgxweihpmhZTpNigbkTzwM
dpKxP9jJIap/Em1mABbIYBA+v13xdrkukxwDK78nG0Zu9wjUA0lSwd0ebf5o0/p3b73/V3zm
7D+NZqdbOz5+2jo+Y/+pVteqBv+5sYb2nxcbGz9+s//8FZ/Sgx+nlrkMXAlpEJtwPpHN6UYa
wZ8uby7CCtwpoE7WXxAKyrfqwaI/CXpDzx+p03gKqtBqogyb11h5lUf70malcn9/X371+qYc
xdflyh+3nLFi0lcK1gUeVD75Xmg4Igpv4DYDBdsv2liKC8ZcIGmM47OK6YLraeyXg3CVVFLQ
M28Iipq+Wy2w55EJIxGQBQNDL96ZewnsBZcyZN6GzMboTKTb5ZiCOayA4zStSwspGhHHF0q9
/c39fOTCRHd8QJkO55eRdxwd0NJEYYAHlWkSV0YRaCh4Hzz04yGAr9rOcOHdv5uAv30e9Zm/
//mo1jx0O09bx2f4v9p4+crw/xcbVeL/1W/4/7/k8zAjZ24uBGF27iorFT4hCEQaPPxq396t
4V7ugg+fNj+Rp2Sqn6KzGAiEVDqQKc780tqrUzrVfnRkbhmP0KGxrn7IaM+ONNSxeuWUWnrP
zTsIaOsqXviBQbL75IJnQE4DxMM/zDT/7ln+9vn2Wf75b0dweuoAoAAA

--------------CA044C69D5789099C204F684--

From - Tue Jul 20 22:20:42 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA30861
	for <slinkp@ulster.net>; Tue, 20 Jul 1999 10:57:05 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA04342 for linux-audio-dev-list; Tue, 20 Jul 1999 09:55:58 -0400
Received: from maelzel.ircam.fr (maelzel.ircam.fr [129.102.1.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA04339 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 20 Jul 1999 09:55:55 -0400
Received: from luc.ircam.fr (luc.ircam.fr [129.102.1.64])
Received: from ircam.fr (linotte.ircam.fr [129.102.1.213])
          by luc.ircam.fr (8.9.1/jtpda-5.3.1/ircam) with ESMTP id PAA15471
          for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 20 Jul 1999 15:54:21 +0200 (MET DST)
Message-ID: <37947F8D.F6683B91@ircam.fr>
Date: Tue, 20 Jul 1999 15:54:21 +0200
From: Francois Dechelle <Francois.Dechelle@ircam.fr>
X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686)
MIME-Version: 1.0
To: Linux Audio Development Mailing list <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] [ANNOUNCE] Ircam releases jMax under GNU's General Public License
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by maelzel.ircam.fr id PAA22629
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id KAA30861
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 516c9510ca70bae178114fbbdac8c242

Paris, France (July 20, 1999) -- IRCAM announces the distribution of jMax,
its software environment for music performance and real time digital audio
processing, as free software under the GNU General Public License.

Since its first public release for the SGI and Linux platforms in early
1999, jMax has reached several hundred users that expressed high interest in
the product and its development. This interest, added to the rapid growth of
the Linux operating system and the effectiveness of the open development
model, created the conditions for an opening of the jMax development.

By releasing jMax under GNU's General Public License, IRCAM brings a key
contribution to the computer music community and to the adoption of Linux
for the multimedia market.

jMax is the new generation of real time systems at IRCAM, designed to
replace the Ircam Signal Processing Workstation. Based on a client/server
architecture, wherein the two components are the C written real-time engine
already known as FTS and a Java graphical user interface, jMax features a
high portability level.

jMax is currently supported on SGI workstations and on Linux for
Intel-compatible processors. Porting to other platforms are under
development, including Alpha-Linux, Linux-PPC, Solaris, Apple MacOS X and
Microsoft's Windows. Compatibilities with Max/MSP (IRCAM/Opcode/Cycling'74)
currently running on MacOS will be pursued.

Support, documentation, tutorials, CDROMs and musical applications for jMax
will be provided by the IRCAM Forum, the IRCAM user group accessible via a
yearly subscription. IRCAM Forum can be reached at
http://www.ircam.fr/departements/valorisation/forum/index-e.html.

jMax is currently being developed at IRCAM by the Real Time Systems team,
lead by Franois Dchelle, with Maurizio de Cecco, Enzo Maggi and Norbert
Schnell.

jMax is currently used in concert and in studio, at Ircam and on
international tours, for productions featuring real time audio synthesis and
processing, as well as for virtual reality interactive installations that
combine image and sound synthesis.

For more information and download, please visit IRCAM's Web site at :
http://www.ircam.fr/jmax/

IRCAM (Institut de Recherche et de Coordination Acoustique/ Musique) is a
non-profit organization associated with the Georges Pompidou National Center
of Art and Culture, Paris, France. Since its foundation in 1969 by the
French composer and conductor Pierre Boulez, IRCAM has always been a pioneer
in designing real time systems for live interaction between instruments and
computers. The first generation of systems lead in 1981 to the 4X processor,
designed at IRCAM by Giuseppe Di Giugno. In the 80s, Miller Puckette started
developing at IRCAM the Max software, a visual language that brought a new
concept in musical interaction. Max, licensed to Opcode Systems Inc., CA,
has reached a wide audience in the computer music community. The IRCAM
Signal Processing Workstation, designed in 1989 at IRCAM by a team leaded by
Eric Lindemann, has been adopted by a large number of composers as a choice
platform for real time interactive musical pieces.

Contact : Franois Dchelle IRCAM 1, place Igor Stravinsky F-75004 PARIS
FRANCE

Fax : +33 1 44 78 15 40 email : jmax-info@ircam.fr

----------------------------------------------------------------------------
(C) Copyright IRCAM-Centre Georges Pompidou 1999, All Rights Reserved
Max, jMax and FTS are registered trademarks of IRCAM
All other trademarks are the property of their respective owners.

From - Tue Jul 20 22:20:46 1999
Received: from fep10-svc.tin.it (mta10-acc.tin.it [212.216.176.41])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id QAA08028
	for <slinkp@ulster.net>; Tue, 20 Jul 1999 16:37:56 -0400
Received: from tin.it ([212.216.171.180]) by fep10-svc.tin.it
          (InterMail v4.01.01.02 201-229-111-106) with ESMTP
          id <19990720202818.FJTI4802.fep10-svc@tin.it>
          for <slinkp@ulster.net>; Tue, 20 Jul 1999 22:28:18 +0200
Sender: umberto
Message-ID: <3794DA4B.61610E7E@tin.it>
Date: Tue, 20 Jul 1999 22:21:31 +0200
From: Maurizio Umberto Puxeddu <umbpux@tin.it>
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Winkler <slinkp@ulster.net>
Subject: Re: audiozip [was Re: wavezip]
References: <3782EEF5.1685313C@ulster.net> <3782FC42.323FFF18@tin.it> <3783FCD7.7FAE6EEC@ulster.net> <37875EB4.B9A5393A@tin.it> <3793A2EC.7B2ACF54@ulster.net> <3793AC70.E47C1539@tin.it> <3793C37A.DB764514@ulster.net>
Content-Type: text/plain; charset=x-user-defined
Content-Transfer-Encoding: 7bit
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: fbb3659513e1f87849c9821fef7e800c

Paul Winkler wrote:
> [...snip...]
> What I've found is that audiozip (using bzip2) compresses almost as well
> as shorten, and much better than anything else I've tried. It's also
> very very slow (largely due to bzip2). Audiozip using gzip is still
> pretty good compression and much, much faster than bzip2 (but still
> slower than shorten or plain gzip). Audiozip is GPL and shorten is not,
> so it'll be interesting to see where you go with this. If bzip2 speed
> can be increased, and audiozip optimized somewhat, that would be very
> cool. [...snip...]

Unfortunately, I don't think I'll hardly make major improvements in the
near future. I think that including very few lines (the so-called
"audiozip method" is so straightforward) of code in bzip2 and gzip we
could obtain the same results saving code, headaches and "chewing" time
(the latter being in fact almost exclusively hard disk I/O time!). So
I'll contact the bzip2 and gzip people.

Finally, it's likely that a better tuned (or auto tuning) stand-alone
variable length encoder could achieve some more percent of compression.
I'll do some estimation to see if it's worthwhile.

I'll keep you informed.

Thanks for your time.

Maurizio Umberto Puxeddu

From - Thu Jul 22 02:57:21 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA28077
	for <slinkp@ulster.net>; Wed, 21 Jul 1999 12:37:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA10003 for linux-audio-dev-list; Wed, 21 Jul 1999 11:45:50 -0400
Received: from gate.fzi.de (gate.fzi.de [141.21.4.3]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id LAA10000 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 21 Jul 1999 11:45:44 -0400
Received: from prost1.fzi.de by gate.fzi.de with SMTP (PP);
          Wed, 21 Jul 1999 17:42:30 +0200
Received: from fzi.de by prost1.fzi.de id <26768-0@prost1.fzi.de>;
          Wed, 21 Jul 1999 17:42:20 +0200
Subject: [linux-audio-dev] Q: OSS, MIDI and pipes
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Wed, 21 Jul 1999 17:42:18 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL2]
Content-Type: text
From: Stefan Nitschke <nitschke@fzi.de>
Message-ID: <"prost1.fzi.953:21.07.99.15.42.26"@fzi.de>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 45957d6bd7f2596d9568d82fb57003b1


Switching to a linux 2.2.5 kernel, I noticed that there is a midi
loop-back device. Unfortunately this device can not be used to connect a
midi sequencer application, writing to /dev/sequencer, and a real time
synthesizer, reading from /dev/midiXX.

I think such a functionality would be very nice and should be very simple
to implement by using a native unix stream: a pipe.

The idea is:
Every time a midi byte is send to the hardware midi device it is also written
to a pipe (for example /dev/midipipe) if this pipe has a reader (basic unix
functionality).

The stream of such a midi pipe could than be duplicated by a standard unix tool
like 'tee' in user space to have support for more than one connected
application ... a plain unix concept -> highest flexibility and lowest overhead.

I am not sure if this works perfect. AFAIK the OSS sequencer does all the
midi output timing and the midi device on soundcards is just a simple
UART like device without any special timing capability.

The problem I have is:
How to open and access a pipe from within a kernel module? 
Is it possible with linux? Any problems with signal setting stuff when
using pipes within system space?

Has anyone suggestions?


- Stefan

From - Thu Jul 22 02:57:23 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA31835
	for <slinkp@ulster.net>; Wed, 21 Jul 1999 13:05:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA10042 for linux-audio-dev-list; Wed, 21 Jul 1999 12:09:05 -0400
Received: from mito.dialup.access.net (mito.dialup.access.net [166.84.203.204]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA10039 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 21 Jul 1999 12:09:01 -0400
Received: (from mito@localhost) by mito.dialup.access.net (8.7.6/8.7.3) id MAA00963; Wed, 21 Jul 1999 12:06:23 -0400
Date: Wed, 21 Jul 1999 12:06:23 -0400
Message-Id: <199907211606.MAA00963@mito.dialup.access.net>
From: The Mitochondrion <mito@panix.com>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] midi on a laptop
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: a98ddecad66da9503640acf91d7c96d4


Sorry if this is a FAQ, but I haven't been able to find any conclusive
information on the web.

I would like to set up a laptop that can work with midi -- receive and
send midi data to and from external devices.  I have software that
uses the OSS/Free libraries, so I would ideally like to use OSS/Free,
but in reality I am willing to code to any API as long as it works.

I don't know if I'll be getting a laptop that has a game/midi port, so
I might have to use a midi device attached to a serial or parallel
port.

Has anyone does this?  What drivers are used?  What devices do those
drivers work with?  I would greatly appreciate any help.

Thanks,
Greg

From - Thu Jul 22 02:57:24 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA15820
	for <slinkp@ulster.net>; Wed, 21 Jul 1999 15:00:53 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA10182 for linux-audio-dev-list; Wed, 21 Jul 1999 14:09:44 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA10179 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 21 Jul 1999 14:09:38 -0400
Received: from bright.net (find-cas1-cs-41.dial.bright.net [209.143.26.144])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id OAA11124;
	Wed, 21 Jul 1999 14:07:52 -0400 (EDT)
Message-ID: <379611AD.33EBB644@bright.net>
Date: Wed, 21 Jul 1999 14:30:05 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: The Mitochondrion <mito@panix.com>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] midi on a laptop
References: <199907211606.MAA00963@mito.dialup.access.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 247e6a45f8f98da962c5a22751575da6

The Mitochondrion wrote:

> I would like to set up a laptop that can work with midi -- receive and
> send midi data to and from external devices.  I have software that
> uses the OSS/Free libraries, so I would ideally like to use OSS/Free,
> but in reality I am willing to code to any API as long as it works.

Check here:

	http://linuxlaptops.com/ll/

here:

	http://www.cs.utexas.edu/users/kharker/linux-laptop/

and here:

	http://www.bright.net/~dlphilp/linuxsound/drivers.html


== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Sun Jul 25 03:15:23 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA23900
	for <slinkp@ulster.net>; Sat, 24 Jul 1999 09:50:14 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA26338 for linux-audio-dev-list; Sat, 24 Jul 1999 09:18:56 -0400
Received: from gate.fzi.de (gate.fzi.de [141.21.4.3]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id JAA26335 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 24 Jul 1999 09:18:53 -0400
Received: from prost1.fzi.de by gate.fzi.de with SMTP (PP);
          Sat, 24 Jul 1999 15:17:02 +0200
Received: from fzi.de by prost1.fzi.de id <15119-0@prost1.fzi.de>;
          Sat, 24 Jul 1999 15:16:54 +0200
Subject: Re: [linux-audio-dev] Q: OSS, MIDI and pipes
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Sat, 24 Jul 1999 15:16:53 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL2]
Content-Type: text
From: Stefan Nitschke <nitschke@fzi.de>
Message-ID: <"prost1.fzi.806:24.07.99.13.16.59"@fzi.de>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 17d8558e453a1b7aadc167b52989232d


Jay Ts wrote:

> 
> I had been thinking the same idea about a year ago relative to the /dev/dsp
> device, and quickly gave up on it.  The problem then was that the finite size
> of the fifo buffer, added to the overhead of going through the filesystem
> driver, resulted in delays that were not acceptable.
> 
> But that was back with Red Hat 5.0, and perhaps things are different now(?).

Sounds like a bad pipe implementation in linux... Anyway a MIDI device sends 
at 19200 BAUD. If this would be too fast for linux pipes we should really try 
to get a better unix implementation ;) 


David Slomin wrote:

> 
> In user space, at least, you create a pipe with the pipe() function, which
> I thought was a system call.  You then open it and write() or read() like
> a normal file or device.  I'm sure how to control the buffer size and
> whatnot... it'll probably require careful use of select() and possibly 
> ioctl().  Sorry for my lack of kernel-level programming experience.
>
 
Pipe() is for sure a system call. I did a lot of kernel programming on a unix 
edition 7 like 16-bit system several years ago, but have absolutely no kernel
programming experience with linux. 
So again can someone tell me how do use system call functions from system 
space?


- Stefan

nitschke@fzi.de

From - Tue Jul 27 16:38:48 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA08012
	for <slinkp@ulster.net>; Tue, 27 Jul 1999 11:54:32 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA13503 for linux-audio-dev-list; Tue, 27 Jul 1999 11:12:09 -0400
Received: from upf.es (newton.upf.es [193.145.54.60]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA13499 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 27 Jul 1999 11:11:47 -0400
Received: from harrison.upf.es (harrison.upf.es [193.145.44.1])
	by upf.es (8.9.0/8.9.0) with SMTP id RAA07985;
	Tue, 27 Jul 1999 17:08:44 +0200 (MET DST)
Received: from mtg150.upf.es by harrison.upf.es with SMTP
	(940816.SGI.8.6.9/16.2) id RAA07889; Tue, 27 Jul 1999 17:27:50 +0200
From: Maarten de Boer <mdeboer@iua.upf.es>
To: Dave Phillips <dlphilp@bright.net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>,
        Csound Linux Development Mail <csound-unix-dev@ilogic.com.au>
Subject: Re: [linux-audio-dev] What do we need now ?
Date: Tue, 27 Jul 1999 16:51:49 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <379DC861.A2828F74@bright.net>
MIME-Version: 1.0
Message-Id: <9907271714410M.13494@mtg150.upf.es>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 8ab0678d529dfc5ffc3a2ff34ab6fa9b

>   So what do you think we need ? More organization ? Does anyone else
> feel that there might be too much re-invention of the wheel ? Can we
> coordinate efforts in some better ways ? Let's put it to ourselves: what
> software do we need and how shall we go about getting it ?

Apart from the suggestions you make about the development of the specific
software (which I fully agree with) I think it would also be good if there 
would be a linux distribution that would install a linux audio workstation.
I don't think the audio software available belongs in a standard linux
distribution, and there are a lot of things in the standard distributions 
are not wanted and needed by somebody who wants to use linux as an audio
workstation primarily. Also, having such a distribution would contribute
to a necessairy 'survival of the fittest', and it could take care of this
extra development it takes to make good software usuable software (docu-
mentation, easy installation, clear bugreporting)

I know a of people how want to use jMax, and have PC's, and are open towards
installing linux (and have even tried it), but are scared away by it. I am
sure that if they would have a linux distribution that would install all they
need for an audio workstation, they would use it.

What should go in such a distribution ? How much effort would it take to 
produce it ? Would should be taken as the base for such a distribution ?

Maarten

PS: it is not the first time I do this, but I would like to urge people to
use FLTK for the GUI of audio software. Fast, small, no bloat.

--
maarten de boer
mdeboer@iua.upf.es
http://www.iua.upf.es/~mdeboer

From - Tue Jul 27 16:38:45 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA05112
	for <slinkp@ulster.net>; Tue, 27 Jul 1999 11:33:33 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA12628 for linux-audio-dev-list; Tue, 27 Jul 1999 10:38:09 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA12625 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 27 Jul 1999 10:38:05 -0400
Received: from bright.net (find-cas2-cs-27.dial.bright.net [209.143.26.181])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id KAA27487;
	Tue, 27 Jul 1999 10:35:52 -0400 (EDT)
Message-ID: <379DC861.A2828F74@bright.net>
Date: Tue, 27 Jul 1999 10:55:29 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>,
        Csound Linux Development Mail <csound-unix-dev@ilogic.com.au>
Subject: [linux-audio-dev] What do we need now ?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8003
X-Mozilla-Status2: 00000000
X-UIDL: 995b49609cb52c4824fd873f3efab806

Greetings:

  Since traffic is slow here these days I thought I'd throw out some
random thoughts and maybe light a fire or two.

  As I write my book I've made a few observations which might be of some
inteest to developers. To wit:

	1. Linux needs a 1st-class MIDI sequencer, preferably one with support
for syncronized audio sequencing. Jazz++ is pretty good, IMO, but its
interface is definitely showing its age. Ditto for Rosegarden, and I
understand that both applications are still in development, including
interface design. If the developers of those progs are reading this,
perhaps we could get an update on your progress ?

	2. The Linux sound & music software world is almost hilariously
lopsided. At the same time I complain about the dearth of full-blown
MIDI sequencers, I can point to an amazing number of software synthesis
languages, some of which (Csound, RTCmix, CLM) have impressive GUIs
(Cecilia, Snd). Then of course there's Quasimodo (how's it going these
days, Paul ?), Silence (new version soon ?), jMax (we've all heard the
good news by now), and HPKComposer. This is all major music software,
impressive even to the Windozers.

	3. Still no (or just too little) support for pro-audio cards. I have it
on good authority that that situation will change later this year, but
the wheels do turn slowly. We still need to make manufacturers aware of
a potential market, and if possible cajole them into open-source
solutions.

	4. How about a MIDI loopback device ? Anyone working on anything like
Hubi's virtual cable ?

	5. The whole situation wrt MIDI is strange. We have a lot of pieces to
the puzzle. We have WaoN, a WAV-to-MIDI converter that needs more work;
we have a bunch of small progs and a lot of utilities and programming
tools; we have kooBase (coming along now, but it still needs input and
testers); and we have the Gseq project. kooBase looks like a contender,
but again, it has a long way to go. If Jazz++ and Rosegarden do improve
their GUIs we'll be a lot more attractive to prospective Window-jumpers.

	6. Soundfile editors are still not up to par, although recent advances
in Snd and MiXViews brings them closer to pro-level software. Simply
put, we need a Cool Edit Pro for Linux. How's it going to happen ? As an
aside: I'd like to DAP fixed to accomodate large files, can anyone take
on that task ? DAP is otherwise quite impressive.

	7. On a related note, we need more or better hard-disk recording
systems. SLab is okay by me, but many are put off by the interface.
KHDRec is still under construction. Multitrack's developer seems to have
simply disappeared (does _anyone_ know how to contact Boris Nagels ?). I
like using NoTAM's Mix, but once again its X/Motif interface is showing
some age.

  So what do you think we need ? More organization ? Does anyone else
feel that there might be too much re-invention of the wheel ? Can we
coordinate efforts in some better ways ? Let's put it to ourselves: what
software do we need and how shall we go about getting it ?

  Btw, thanks to Nicola Bernardini for maintaining the Linux Csound CVS
repository !

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Tue Jul 27 16:38:51 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA10374
	for <slinkp@ulster.net>; Tue, 27 Jul 1999 12:10:39 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA16621 for linux-audio-dev-list; Tue, 27 Jul 1999 11:28:19 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA16611 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 27 Jul 1999 11:28:16 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S44268AbPG0PZp>; Tue, 27 Jul 1999 18:25:45 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca,
        csound-unix-dev@ilogic.com.au
In-reply-to: <379DC861.A2828F74@bright.net> (message from Dave Phillips on
	Tue, 27 Jul 1999 10:55:29 -0400)
Subject: [linux-audio-dev] Re: [CUD] What do we need now ?
Message-Id: <19990727152555Z44268-2248+2097@nic.funet.fi>
Date:   Tue, 27 Jul 1999 18:25:45 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8003
X-Mozilla-Status2: 00000000
X-UIDL: ffe7ce699575d637b635d4e2e4aba02c

>From:   Dave Phillips <dlphilp@bright.net>
>
>	6. Soundfile editors are still not up to par, although recent advances
>in Snd and MiXViews brings them closer to pro-level software. Simply

Could somebody give a short explanation why Snd and MiXViews should be
considered as pro-level? MiXViews has problems in editing, handling large
files, playing, no plug-ins, and more.

>  So what do you think we need ? More organization ? Does anyone else
>feel that there might be too much re-invention of the wheel ? Can we
>coordinate efforts in some better ways ? Let's put it to ourselves: what
>software do we need and how shall we go about getting it ?

I have set up GNU Audio Software Project (GASP) webpages at
"http://www.funet.fi/~kouhia/gasp/". Any matter related to audio software
writing should be documented there: designs, implementation issues,
example codes. Software writers then could look at there and, for example,
take ideas there and save development and/or programming time.

To get an idea about commercial softwares, I have provided there an extensive
listing of software manuals available on the net. If you're interested in
to design GUIs and features, you could download a few best manuals for
getting ideas.

 -*-

In alsa-devel mailing list an other netter announced an audio engine
project last week. I think we need an audio engine so that audio
software development can move to GUI and other non-audio parts of the
software.

Yours,

Juhana

From - Tue Jul 27 16:38:50 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA09273
	for <slinkp@ulster.net>; Tue, 27 Jul 1999 12:03:29 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA15135 for linux-audio-dev-list; Tue, 27 Jul 1999 11:21:25 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA15124 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 27 Jul 1999 11:21:22 -0400
Received: from bright.net (find-cas2-cs-27.dial.bright.net [209.143.26.181])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id LAA28592;
	Tue, 27 Jul 1999 11:18:56 -0400 (EDT)
Message-ID: <379DD27B.C21A28D0@bright.net>
Date: Tue, 27 Jul 1999 11:38:35 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Maarten de Boer <mdeboer@iua.upf.es>
CC: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>,
        Csound Linux Development Mail <csound-unix-dev@ilogic.com.au>
Subject: Re: [CUD] Re: [linux-audio-dev] What do we need now ?
References: <379DC861.A2828F74@bright.net> <9907271714410M.13494@mtg150.upf.es>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b53e6e5ba621edd7f0937ae09176866e

Maarten de Boer wrote:

> ...I think it would also be good if there
> would be a linux distribution that would install a linux audio workstation.

There will be a CD accompanying my book, and we hope to include
everything profiled in the book. Unfortunately we probably won't be able
to include a version of Linux optimized for a DAW installation, but the
I certainly like the idea.

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Tue Jul 27 16:38:53 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA13258
	for <slinkp@ulster.net>; Tue, 27 Jul 1999 12:30:52 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA18345 for linux-audio-dev-list; Tue, 27 Jul 1999 11:47:16 -0400
Received: from maelzel.ircam.fr (maelzel.ircam.fr [129.102.1.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA18342 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 27 Jul 1999 11:47:12 -0400
Received: from luc.ircam.fr (luc.ircam.fr [129.102.1.64])
Received: from ircam.fr (linotte.ircam.fr [129.102.1.213])
          by luc.ircam.fr (8.9.1/jtpda-5.3.1/ircam) with ESMTP id RAA11779
          ; Tue, 27 Jul 1999 17:44:46 +0200 (MET DST)
Message-ID: <379DD3ED.5CC74D34@ircam.fr>
Date: Tue, 27 Jul 1999 17:44:45 +0200
From: Francois Dechelle <Francois.Dechelle@ircam.fr>
X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686)
MIME-Version: 1.0
To: Dave Phillips <dlphilp@bright.net>
CC: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>,
        Csound Linux Development Mail <csound-unix-dev@ilogic.com.au>
Subject: Re: [linux-audio-dev] What do we need now ?
References: <379DC861.A2828F74@bright.net>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by maelzel.ircam.fr id RAA03908
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id MAA13258
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 210099419946aeae509e68ed95d4910f

Dave Phillips wrote:
> 
> Greetings:
> 
>   Since traffic is slow here these days I thought I'd throw out some
> random thoughts and maybe light a fire or two.
> 
>   As I write my book I've made a few observations which might be of some
> inteest to developers. To wit:
> 
>         1. Linux needs a 1st-class MIDI sequencer, preferably one with support
> for syncronized audio sequencing. Jazz++ is pretty good, IMO, but its
> interface is definitely showing its age. Ditto for Rosegarden, and I
> understand that both applications are still in development, including
> interface design. If the developers of those progs are reading this,
> perhaps we could get an update on your progress ?
> 
>         2. The Linux sound & music software world is almost hilariously
> lopsided. At the same time I complain about the dearth of full-blown
> MIDI sequencers, I can point to an amazing number of software synthesis
> languages, some of which (Csound, RTCmix, CLM) have impressive GUIs
> (Cecilia, Snd). Then of course there's Quasimodo (how's it going these
> days, Paul ?), Silence (new version soon ?), jMax (we've all heard the
> good news by now), and HPKComposer. This is all major music software,
> impressive even to the Windozers.
> 
>         3. Still no (or just too little) support for pro-audio cards. I have it
> on good authority that that situation will change later this year, but
> the wheels do turn slowly. We still need to make manufacturers aware of
> a potential market, and if possible cajole them into open-source
> solutions.
> 
>         4. How about a MIDI loopback device ? Anyone working on anything like
> Hubi's virtual cable ?
> 
>         5. The whole situation wrt MIDI is strange. We have a lot of pieces to
> the puzzle. We have WaoN, a WAV-to-MIDI converter that needs more work;
> we have a bunch of small progs and a lot of utilities and programming
> tools; we have kooBase (coming along now, but it still needs input and
> testers); and we have the Gseq project. kooBase looks like a contender,
> but again, it has a long way to go. If Jazz++ and Rosegarden do improve
> their GUIs we'll be a lot more attractive to prospective Window-jumpers.
> 
>         6. Soundfile editors are still not up to par, although recent advances
> in Snd and MiXViews brings them closer to pro-level software. Simply
> put, we need a Cool Edit Pro for Linux. How's it going to happen ? As an
> aside: I'd like to DAP fixed to accomodate large files, can anyone take
> on that task ? DAP is otherwise quite impressive.
> 
>         7. On a related note, we need more or better hard-disk recording
> systems. SLab is okay by me, but many are put off by the interface.
> KHDRec is still under construction. Multitrack's developer seems to have
> simply disappeared (does _anyone_ know how to contact Boris Nagels ?). I
> like using NoTAM's Mix, but once again its X/Motif interface is showing
> some age.
> 
>   So what do you think we need ? More organization ? Does anyone else
> feel that there might be too much re-invention of the wheel ? Can we
> coordinate efforts in some better ways ? Let's put it to ourselves: what
> software do we need and how shall we go about getting it ?
> 
>   Btw, thanks to Nicola Bernardini for maintaining the Linux Csound CVS
> repository !
> 
> == Dave Phillips
> 
>        http://www.bright.net/~dlphilp/index.html
>    http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

Greetings,

Thanks a lot, Dave, for your initiative.

As you mentionned, we are now much involved in moving GNU/Linux 
to music and multimedia, and we will put our efforts into this.

I think that one important and urgent problem is the lack of
drivers for pro multi-channels audio cards. I don't know
if you agree, but I think that OSS has not helped progress
in this area because of the closed-sources, and we should
fight for open-source drivers. So what we can do here
is: show board manufacturers that there is an operating system 
that works on very powerfull machines (an 21264 Alpha server 
is rated at 45 SpecFP-95 and costs about 4000 $ !), has very
good latency performance, has a community of developpers,
has first-class audio applications (well, ...), in order to
have an ALSA interface for a set of pro audio cards (1 is 
enough, but 2 or 3 would be perfect). To help that, may
be a list of potential cards to support may be helpfull:
Here are some:
 - Mark of the Unicorn: http://www.motu.com/english/motuaudio/PCI324/pci324.html
 - Korg: http://www.korg.com/sndlnk1.htm
 - Sonorus (there is an OSS driver, but it is beta since
one year): http://sonorus.com/studio.html
 - RME: http://www.rme-audio.com/english/digi96/hammer.htm

There is another possibility that you did not mention, but 
that may become likely one day, which is that Steinberg
ports VST to Linux... They did "Nuendo", a new version
of Cubase/VST, that worked on SGI. So, doing a version
for GNU/Linux would not be too difficult.

There is something that may be worth considering
for MIDI. The GRAME (a french studio located in Lyon)
has released its "MidiShare" as free software. People
knowing it say that it is superior to Opcode's OMS. 
So, may be porting it to Linux could be usefull. It
allows multi-devices, has GUI for configuration, provides
a library for MIDI files reading, ...

I also completely agree for Marten's idea of a distribution
oriented for multimedia and audio. I was also thinking
of it, and I volunteer to work on it.

Let's go !

Francois

--
Franois Dchelle - IRCAM - `Real-time Systems' Team - 

From - Tue Jul 27 16:38:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA15130
	for <slinkp@ulster.net>; Tue, 27 Jul 1999 12:43:39 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA18581 for linux-audio-dev-list; Tue, 27 Jul 1999 11:58:40 -0400
Received: from mailhub2.arts.gla.ac.uk (mailhub2.arts.gla.ac.uk [130.209.96.13]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA18578 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 27 Jul 1999 11:58:37 -0400
Received: from music.gla.ac.uk (celeste.music.gla.ac.uk [130.209.97.23])
	by mailhub2.arts.gla.ac.uk (8.8.6/8.8.6) with ESMTP id RAA07638;
	Tue, 27 Jul 1999 17:08:31 +0100 (BST)
Received: from flugel.music.gla.ac.uk (flugel [130.209.97.30])
	by music.gla.ac.uk (8.8.5/8.8.6) with SMTP id QAA05379;
	Tue, 27 Jul 1999 16:56:22 +0100 (BST)
Message-Id: <199907271556.QAA05379@music.gla.ac.uk>
Received: by flugel.music.gla.ac.uk (NX5.67f2/NX3.0X)
	id AA00728; Tue, 27 Jul 99 16:56:14 +0100
Mime-Version: 1.0 (NeXT Mail 3.3 v118.2)
Content-Type: text/plain; charset=us-ascii
X-Nextstep-Mailer: Mail 3.3 [i386] (Enhance 2.2p2)
Received: by NeXT.Mailer (1.118.2)
From: "Dr. Nick Fells" <nick@music.gla.ac.uk>
Date: Tue, 27 Jul 1999 16:56:13 +0100
To: linux-audio-dev@ginette.musique.umontreal.ca,
        csound-unix-dev@ilogic.com.au
Subject: [linux-audio-dev] Re: [CUD] What do we need now ?
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id MAA15130
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: e1ce5068a29b00f9715d4afe05960947

Dear all, 

In response to Dave:

>  So what do you think we need ? More organization ? Does anyone else
>feel that there might be too much re-invention of the wheel ? Can we
>coordinate efforts in some better ways ? Let's put it to ourselves: what
>software do we need and how shall we go about getting it ?

Yep, I would say a more organised/coordinated approach (not that I know that much about it, I have to say: I'm an eager linux sound user, being an electroacoustic composer who unfortunately has to resort to W*****ws on a regular basis. I would like Linux audio to run more smoothly, to have better applications etc...but I'm not an established developer by any means). I would think the establishment of a recognised linux audio users/developers group might have some effect here. Such a group could coordinate development/testing/evaluation tasks, lobby hardware manufacturers, stress test kernel releases and work on solutions to latency problems etc...and would have more clout than individuals. Forgive me if such a group exists and I've just slipped on a banana skin. It just seems there are so many smallish development efforts going, when what's lacking are apps which have the reliability/flexibility/comprehensiveness of software like CEPro and Cubase (just to be clear, I use mainly Csound, which seems to be developing apace in the linux realm).

Nick

---
Dr Nick Fells,	
Music Department,
University of Glasgow,			Tel: +44 (0) 141-330 5509/6065
Glasgow G12 8QQ				Fax: +44 (0) 141-330 3518
UK.							http://www.music.gla.ac.uk/~nick


From - Tue Jul 27 16:38:57 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA20460
	for <slinkp@ulster.net>; Tue, 27 Jul 1999 13:22:19 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA18681 for linux-audio-dev-list; Tue, 27 Jul 1999 12:42:14 -0400
Received: from gauss.deltav.hu (gauss.deltav.hu [194.9.64.225]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA18678 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 27 Jul 1999 12:42:11 -0400
Received: from cerealbox (118.dial02.deltav.hu [194.9.64.118])
          by gauss.deltav.hu (Netscape Messaging Server 3.6)  with ESMTP
          id AAA75A for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Tue, 27 Jul 1999 18:42:52 +0200
Received: from reactor by cerealbox with local (Exim 1.92 #1 (Debian))
	id 119A5z-00003Z-00; Tue, 27 Jul 1999 18:28:51 +0200
Message-ID: <19990727182851.B177@cerealbox>
Date: Tue, 27 Jul 1999 18:28:51 +0200
From: reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] What do we need now ?
Reply-To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
References: <379DC861.A2828F74@bright.net> <9907271714410M.13494@mtg150.upf.es>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.91.2
In-Reply-To: <9907271714410M.13494@mtg150.upf.es>; from Maarten de Boer on Tue, Jul 27, 1999 at 04:51:49PM +0200
Organization: CTP media laboratories
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4047ede859f314246fee095b4da4a143

 >% PS: it is not the first time I do this, but I would like to urge people to
 >% use FLTK for the GUI of audio software. Fast, small, no bloat.

i think we should prefer GTK+ instead, because it's more standard.
every linux distribution has a GTK+ package.

you're right, FLTK is fast, cool, but GTK+ looks prettier (and that's
an important factor if we want to get Windozers away from their Windozes)

or we could use both. QT could be a good choice too (besides i don't like
it :))). just look at GreenBox, a nice drummachine made with QT. it has
real knobs like Rebirth. i don't know if we could make it with GTK+ too,
but i think so, and then the world would be ours. (unfortunately FLTK's
knobs are ugly... and today's "music" is mostly about knob-tweaking and
slider-sliding :))

and don't forget, we are competing with COMMERCIAL software, for which
people get lots of money (even though Radium cracks all of them), so
we have to bring QUALiTY in our stuff, or noone will take us seriously.

we need easy-compiling, good-looking, good-sounding, stable stuff, with
functions that commercial stuff don't have.


bya!


ps: anyone working on a Buzz-alike tracker?

-- 

 Rcz Mt - http://linux.gyakg.u-szeged.hu/~reactor/
 CTP media - http://ctpmedia.scene-hu.com/
  Hungary

From - Tue Jul 27 16:38:59 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA22718
	for <slinkp@ulster.net>; Tue, 27 Jul 1999 13:41:58 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA18725 for linux-audio-dev-list; Tue, 27 Jul 1999 13:00:29 -0400
Received: from upf.es (newton.upf.es [193.145.54.60]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA18722 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 27 Jul 1999 13:00:23 -0400
Received: from harrison.upf.es (harrison.upf.es [193.145.44.1])
	by upf.es (8.9.0/8.9.0) with SMTP id SAA13327;
	Tue, 27 Jul 1999 18:58:05 +0200 (MET DST)
Received: from mtg150.upf.es by harrison.upf.es with SMTP
	(940816.SGI.8.6.9/16.2) id TAA09127; Tue, 27 Jul 1999 19:17:20 +0200
From: Maarten de Boer <mdeboer@iua.upf.es>
To: reactor@sagv5.gyakg.u-szeged.hu,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: [OT] FLTK; was [linux-audio-dev] What do we need now ?
Date: Tue, 27 Jul 1999 18:58:06 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <19990727182851.B177@cerealbox>
MIME-Version: 1.0
Message-Id: <9907271904070P.13494@mtg150.upf.es>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: ee6300129fe14ee6d0e198cb9fc02554

On Tue, 27 Jul 1999, reactor/CTPmedia wrote:
> >% PS: it is not the first time I do this, but I would like to urge people to
>  >% use FLTK for the GUI of audio software. Fast, small, no bloat.
> 
> i think we should prefer GTK+ instead, because it's more standard.
> every linux distribution has a GTK+ package.

Yes, but incompatibility issues are very common. FLTK can be used
statically and doesn't make your app much bigger.

> you're right, FLTK is fast, cool, but GTK+ looks prettier (and that's
> an important factor if we want to get Windozers away from their Windozes)

The look of FLTK is very customizable, and it comes closer to GTK+ and
Windows look than to Motif.

> or we could use both. QT could be a good choice too (besides i don't like
> it :))). just look at GreenBox, a nice drummachine made with QT. it has
> real knobs like Rebirth. i don't know if we could make it with GTK+ too,
> but i think so, and then the world would be ours. (unfortunately FLTK's
> knobs are ugly... and today's "music" is mostly about knob-tweaking and
> slider-sliding :))

FLTK's slider is fine though. Smooth hightech looking knobs do not belong
in the standard widget set of a GUI toolkit. If you need one, write one,
which is really little work with fltk, because it's C++. 

> and don't forget, we are competing with COMMERCIAL software, for which
> people get lots of money (even though Radium cracks all of them), so
> we have to bring QUALiTY in our stuff, or noone will take us seriously.

I think for quality 'looks' are not the mean issue. Useability is at least
as important.

> we need easy-compiling, good-looking, good-sounding, stable stuff, with
> functions that commercial stuff don't have.

Yes!

Maarten

From - Tue Jul 27 16:39:01 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA30509
	for <slinkp@ulster.net>; Tue, 27 Jul 1999 14:42:47 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA18807 for linux-audio-dev-list; Tue, 27 Jul 1999 14:02:21 -0400
Received: from fep09-svc.tin.it (mta09-acc.tin.it [212.216.176.40]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA18804 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 27 Jul 1999 14:02:16 -0400
Received: from tin.it ([212.216.171.92]) by fep09-svc.tin.it
          (InterMail v4.01.01.02 201-229-111-106) with ESMTP
          id <19990727175959.WIJM9838.fep09-svc@tin.it>;
          Tue, 27 Jul 1999 19:59:59 +0200
Message-ID: <379DF1FA.8922DEE8@tin.it>
Date: Tue, 27 Jul 1999 19:52:58 +0200
From: Maurizio Umberto Puxeddu <umbpux@tin.it>
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>,
        Csound Linux Development Mail <csound-unix-dev@ilogic.com.au>
Subject: Re: [CUD] Re: [linux-audio-dev] What do we need now ?
References: <379DC861.A2828F74@bright.net> <9907271714410M.13494@mtg150.upf.es>
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5ea41e98c9c53e8fa4597bd960d81b6f

Hello all. Hello Dave.

I'm not a professional developer but I like to express my modest
opinion.

Maarten de Boer wrote:
> 
> >   So what do you think we need ? More organization ? Does anyone else
> > feel that there might be too much re-invention of the wheel ? Can we
> > coordinate efforts in some better ways ? Let's put it to ourselves: what
> > software do we need and how shall we go about getting it ?
> 
> Apart from the suggestions you make about the development of the specific
> software (which I fully agree with) I think it would also be good if there
> would be a linux distribution that would install a linux audio workstation.
> I don't think the audio software available belongs in a standard linux
> distribution, and there are a lot of things in the standard distributions
> are not wanted and needed by somebody who wants to use linux as an audio
> workstation primarily. Also, having such a distribution would contribute
> to a necessairy 'survival of the fittest', and it could take care of this
> extra development it takes to make good software usuable software (docu-
> mentation, easy installation, clear bugreporting)
> 
> I know a of people how want to use jMax, and have PC's, and are open towards
> installing linux (and have even tried it), but are scared away by it. I am
> sure that if they would have a linux distribution that would install all they
> need for an audio workstation, they would use it.

I completely agree with you. I know professional composers (teachers in
my school) that would like to have a reliable "music machine". Some time
ago, one of them complained: "I prefer to buy another computer that I
could use just for make music but that is reliable than having a
computer that is claimed to be all-purpose but crashes every few
minutes".

I was thinking of a similar Linux-for-the-musician distribution too. One
could maintain it and sell support just like Redhat does for it general
purpose distribution.
 
> What should go in such a distribution?
Random things that often don't go with standard distributions:

-Both ALSA and OSS drivers with a installation utility that can install
and configure completely the driver and select the driver that best
support the audiocard (waiting for ALSA to bury OSS under its source
code listings)
-Java Development Kit
-Libraries and other things that are often required for running audio
software (Lesstiff, audiofile, FFTW, Gtk widgets, TCL/TK extensions) 
-One of the two graphic environments: GNOME (my favourite) or KDE. But
just one of them (see below).
-Of course, a selection of the sound software for Linux and a section
with less stable but interesting software.
-Extension to the available documentation.
-Musical addon for standard software (for example, Csound modes for
Emacs)
-A kernel configured to better perform audio task. For example often a
composer would like to burn a CD with its music. Lets configure the
kernel to do it. It's not so easy.

I think that an end-user would accept less choice and less customization
if he can have a machine that it's easy to start and to maintain. This
means: one graphic environment, one editor, one mail-agent... ok, maybe
it's a bit extremist but I think that the other extreme is worse.

> How much effort would it take to
> produce it?
Don't now but too much for me alone... :)

> Would should be taken as the base for such a distribution ?
Redhat (or Mandrake)?

Some word about Linux audio software development. Pro-developer will
excuse my words

1) Do you think that running audio driver (and other audio services
daemons) under RTLinux could improve the quality of the audio for Linux?

2) Some months ago I worked to (and the abandoned) an audio software
idea: "Abstract Audio". It's started as yet another audiofile library
but I'd like to include code for all standard audio tasks: an engine for
automatic audio data conversion, mixing/splitting and even for the
standardization of command line options. You can continue the list. 

I abandoned it because I see that there are many similar project but
they are partial: so we have people that write audio data conversion
code for the audio driver, for the brand new audio file library, ...
etc. I understood that I was working to have a nice toy for me only.
Most of this code has be already written: we have only to put it in a
unique object and define a modern and general API. Just like an
X-Windows for the audio stuff.

Good thing GASP!

A presto,
Maurizio Umberto Puxeddu

From - Tue Jul 27 16:39:03 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA30769
	for <slinkp@ulster.net>; Tue, 27 Jul 1999 14:44:30 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA18812 for linux-audio-dev-list; Tue, 27 Jul 1999 14:03:50 -0400
Received: from cyphyn.219.org (nwhn-sh2-port209.snet.net [204.60.13.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA18809 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 27 Jul 1999 14:03:45 -0400
Received: from localhost (ffloberg@localhost)
          by cyphyn.219.org (8.8.4/8.8.4) with ESMTP
	  id OAA04658; Tue, 27 Jul 1999 14:04:15 -0400
X-Authentication-Warning: cyphyn.219.org: ffloberg owned process doing -bs
Date: Tue, 27 Jul 1999 14:04:15 -0400 (EDT)
From: Fred Floberg <ffloberg@snet.net>
X-Sender: ffloberg@cyphyn.219.org
To: Francois Dechelle <Francois.Dechelle@ircam.fr>
cc: Dave Phillips <dlphilp@bright.net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>,
        Csound Linux Development Mail <csound-unix-dev@ilogic.com.au>
Subject: Re: [CUD] Re: [linux-audio-dev] What do we need now ?
In-Reply-To: <379DD3ED.5CC74D34@ircam.fr>
Message-ID: <Pine.LNX.4.05.9907271305440.4323-100000@cyphyn.219.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 26a957f9361be4b0ccfa6a19c0bbd3a8




On Tue, 27 Jul 1999, Francois Dechelle wrote:

> Dave Phillips wrote:
[snip]
> >   So what do you think we need ? More organization ? Does anyone else
> > feel that there might be too much re-invention of the wheel ? Can we
> > coordinate efforts in some better ways ? Let's put it to ourselves: what
> > software do we need and how shall we go about getting it ?
[snip]
> Greetings,
> 
> Thanks a lot, Dave, for your initiative.
> 
> As you mentionned, we are now much involved in moving GNU/Linux 
> to music and multimedia, and we will put our efforts into this.

Though I've been pretty busy with non-computer related activities this
summer, I've been trying to keep an eye on ALSA developement.

Their are several problems concerning Linux's viability as a real-time
multi-media OS which need to be addressed.

One is short term, or intermittant latency caused by the kernel locking
during syncs of the disks [URL1]. The locking causes suspension of writes by
all drivers in the kernel, including audio drivers, at random intervals.
This makes hard-disk audio recorder apps, for example, rather unreliable.

>From what I understand, this problem is being addressed slowly but surely,
by the kernel developers. But until the work is finished it's going to
be difficult for app writers to write rock solid real-time audio tools.

So one of the things that could be done is to encourage kernel developers
in completing the work in this area, and of course lend a hand if possible.

 
> I think that one important and urgent problem is the lack of
> drivers for pro multi-channels audio cards. I don't know
> if you agree, but I think that OSS has not helped progress
> in this area because of the closed-sources, and we should
> fight for open-source drivers. So what we can do here
> is: show board manufacturers that there is an operating system 
> that works on very powerfull machines (an 21264 Alpha server 
> is rated at 45 SpecFP-95 and costs about 4000 $ !), has very
> good latency performance, has a community of developpers,
> has first-class audio applications (well, ...), in order to
> have an ALSA interface for a set of pro audio cards (1 is 
> enough, but 2 or 3 would be perfect). To help that, may
> be a list of potential cards to support may be helpfull:

Part of the problem of writing drivers for pro-quality multi-channel
audio cards is their expence. There aren't many driver developers
out there who can afford a $400 or $500 card to write a driver for.
Once again, this has been discussed on the ALSA development list.

But because ALSA [URL 2] is designed with the idea of making it easy for
others to write low level drivers for new cards, I think we'll be
seeing many more cards supported once ALSA becomes a standard part
of the Linux kernel, IMO, guessing that people have these high end cards
running under "other OS's" already. Then it will be more a matter of getting
card manufacturers to give up the needed info in order to write the low
level drivers.

[snip]
> There is something that may be worth considering
> for MIDI. The GRAME (a french studio located in Lyon)
> has released its "MidiShare" as free software. People
> knowing it say that it is superior to Opcode's OMS. 
> So, may be porting it to Linux could be usefull. It
> allows multi-devices, has GUI for configuration, provides
> a library for MIDI files reading, ...

MidiShare to some extent, is what Frank Van De Pol used as a model when he
wrote the MIDI Sequencer Subsystem for ALSA [URL 3]. From email to
the ALSA list [URL 4], the MidiShare people are aware of ALSA and
Frank's work, and have offered to collaborate with the ALSA
project. This is Very Good News, and we'll have to see what
comes of it.

> I also completely agree for Marten's idea of a distribution
> oriented for multimedia and audio. I was also thinking
> of it, and I volunteer to work on it.

I agree as well, but I do think that the locking problems in
the Linux kernel need to be fixed completely before focusing
on an audio/multi-media workstation distrib of Linux.




URLs:

1: http://www.mail-archive.com/alsa-devel@alsa-project.org/msg00050.html
2: http://www.alsa-project.org
3: http://www.vande-pol.demon.nl/alsa/node2.html#4
4: http://www.mail-archive.com/alsa-devel@alsa-project.org/msg00396.html







Fred


From - Tue Jul 27 16:39:06 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA31239
	for <slinkp@ulster.net>; Tue, 27 Jul 1999 14:48:26 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA18849 for linux-audio-dev-list; Tue, 27 Jul 1999 14:10:14 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA18846 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 27 Jul 1999 14:10:11 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id OAA25353;
	Tue, 27 Jul 1999 14:08:03 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id OAA23614; Tue, 27 Jul 1999 14:08:02 -0400 (EDT)
Date: Tue, 27 Jul 1999 14:08:02 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] What do we need now ?
In-Reply-To: <19990727182851.B177@cerealbox>
Message-ID: <Pine.GSO.4.10.9907271358520.23444-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5079215579f36935de54b56f42d13f80

On Tue, 27 Jul 1999, reactor/CTPmedia wrote:

>  >% PS: it is not the first time I do this, but I would like to urge people to
>  >% use FLTK for the GUI of audio software. Fast, small, no bloat.
> 
> i think we should prefer GTK+ instead, because it's more standard.
> every linux distribution has a GTK+ package.

Please folks, this isn't Usenet; this is very definitely lighter fluid for
a flame war.  By arguing about toolkits you can easily alienate
developers, and this is such a small community we have here, we can't
afford to do that.  Use what you personally prefer, and give advice only
to those who ask for it on that topic.

In the realm of alienation, don't forget the sad case of Audiotech.  This
was _the_ big up and coming development project (or so it seemed) in this
community two years ago.  It was meant to be a pro-level audio recorder
and editor (to put Sound Forge to shame), which, as Dave mentioned, is one
of the prime things we're still lacking.  However, the project ground to a
halt after too much infighting due (so I'm told) to conflicting egos.
There's just not enough of us here to deal with such arguments, so lets
try our best to avoid them!

Div.

P.S.  In response to Dave's call-for-projects, I'd talk about my
in-progress Java-based MIDI sequencer (which emphasizes having an
unprecedentedly strong editing interface rather than being a clone of
anything existing), but it's not far enough along, nor is it progressing
quickly enough to get anybody's hopes up.


From - Tue Jul 27 16:39:07 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA02534
	for <slinkp@ulster.net>; Tue, 27 Jul 1999 15:15:22 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA18877 for linux-audio-dev-list; Tue, 27 Jul 1999 14:23:59 -0400
Received: from kaybee.org (kaybee.resnet.gatech.edu [128.61.15.250]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA18874 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 27 Jul 1999 14:23:57 -0400
Received: (from rob@localhost)
	by kaybee.org (8.8.7/8.8.7) id OAA28400
	for linux-audio-dev@ginette.musique.umontreal.ca; Tue, 27 Jul 1999 14:21:52 -0400
From: rob <rob@kaybee.org>
Message-Id: <199907271821.OAA28400@kaybee.org>
Subject: Re: [CUD] Re: [linux-audio-dev] What do we need now ?
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Tue, 27 Jul 1999 14:21:52 -0400 (EDT)
In-Reply-To: <Pine.LNX.4.05.9907271305440.4323-100000@cyphyn.219.org> from "Fred Floberg" at Jul 27, 99 02:04:15 pm
Content-Type: text
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 92ecd268c69a14e42b3065d94c8d6df1

> 
> Their are several problems concerning Linux's viability as a real-time
> multi-media OS which need to be addressed.
> 
> One is short term, or intermittant latency caused by the kernel locking
> during syncs of the disks [URL1]. The locking causes suspension of writes by
> all drivers in the kernel, including audio drivers, at random intervals.
> This makes hard-disk audio recorder apps, for example, rather unreliable.
> 


	hard real time scheduling is available to linux now with more or
less trouble.  rtlinux puts a small scheduler under the kernel that
controls the interrupts, nothing in the linux kernel level can lock its
resources.
	see rtlinux.org and follow the redirect.  
	by the way i've made several utilities including one that can view
an akai sample cd with gtk, and a somewhat realtime sampler that uses akai
samples,  the code works completely fine in  user space, but i'm just
starting to integrate it into rt linux.  yell if anyone is interested and
would like me to put these up somewhere.
			           rob

-- 
Rob Melby
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
Internet: rob@kaybee.org, gt4255a@prism.gatech.edu

From - Tue Jul 27 16:39:08 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA03746
	for <slinkp@ulster.net>; Tue, 27 Jul 1999 15:24:11 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA18917 for linux-audio-dev-list; Tue, 27 Jul 1999 14:46:43 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA18914 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 27 Jul 1999 14:46:37 -0400
Received: from bright.net (find-cas1-cs-46.dial.bright.net [209.143.26.149])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id OAA05248;
	Tue, 27 Jul 1999 14:44:31 -0400 (EDT)
Message-ID: <379E02AC.D9A262B3@bright.net>
Date: Tue, 27 Jul 1999 15:04:12 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] What do we need now ?
References: <19990727152555Z44268-2248+2097@nic.funet.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7403007514e1510cb1cc74cb551c833c

Greetings to all:

  Well, I've certainly learned not to cross-post !

Juhana Sadeharju wrote:

> Could somebody give a short explanation why Snd and MiXViews should be
> considered as pro-level? MiXViews has problems in editing, handling large
> files, playing, no plug-ins, and more.

Hmm. Well, I've been using MiXViews for much of my own work with
soundfiles in Linux, and I've come to know it pretty well. I'd be out of
bounds to claim it or Snd as 'pro-level', but each has certain features
I don't find in Cool Edit (or any other Windoze sound editor) and that I
do use.

The biases of those apps may indicate something about their origins. It
seems to me that both Snd and MiXViews are especially oriented towards
work in the spectral domain, i.e., frequency analysis, display, and
resynthesis. Does CE do LPC analysis and resynthesis ? Does it do phase
vocoder analysis and resynthesis ? Can I use the spectral display as a
source for data to apply to other aspects of the sound ? Will it use
LPC-derived formants as filter components ?

I'm not defending MiXViews against Cool Edit, nor am I arguing that it
is a 'pro-level' (my gaff) piece of software. In point of fact I wrote
that it's "moving closer" to pro-level. The latest version has some new
memory controls, perhaps it has already addressed your concerns about
handling large files. I should also note that I've had no trouble
playing anything in MiXViews, and that in fact it plays files I've had
trouble with elsewheres. Ditto for editing.

However, I understand that your needs are somewhat heavier than mine.
But you're still right when we compare MiXViews and Snd to the big guns
in the Windows world. MiXViews still lacks a tracking cursor !

Snd may be a different order of things. Bill Schottstaedt is working to
include the signal processing power of CLM into Snd (which would be
something like hitching Csound to Cool Edit) but I've been unable to use
it due to LessTif flakiness. I suggest watching Snd's development: it
already has good displays, can handle a large number of file formats, is
already moving into the use of plug-ins, and source code is included.
 
Francois Dechelle wrote:

> I think that one important and urgent problem is the lack of
> drivers for pro multi-channels audio cards. I don't know
> if you agree, but I think that OSS has not helped progress
> in this area because of the closed-sources, and we should
> fight for open-source drivers.

Right now it appears that Windows enjoys the same sort of industry
patronage that the Mac had in the 80s. But just as the Mac's hegemony
has declined, so can Linux bite into that Windows piece of the audio
pie. And you are correct: serious sound composers and researchers
absolutely need high-end high-quality sound cards.

So who do we fight ? How will we convince manufacturers of the obvious,
namely, that if they open-source their drivers they will sell more cards
? If they can't already see it, how will we convince them ? Frankly, I
doubt that our community's current buying power is simply not great
enough to warrant their attention. And when we _do_ reach critical mass
in numbers of Linuxen, then won't manufacturers be far more interested
in producing mass-market cards instead of high-end audio boards ?

I like the idea of targeting the manufacturers who already make the
cards we want on our Linux machines. Lobbying those builders seems a
sensible thing. Perhaps a group from LAD could start drafting a common
request ?

If there is a most-often heard complaint in the Linux audio world it has
to be about the lack of support for high-end audio cards.

Maurizio Umberto Puxeddu wrote:

> I was thinking of a similar Linux-for-the-musician distribution too.

This seems to be an idea whose time has come. Francois, perhaps you and
Maurizio should hook up on this ? I had the same idea two years ago: can
you imagine how crummy it would have been ? ;)

Nick Fells wrote:

> I would think the establishment of a recognised linux audio users/developers 
> group might have some effect here. Such a group could coordinate 
> development/testing/evaluation tasks, lobby hardware manufacturers, stress test > kernel releases and work on solutions to latency problems etc...and would have > more clout than individuals. 

Well, I'd like to think that this group qualifies, but I think Nick is
proposing a group wth some serious blessings from on-high, i.e., Linus
Torvalds and Alan Cox.

> ...what's lacking are apps which have the 
> reliability/flexibility/comprehensiveness of software like CEPro and Cubase 

I'm going to say a word which will chill the hearts of many here: money.
The developers of CE and Cubase are paid and probably paid well. Most of
us are doing what we can in Linux for absolutely no pay. I maintain that
in order for Linux audio development to even begin to compete with the
Big Guys we need some better organization of talents, better statements
of principles and goals, and perhaps even some honest-to-goodness
sanction from Linus and Alan and the other primary kernel hackers. In
other words, we need a strong and convincing profile, something that
will notify manufacturers and other targets that we are ready to
develop, that we have the resources, and that the work will see the
light of day.

Fred Floberg wrote:

> ...intermittant latency caused by the kernel locking
> during syncs of the disks [URL1]. The locking causes suspension of writes by
> all drivers in the kernel, including audio drivers, at random intervals.
> This makes hard-disk audio recorder apps, for example, rather unreliable.
>
> From what I understand, this problem is being addressed slowly but surely,
> by the kernel developers. But until the work is finished it's going to
> be difficult for app writers to write rock solid real-time audio tools.
>
> So one of the things that could be done is to encourage kernel developers
> in completing the work in this area, and of course lend a hand if possible.

This direction should be followed asap. Does Alan Cox read this mail
list ? If so, perhaps he could clarify the points needing attention.
Some pretty smart people are on the list, surely someone can lend a
hand.

(Hi, Fred, I wondered what happened to you !)

Rob Melby wrote:

>         hard real time scheduling is available to linux now with more or
> less trouble.  rtlinux puts a small scheduler under the kernel that
> controls the interrupts, nothing in the linux kernel level can lock its
> resources.

So this needs to be put into our Linux audio CD's kernel ? How would
such an addition impact applications already handling scheduling in
their own way, i.e., how would Quasimodo react, or realtime Csound ? I'm
not baiting, I just don't know much about rtlinux.


Okay, I have to stop somewhere and get back to work. Here's what I'm
tabulating as a partial list of the First Things we still need to get
to:

   1. Support for professional quality audio cards.
   2. Professional quality software that will use those cards to their
fullest extent.
   3. Some method of controlling disk writes and any other kernel
activity which can throw timing to the winds.
   4. A Linux-for-musicians CD which would hopefully have #1 and #2.
 
Thanks to all who responded, and I look forward to reading what comes
next.

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Tue Jul 27 17:56:44 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA24061
	for <slinkp@ulster.net>; Tue, 27 Jul 1999 17:51:54 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA19096 for linux-audio-dev-list; Tue, 27 Jul 1999 17:13:01 -0400
Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA19093 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 27 Jul 1999 17:12:56 -0400
Received: from hendrix (cartman17.zip.com.au [61.8.20.145])
	by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id HAA17892;
	Wed, 28 Jul 1999 07:02:48 +1000 (EST)
Message-ID: <379E204D.4D77190F@zip.com.au>
Date: Wed, 28 Jul 1999 07:10:37 +1000
From: Erik de Castro Lopo <erikd@zip.com.au>
Organization: Eric Conspiracy Secret Labs
X-Mailer: Mozilla 3.04Gold (X11; I; Linux 2.2.10 i586)
MIME-Version: 1.0
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
CC: Csound Linux Development Mail <csound-unix-dev@ilogic.com.au>
Subject: Re: [CUD] Re: [linux-audio-dev] What do we need now ?
References: <379DC861.A2828F74@bright.net> <9907271714410M.13494@mtg150.upf.es> <379DF1FA.8922DEE8@tin.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 05efc5e0085906a887dce0c2b2cb8a89

Maurizio Umberto Puxeddu wrote:
> 

<snip>

> 1) Do you think that running audio driver (and other audio services
> daemons) under RTLinux could improve the quality of the audio for Linux?

I've been messing about with compute heavy audio programs and found
that the built in Linux scheduler has Realtime features (man 
sched_setscheduler). The only drawback is that the program needs
to be setuid root.

Hope this helps,
Erik
-- 
+-------------------------------------------------+
     Erik de Castro Lopo     erikd@zip.com.au
+-------------------------------------------------+
"I love deadlines. I especially like the whooshing sound 
they make as they go flying by."  -- Douglas Adams

From - Tue Jul 27 21:36:17 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA20746
	for <slinkp@ulster.net>; Tue, 27 Jul 1999 21:38:37 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA19527 for linux-audio-dev-list; Tue, 27 Jul 1999 21:07:46 -0400
Received: from sculpscape.wakkanet.fi (cvx-1-6.dyn.nic.fi [62.236.97.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA19524 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 27 Jul 1999 21:07:43 -0400
Received: (from root@localhost)
	by sculpscape.wakkanet.fi (8.8.7/8.8.7) id BAA04360;
	Wed, 28 Jul 1999 01:33:19 +0300
Date: Wed, 28 Jul 1999 01:33:19 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
To: David Slomin <dgslomin@CS.Princeton.EDU>
cc: reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] What do we need now ?
In-Reply-To: <Pine.GSO.4.10.9907271358520.23444-100000@ux02.CS.Princeton.EDU>
Message-ID: <%hCjn3YtDx@sculpcave>
X-User-Agent: Mana 4.0beta (Linux)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: bafe62f89f73e4b809b8160b0975bd6a

On Tue, 27 Jul 1999, David Slomin wrote:

> P.S.  In response to Dave's call-for-projects, I'd talk about my
> in-progress Java-based MIDI sequencer (which emphasizes having an
> unprecedentedly strong editing interface rather than being a clone of
> anything existing), but it's not far enough along, nor is it progressing

IHMO this is important. We shouldn't just copy Windows/Mac/whatever 
software and their interfaces. While creating new apps, we should try 
to develop the old concepts. Good examples of this are the new MIDI 
system of ALSA drivers and linux kernel itself. 

--
Kai Vehmanen ----------------------------- CS, University of Turku, Finland
 : email                                 mailto:kaiv@wakkanet.fi
 : audio processing for linux            http://www.wakkanet.fi/ecasound/
 : my music (ambient-idm-rock-...mp3/ra) http://www.wakkanet.fi/sculpscape/


From - Tue Jul 27 21:36:47 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA21084
	for <slinkp@ulster.net>; Tue, 27 Jul 1999 21:40:41 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA19538 for linux-audio-dev-list; Tue, 27 Jul 1999 21:08:34 -0400
Received: from sculpscape.wakkanet.fi (cvx-1-6.dyn.nic.fi [62.236.97.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA19535 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 27 Jul 1999 21:08:30 -0400
Received: (from root@localhost)
	by sculpscape.wakkanet.fi (8.8.7/8.8.7) id CAA04603;
	Wed, 28 Jul 1999 02:30:02 +0300
Date: Wed, 28 Jul 1999 02:30:01 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
To: Dave Phillips <dlphilp@bright.net>
cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>,
        Csound Linux Development Mail <csound-unix-dev@ilogic.com.au>
Subject: Re: [linux-audio-dev] What do we need now ?
In-Reply-To: <379DC861.A2828F74@bright.net>
Message-ID: <%rien3YtDw@sculpcave>
X-User-Agent: Mana 4.0beta (Linux)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 812f3c6bb9f30abd3a5d53e860378f3a

On Tue, 27 Jul 1999, Dave Phillips wrote:

> 	3. Still no (or just too little) support for pro-audio cards. I have it
> on good authority that that situation will change later this year, but
> the wheels do turn slowly. We still need to make manufacturers aware of

Linux Musicstation had a interview with Dev Mazumdar (co-author of
OSS/Linux) and pro-audio cards were also discussed... 

http://www2.crosswinds.net/~linuxmusic/software3.html

I just hope that support for more medium priced audio cards will 
also happen. Frankly, I can't see myself affording to buy 
a RME Digi32 or Sonorus Studi/o. Cards like Midiman 2044, Korg
1212, Audiowerk8, Event Darla and Turtle Beach Montego 
might have more potential in Linux audio. Afterall, currently
Linux really isn't for the real professional, money is no problem
people.

> 	6. Soundfile editors are still not up to par, although recent advances
> in Snd and MiXViews brings them closer to pro-level software. Simply

Hmm, relating to this, I'd really like start a discussion about 
a common effect plugin API for Linux audio apps. I've been thinking
about adding plugin support for ecasound - my linux audio project - 
but it seems like a awful waste of resources that every audio file 
editor, mp3 player, realtime synth, mixer, etc, etc has its own
effects and usually even their own plugin APIs. 

After all, plugin support isn't very useful, if no one is actually 
making plugins. With a common API, it would make a lot of great
effect routines available for all to use. 

Any suggestions? As there are already many plugin APIs available, 
it might be enough just to choose one.

>   So what do you think we need ? More organization ? Does anyone else
> feel that there might be too much re-invention of the wheel ? Can we
> coordinate efforts in some better ways ? Let's put it to ourselves: what
> software do we need and how shall we go about getting it ?

Definately! I don't think we need anything too fancy. I guess 
GIMP is putting too much pressure on us. :) It seems that many
ambitious audio projects have died because unrealistic goals.

I like mailing lists and I feel that the best thing for iinux audio 
development would be that this (linux-audio-dev) became the 
home for all audio developers. Many succesful Linux projects seem
to work this way... Lists like linux kernel, ALSA, Roxen, KDE, ...
and many many others have proved that this is a good way to create
co-operation.

-- 
Kai Vehmanen ----------------------------- CS, University of Turku, Finland
 : email                                 mailto:kaiv@wakkanet.fi
 : audio processing for linux            http://www.wakkanet.fi/ecasound/
 : my music (ambient-idm-rock-...mp3/ra) http://www.wakkanet.fi/sculpscape/

From - Tue Jul 27 20:12:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA09674
	for <slinkp@ulster.net>; Tue, 27 Jul 1999 20:16:00 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA19337 for linux-audio-dev-list; Tue, 27 Jul 1999 19:38:47 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA19334 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 27 Jul 1999 19:38:43 -0400
Received: from ulster.net (annex1-port19.ulster.net [208.133.192.19])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id TAA06210
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 27 Jul 1999 19:46:49 -0400
Message-ID: <379E43E3.343649F2@ulster.net>
Date: Tue, 27 Jul 1999 19:42:27 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Recording: What do we need now ?
References: <379DC861.A2828F74@bright.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b2d1b14a4e3b6a153f90ffee0ec4d453

Much good fodder for discussion...

A note on where I'm coming from:
I'm mostly a user, not a developer. I can hack together csound orcs and
scos, and I can hack enough perl and python to do fun things with
automatically generated csound scores, but that's about it. I can sort
of barely read some C. So I don't have much to offer any projects in the
making. I am pretty good at writing user-level documentation, which I
know some of you guys hate, so maybe that would be of use.

My personal wish list:

First, re. items 6 and 7 from Dave's list:
Hard-disk recording and soundfile editing.

I think these are more than closely related: they are (or should be)
integral. Sure, there's plenty of use for a good 2-channel editor, but
once you go beyond that, there is so much benefit to be had from a real
hard-disk recording system. And a hard-disk recorder without good
editing capabilities gets annoying pretty quickly (e.g. Multitrack.)

Having spent some time this year recording an album on a 24-channel
ProTools system, I must say that doing it _right_ is a pretty daunting
task.

Part of what makes ProTools so great is the extensive, powerful signal
processing. We can't (currently) hope to compete with $30,000 worth of
dedicated DSP's, nor is it realistic to think we can put together a
system of free plugins rivalling a burgeoning industry where plugins
cost > $500 apiece, BUT:

Leaving aside signal processing _entirely_, the ProTools
recording/editing interface alone is miles beyond anything we have.
SLab, MultiTrack, Mix... I don't think any of these could possibly be
rebuilt into something comparable. It would almost certainly have to be
a new project. Imagine Mix's interface, only you have 32 (or is it 64?)
channels instead of 9, there's no arbitrary limits on file length, each
channel has totally non-linear non-destructive editing (so it's like a
32-channel editor with unlimited undo), and zooming in on envelope
curves actually works... you get the idea. Now imagine that this system
also records audio (in 24-bit precision, no less). Then add pro-quality
dsp, plugins, the ability to record mixer fader movement from an
external interface, the ability to sync to external analog or digital
recorders...

Now, that's a tall order. The demands on the hard drive must be _very_
intense. Without those Digidesign DSPs to do all the mixing, the CPU and
memory load would be pretty heavy too. I have no idea how Digidesign
gets ProTools to respond to edits as quickly as it does. I would think
the disk would just be seeking like crazy. At one point we were using 32
channels of audio simultaneously, with editing on about half the
channels, and doing overdubs on that with perfect synchronization and no
dropouts. I don't know how much latency there was but it sure seemed
like you could make an edit, hit "play" and hear it really fast. (This
was on a Mac G3 - 233 MHz I think, 96 MB ram, with one SCSI drive
dedicated to audio. This is not an exotic machine these days by any
means. But then, as the guys at the studio told me, "The Mac doesn't do
much except hold it all together.")

I bring up ProTools because, as long as we're looking at what needs to
be done, I think we may as well aim REALLY high. It's worth considering
how close we can come to meeting such specs.
I would just about die to see a free software recording/editing
application project that could, in principle, accomplish these things,
even at a lesser scale. Hell, as little as 8 channels of ProTools with
only 2 or 4 channels of I/O would be an enormously powerful system for a
home studio. And as the price of CPU and hard drives continues to drop,
it would only get better.

I think the most likely way a project like this could actually get done
is somewhat like the way GIMP seems to work: if a small team of core
developers concentrated on the recording / editing / mixing system and
the interface, and left dsp entirely up to plugin authors. Probably
there wouldn't need to be time wasted on developing a new toolkit since
the GIMP people already did that for us. :) (But let's not argue about
toolkits again... yet.) In a few short years, GIMP has come from nowhere
and is arguably giving Photoshop a very, very good run for its money
(for web graphics, at least; not prepress, sadly). 

So it IS possible.

It seems to me that part of the problem with SLab and Multitrack is the
authors wanted to do too much themselves; they wrote lots of dsp code
for a framework that wasn't working very reliably yet. The other problem
is the closed development model. Unless B. Nagels turns up, all the work
he did on Multitrack is useless because nobody but him can fix all the
bugs. 

Re. Slab: I haven't checked it out lately; maybe it's better now. I'm
not so inclined to give it another try because I was one of those who
disliked the interface... too complicated and I _still_ couldn't do a
lot of the things I wanted ... an example of inappropriately aping
physical hardware, I think.

At this point, it must be noted that Snd already has a lot of what's
needed for my hypothetical system: it already supports many channels; it
already has a plugin API (or rather several ways of doing it -- IMHO a
very good idea as you can in principle do quick hacks with tools like
sox, or cool things with csound, or whatever.). And Snd already has a
lot of editing capability. But:

--I can't figure out what the license terms of snd are; would it be ok
to modify and redistribute?
--It's not really set up to be a hard-disk recorder: I haven't figured
out how to make it work full duplex, if it even can. Likewise, it's not
really designed for intensive realtime work so I'd be surprised if it
would work well.
--It doesn't really have any way to do non-destructive automated mixing:
the envelope interface is OK, but not really comparable to what ProTools
and similar systems have.

----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Tue Jul 27 21:42:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA21294
	for <slinkp@ulster.net>; Tue, 27 Jul 1999 21:41:39 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA19523 for linux-audio-dev-list; Tue, 27 Jul 1999 21:07:40 -0400
Received: from sculpscape.wakkanet.fi (cvx-1-6.dyn.nic.fi [62.236.97.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA19520 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 27 Jul 1999 21:07:36 -0400
Received: (from root@localhost)
	by sculpscape.wakkanet.fi (8.8.7/8.8.7) id DAA04632;
	Wed, 28 Jul 1999 03:04:26 +0300
Date: Wed, 28 Jul 1999 03:04:26 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
To: reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] What do we need now ?
In-Reply-To: <19990727182851.B177@cerealbox>
Message-ID: <%HHkn3YtDy@sculpcave>
X-User-Agent: Mana 4.0beta (Linux)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e02b710b95c129c13beb9c228ccb9253

On Tue, 27 Jul 1999, reactor/CTPmedia wrote:

> you're right, FLTK is fast, cool, but GTK+ looks prettier (and that's
> an important factor if we want to get Windozers away from their Windozes)
[...]> 
> or we could use both. QT could be a good choice too (besides i don't like
> it :))). just look at GreenBox, a nice drummachine made with QT. it has

As someone already said, this is dangerous. As long as the runtime
libs are easy to obtain, you should use whatever library you like
to use. I'm a really object-oriented guy myself and like to use Qt.

On the other hand, audio apps shouldn't be tied to any particular 
windowing system. It might be a good thing that we have KDE, Gnome
and others competing with each other, but it would a shame if some 
great audio app worked only with one of them... So no for Ksequencer
and Gsequencer and yes to Lsequencer. :)

> and don't forget, we are competing with COMMERCIAL software, for which
> people get lots of money (even though Radium cracks all of them), so
> we have to bring QUALiTY in our stuff, or noone will take us seriously.

Because of this, we must really take advantage of open-source
possibilities. As an example, I released the first public version 
of my ecasound software about a month ago. Already I've received
a lot of valuable feedback that has helped enormously in development.
And what's more important, GNU licence has abled me to use
the vast resources of GPL'd code in my software. Still, my motive
has remained the same: I'm coding this for my own purposes. If you 
think you have to compete with commercial software, your project
will die sooner or later.

-- 
Kai Vehmanen ----------------------------- CS, University of Turku, Finland
 : email                                 mailto:kaiv@wakkanet.fi
 : audio processing for linux            http://www.wakkanet.fi/ecasound/
 : my music (ambient-idm-rock-...mp3/ra) http://www.wakkanet.fi/sculpscape/

From - Tue Jul 27 21:18:22 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA17958
	for <slinkp@ulster.net>; Tue, 27 Jul 1999 21:18:13 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA19469 for linux-audio-dev-list; Tue, 27 Jul 1999 20:33:57 -0400
Received: from shell.nacs.net (shell.nacs.net [207.166.192.99]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA19466 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 27 Jul 1999 20:33:54 -0400
Received: from localhost (stutz@localhost)
	by shell.nacs.net (8.8.7/8.8.8) with ESMTP id UAA04726
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 27 Jul 1999 20:31:48 -0400
X-Authentication-Warning: shell.nacs.net: stutz owned process doing -bs
Date: Tue, 27 Jul 1999 20:31:47 -0400 (EDT)
From: Michael Stutz <stutz@dsl.org>
X-Sender: stutz@shell.nacs.net
To: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Recording: What do we need now ?
In-Reply-To: <379E43E3.343649F2@ulster.net>
Message-ID: <Pine.LNX.4.10.9907272003010.4574-100000@shell.nacs.net>
X-URL: http://dsl.org/
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 6301ab77ca60f0ac9207e5fb19c90470

On Tue, 27 Jul 1999, Paul Winkler wrote:

> I think these are more than closely related: they are (or should be)
> integral. Sure, there's plenty of use for a good 2-channel editor, but
> once you go beyond that, there is so much benefit to be had from a real
> hard-disk recording system. And a hard-disk recorder without good
> editing capabilities gets annoying pretty quickly (e.g. Multitrack.)

Not only that (and I'm coming roughly from the same place Paul is, skill-
and interest-wise), but what is the use of a hard-disk recorder when you
only have one input on your sound card?

I use my (analog) Yamaha 4-track to record live performances with 2-4 mikes
(otherwise, when I'm just screwing around with one mike, recording to one 
track, I might as well be using brec on my computer --and sometimes I do).
Then the mixdown gets captured into the soundcard's LINE IN jack and the
resulting file is edited in Snd, whose interface whips all the other
sound-editing tools, imho.

It's still too difficult (at least for me) to mix separate sound files in
the way or with the ease/precision that I want to, or find ways to layer and
sequence them. My dream-system would combine this, plenty of dsp plugins,
etc. I got some good use out of a primitive sequencer/sampler program called
Delfin but there was no reliable way to record the sound output -- it would
be nice to see a tool like /proc/audio that you could use to record the
sound currently being played by the soundcard, regardless of the format or
the application playing it (there is a paudio package to do this, haven't
tested it with ALSA yet). Finally, another dream-app is a realitme
virtual effects processor with a GIMP-like plugin API that the community can
contribute to. Plug a guitar, mike or other input in the LINE IN, plug the
amplifier in the LINE OUT and the program is like the ultimate effects box
collection, and you can pick and choose the effects in your loop: flange,
chorus, distortion, RAT pedal, superfuzz bigmuff, Fuzzrite, etc. ...


From - Tue Jul 27 21:33:22 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA19610
	for <slinkp@ulster.net>; Tue, 27 Jul 1999 21:30:56 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA19487 for linux-audio-dev-list; Tue, 27 Jul 1999 20:49:03 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA19484 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 27 Jul 1999 20:48:57 -0400
Received: from someip.ppp.op.net (d-bm3-1a.ppp.op.net [209.152.194.90]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id UAA18608; Tue, 27 Jul 1999 20:46:50 -0400 (EDT)
Message-Id: <199907280046.UAA18608@renoir.op.net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>,
        Csound Linux Development Mail <csound-unix-dev@ilogic.com.au>
Subject: [linux-audio-dev] Re: [CUD] What do we need now ? 
In-reply-to: Your message of "Tue, 27 Jul 1999 10:55:29 EDT."
             <379DC861.A2828F74@bright.net> 
Date: Tue, 27 Jul 1999 20:53:28 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: fad3ab5574540915975a9a1cf32fd110

>(Cecilia, Snd). Then of course there's Quasimodo (how's it going these
>days, Paul ?), 

there's been a small slowdown, because my daughter is out of
(pre-)school for summer and i'm often travelling. but things continue
to develop fairly rapidly, and i am hoping that by september, i will
be building binary distributions of quasimodo so that people without
the desire and patience for the compilation process can try using it.

stephane added support for XML and patch saving/restoring, and we'll
be moving to XML for the module files (".orc") soon.

i also spent quite a bit of time porting my turtle beach wavefront
drivers to ALSA, and just recently, on a working native mmap()
implementation for ALSA (see the alsa-devel mailing list).

right now, stephane conversy and myself are hard at work on a new
internal API that will allow quasimodo to be used as a shared
library. i have also altered things so that it can be built without
GTK - quasimodo now dynamically loads its user-interface libraries
just like its modules. at least one english user has expressed
interest in quasimodo-for-the-blind.

i've been focusing on quasimodo as an FX processor recently, which has
given me a different emphasis (real-time latency in particular). 

soon, i will really need some people to do development work on new and
existing modules (once we switch to XML).

>	4. How about a MIDI loopback device ? Anyone working on anything like
>Hubi's virtual cable ?

OSS has these already. ALSA does not, I think. 

>	7. On a related note, we need more or better hard-disk recording
>systems. SLab is okay by me, but many are put off by the interface.

this is a mild understatement. if nobody else does it, then by the
time i get quasimodo stable, i plan to do a HDR system based on a lot
of the same code as quasimodo and with nice graphics. quasimodo itself
might even do this, but a separate app would win more fans :) if you
like the steinberg/creamware/logic stuff, that will be the general
idea. but it won't be an audio or MIDI sequencer.

--regards,
--p

From - Tue Jul 27 22:02:42 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA23676
	for <slinkp@ulster.net>; Tue, 27 Jul 1999 21:57:56 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA19577 for linux-audio-dev-list; Tue, 27 Jul 1999 21:29:33 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA19574 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 27 Jul 1999 21:29:31 -0400
Received: from ulster.net (annex1-port19.ulster.net [208.133.192.19])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id VAA20611;
	Tue, 27 Jul 1999 21:37:50 -0400
Message-ID: <379E5DE7.C5D0BF6C@ulster.net>
Date: Tue, 27 Jul 1999 21:33:28 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
CC: Michael Stutz <stutz@dsl.org>
Subject: Re: [linux-audio-dev] Recording: What do we need now ?
References: <Pine.LNX.4.10.9907272003010.4574-100000@shell.nacs.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: a21d77a0dbee3c4f6aa532e51db3dc52

Michael Stutz wrote:
> 
> On Tue, 27 Jul 1999, Paul Winkler wrote:
> 
> > I think these are more than closely related: they are (or should be)
> > integral. Sure, there's plenty of use for a good 2-channel editor, but
> > once you go beyond that, there is so much benefit to be had from a real
> > hard-disk recording system. And a hard-disk recorder without good
> > editing capabilities gets annoying pretty quickly (e.g. Multitrack.)
> 
> Not only that (and I'm coming roughly from the same place Paul is, skill-
> and interest-wise), but what is the use of a hard-disk recorder when you
> only have one input on your sound card?

Actually, plenty, depending on your working style. If you are recording
only one musician at a time (e.g. recording yourself), you'd only use
those one or two tracks anyway. The advantage of the HDR system is the
non-linear editing and automated mixing. You could sort of do this
currently by recording in ... um... whatever you can get to work
full-duplex; then import the files to snd for editing; then export them
to individual .wavs again and mix with MixW. Very clunky.

(snip)
> Delfin but there was no reliable way to record the sound output -- it would
> be nice to see a tool like /proc/audio that you could use to record the
> sound currently being played by the soundcard, regardless of the format or
> the application playing it (there is a paudio package to do this, haven't
> tested it with ALSA yet).

I tried it some months ago -- it was OSS-free only at that time. Haven't
checked lately.

 Finally, another dream-app is a realitme
> virtual effects processor with a GIMP-like plugin API that the community can
> contribute to. Plug a guitar, mike or other input in the LINE IN, plug the
> amplifier in the LINE OUT and the program is like the ultimate effects box
> collection, and you can pick and choose the effects in your loop:

Cool idea. There are a few attempts at full-duplex processors somewhere
on Dave's page. Problem is, latency here is _extremely_ critical, unless
you like every single effect you use to have a built-in predelay that
you can't bypass. :) 

----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Tue Jul 27 23:23:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA01615
	for <slinkp@ulster.net>; Tue, 27 Jul 1999 23:17:46 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA19683 for linux-audio-dev-list; Tue, 27 Jul 1999 22:41:25 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA19680 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 27 Jul 1999 22:41:21 -0400
Received: from ulster.net (annex1-port19.ulster.net [208.133.192.19])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id WAA30715
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 27 Jul 1999 22:49:27 -0400
Message-ID: <379E6EB1.1748A2F6@ulster.net>
Date: Tue, 27 Jul 1999 22:45:05 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] What do we need now ?
References: <%rien3YtDw@sculpcave>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0b5783f82ea7d48d52591fa6e89f468b

Kai Vehmanen wrote:
> I just hope that support for more medium priced audio cards will
> also happen. Frankly, I can't see myself affording to buy
> a RME Digi32 or Sonorus Studi/o. Cards like Midiman 2044, Korg
> 1212, Audiowerk8, Event Darla and Turtle Beach Montego
> might have more potential in Linux audio. Afterall, currently
> Linux really isn't for the real professional, money is no problem
> people.


This is a very good point. The cards you mention are what I call
"semi-pro". Drivers for these would be very, very nice.

> >       6. Soundfile editors are still not up to par, although recent advances
> > in Snd and MiXViews brings them closer to pro-level software. Simply
> 
> Hmm, relating to this, I'd really like start a discussion about
> a common effect plugin API for Linux audio apps. I've been thinking
> about adding plugin support for ecasound - my linux audio project -

There has been discussion re. Steinberg VST2 plugin format (one of *the*
commercial standards) recently on the csound mailing list. You might
want to check the archive at:

http://media.dr.rhbnc.ac.uk/csound/list/

There are at least two threads with VST in the topic...

I believe VST2 is an open standard?

BTW, one thing I like about Snd (though I have yet to actually have time
to make use of it) is that, in addition to a real plugin interface, you
can make a pseudo-plugin out of any external application by adding some
stuff to the config file. It's a slow & dumb way of doing it--writing
temp files to disk, then starting the external app. with the temp file--
but it could be great for people like me who aren't "real" developers
but can hack some csound or suchlike to do interesting things.


----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Wed Jul 28 00:03:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA06914
	for <slinkp@ulster.net>; Wed, 28 Jul 1999 00:06:05 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA19779 for linux-audio-dev-list; Tue, 27 Jul 1999 23:31:08 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA19776 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 27 Jul 1999 23:31:06 -0400
Received: from ulster.net (annex1-port19.ulster.net [208.133.192.19])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id XAA04278;
	Tue, 27 Jul 1999 23:39:22 -0400
Message-ID: <379E7A65.E2314671@ulster.net>
Date: Tue, 27 Jul 1999 23:35:01 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Juhana Sadeharju <kouhia@nic.funet.fi>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: [CUD] What do we need now ?
References: <19990727152555Z44268-2248+2097@nic.funet.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 89091942ffefd2e21236db7d7f95ae4e

Juhana Sadeharju wrote:
> I have set up GNU Audio Software Project (GASP) webpages at
> "http://www.funet.fi/~kouhia/gasp/". Any matter related to audio software
> writing should be documented there: designs, implementation issues,
> example codes.
> Software writers then could look at there and, for example,
> take ideas there and save development and/or programming time.

This is a very nice idea. Perhaps people on the list would consider
placing things they're already working on there, so novice developers
could more easily see what sort of code is available to look at?

I've been looking at your overview at
http://www.funet.fi/~kouhia/gasp/overview.html
...and this is a nice introduction to the main tools needed for a decent
music/audio workstation.

If anyone on the list hasn't seen Protools but was intrigued by my
description, the interface is not (in principle) all that different from
the screenshot of Steinberg Nuendo. So, in Juhana's terminology, what
I'm talking about is basically a "multitrack sequencer".  Except that
protools DOES "store...the audio signal as does the wave editor".

Protools looks different superficially (it looks more like NoTAM's Mix,
with a lot more tools and controls) but I can see at a glance that the
same interface ideas are there, with one notable exception: volume (or
other) envelopes in Protools are visualized much like those in Mix, as
thin colored lines right on top of the tracks they effect, rather than
in a separate track.

The volume envelopes can also be recorded from realtime control of an
external (proprietary, expensive) interface, but there's no reason we
couldn't do essentially the same thing with one of the midi fader-boxes
on the market (e.g. the one by Peavey). Protools volume envelopes can
also be recorded onscreen with mouse scrollbars, so it is in that sense
a "multitrack mixing desk", though it's not laid out like one. In
principle we can already do this kind of thing onscreen with pbd's
slider-box application (I forget the name of it, sorry). 

> To get an idea about commercial softwares, I have provided there an extensive
> listing of software manuals available on the net. If you're interested in
> to design GUIs and features, you could download a few best manuals for
> getting ideas.

One worth looking at is the Ensoniq PARIS manual-- I knew the guy who
re-wrote it, and he seemed to know his stuff. PARIS seemed to be well
designed.



----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Wed Jul 28 02:30:47 1999
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id CAA15946
	for <slinkp@ulster.net>; Wed, 28 Jul 1999 02:15:56 -0400
Received: from bright.net (find-cas1-cs-18.dial.bright.net [209.143.26.121])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id CAA22031;
	Wed, 28 Jul 1999 02:05:20 -0400 (EDT)
Sender: root@sparticus.bright.net
Message-ID: <379EA243.62FCC993@bright.net>
Date: Wed, 28 Jul 1999 02:25:07 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: slinkp@ulster.net
Subject: Snd question(s)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: U
X-Mozilla-Status: 8003
X-Mozilla-Status2: 00000000
X-UIDL: 4587e4fe69635ac30a79fb584226b33d

Greetings:

  Paul, you mentioned that you were using Snd. Have you been able to use
the Listener at all ? Apparently my build has problems with my LessTif.
I'm very curious about the plug-in capabilities (there seem to be more
than one method, right ?) but I can't run the examples. I've compiled
the necessary objects, I just can't get Listener to listen...

  Any other comments on Snd ?

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Wed Jul 28 15:57:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA13142
	for <slinkp@ulster.net>; Wed, 28 Jul 1999 09:46:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA24364 for linux-audio-dev-list; Wed, 28 Jul 1999 08:51:02 -0400
Received: from cmn14.stanford.edu (cmn14.Stanford.EDU [36.49.0.93]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA24361 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 28 Jul 1999 08:50:59 -0400
Received: (from bil@localhost)
	by cmn14.stanford.edu (8.8.8/8.8.8) id FAA29304
	for linux-audio-dev@ginette.musique.umontreal.ca; Wed, 28 Jul 1999 05:48:51 -0700 (PDT)
Date: Wed, 28 Jul 1999 05:48:51 -0700 (PDT)
From: Bill Schottstaedt <bil@ccrma.Stanford.EDU>
Message-Id: <199907281248.FAA29304@cmn14.stanford.edu>
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] What do we need now ?
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 36d56135295e257991bcf482d378459f

I very much appreciate the kind words about Snd!  I started work
on it about 3 years ago because I couldn't find such a program 

for my own work, so it reflects (as does CLM) my own interests;
I'm a non-real-time composer, interested primarily in sound
synthesis and processing; I've never had any burning
interest in real-time issues -- I'm happy to leave that area
to those who care about it.

On the questions that have come up: Snd's license is a slight
revision of Miller Puckette's Max license, if I remember right;
I consider it a freer version of the GPL, though I also released
Snd under the GPL; you can basically do anything you want with it 

as long as you don't sue me.  


On the recorder: I get full-duplex with Soundblaster and Ensoniq
cards, so I'm not sure what the problem is there; we recently
got a Sonorus card, so I'll work on that as soon as I find time.

On the plugins: I'm interested in any ideas!  I was trying to
imitate GIMP.

On the CLM connection: this is actually my true interest, the
reason I got involved in computer music 24 years ago.  I'm hoping
to get CLM-2 done by the end of the summer, then have some fun!

Perhaps this note sounds too defensive -- I am open to any suggestions
(my list of things-to-do for Snd has more than 250 entries), but
I'm not as smart as I once was, and there are only 24 hours in a day.

From - Wed Jul 28 15:57:37 1999
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id JAA08477
	for <slinkp@ulster.net>; Wed, 28 Jul 1999 09:09:34 -0400
Received: from bright.net (find-cas1-cs-47.dial.bright.net [209.143.26.150])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id IAA10541;
	Wed, 28 Jul 1999 08:58:52 -0400 (EDT)
Sender: root@sparticus.bright.net
Message-ID: <379F0322.3D7D936F@bright.net>
Date: Wed, 28 Jul 1999 09:18:26 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Winkler <slinkp@ulster.net>
Subject: Re: Snd question(s) and: STOP THE PRESS !!!
References: <379EA243.62FCC993@bright.net> <379EA7A1.4F8296D@ulster.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: U
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: fb58346124f6c2c76c17f0b85af60e62

Paul Winkler wrote:

> Well, snd reminds me of emacs in more ways than one. First, the lisp
> thing; second, I'm convinced it's the best editor even though I barely
> understand it. :)

Ha, that's the truth !

> I just opened up snd, and yes, the listener works. I don't know enough
> lisp to know what to _do_ with it, but it's there and seems to be
> responding.

Bill Schottstaedt has provided some examples of using the clm.o object
in Snd but I can't run them because I can't get the Listener working. Or
am I missing something: do I need a particular version of LISP installed
?

I really like his idea. Integrating Csound into something like KWave or
another good editor would be a similar effort, but of course Bill has an
advantage: he designed both Snd and CLM.

> I'm using a pre-built binary of snd-3.1, which I found as an rpm
> somewhere. I haven't tried to compile anything with lesstif in a long
> time... too much hassle last time I tried (I think it was one of the
> Notam apps).

Funny thing: I get mail from people trying to run the NoTAM binaries,
very few people try to build them. Of course, the binaries usually won't
run because they were built under libc5 and older versions of LessTif.
Well, I plan to completely revise those packages and prepare a much
better distro, perhaps a bundle including Ceres, Mix, Mammut, and I
don't know what else, maybe Adsyn. Could be a fun bundle...
 
> I don't have much time to play with that stuff these days-- I'm trying
> to get the band's "official" web site happening, which means learning
> all the html I never bothered with (tables, maybe css...). I've tried
> several html-generating tools (composer, amaya) and am convinced they
> all suck with the possible exception of StarOffice, which is the
> all-time king fascist of supreme bloatware. I mean, it is _big_.

I understand. Me, I use vi for everything. I once set up a neat little
Csound environment in vi but I didn't save the macros.

Yes, I use vi. I wear an iron jock-strap. ;)

Okay, big news time: I heard from Boris Nagels this morning ! You're
going to enjoy this one: he's going to release Multitrack as
open-source. If he approves I'll be placing the package on the MusTec
server. He's leaving for vacation today, but I hope to receive the
package yet today. If not, I'll get it in a couple of weeks.

So what do you think, is it good news ?

And how's your band doing these days ?

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Wed Jul 28 23:05:23 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA00759
	for <slinkp@ulster.net>; Wed, 28 Jul 1999 20:20:11 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA25163 for linux-audio-dev-list; Wed, 28 Jul 1999 19:14:24 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA25160 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 28 Jul 1999 19:14:22 -0400
Received: from ulster.net (annex1-port22.ulster.net [208.133.192.22])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id TAA26197;
	Wed, 28 Jul 1999 19:21:48 -0400
Message-ID: <379F8F7B.609D0A61@ulster.net>
Date: Wed, 28 Jul 1999 19:17:15 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-announce@sws1.ctd.ornl.gov
CC: LINART list <linart@li.org>,
        "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Audio-Quality-HOWTO updated
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 272640d98ea31734e9e879b1a75486ec

The Audio-Quality-HOWTO has been updated. The current version is 0.0.7.

The page is currently kept at:
http://www.ulster.net/~abigoo/pw_linux/Audio-Quality-HOWTO.html

Several new tips have been added. Thanks to all the contributors!

I would like to put the page somewhere with a more user-friendly URL. I
would also like to add some forms and CGI scripts so readers can add
tips and comments directly with minimal intervention from me.
(I would prefer scripting in Python, but I could probably hack Perl
too). I cannot do CGI on my current ISP. Any offers of a better
permanent home for the page would be appreciated.

It's getting a bit big and messy. Major reorganization is imminent...
 

----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Wed Jul 28 19:10:44 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA24609
	for <slinkp@ulster.net>; Wed, 28 Jul 1999 19:08:34 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA25078 for linux-audio-dev-list; Wed, 28 Jul 1999 18:09:58 -0400
Received: from duq3a.cc.duq.edu (duq3a.cc.duq.edu [165.190.9.207]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id SAA25075 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 28 Jul 1999 18:09:55 -0400
Received: from carmick5721.duq.edu ([206.217.109.75]) by duq3b.cc.duq.edu with SMTP;
          Wed, 28 Jul 1999 17:58:49 -0400
Message-Id: <3.0.5.32.19990728180155.013d0280@duq3.cc.duq.edu>
X-Sender: carmick5721@duq3.cc.duq.edu
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 28 Jul 1999 18:01:55 -0700
To: linux-audio-dev@ginette.musique.umontreal.ca,
        Csound Linux Development Mail <csound-unix-dev@ilogic.com.au>
From: "Frank J. Carmickle" <frankiec@unforgettable.com>
Subject: Re: [linux-audio-dev] What do we need now ?
In-Reply-To: <9907271714410M.13494@mtg150.upf.es>
References: <379DC861.A2828F74@bright.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3b080682b1a53ece4e8ecb6ed619661a

At 04:51 PM 7/27/99 +0200, you wrote:
snip
>Apart from the suggestions you make about the development of the specific
>software (which I fully agree with) I think it would also be good if there 
>would be a linux distribution that would install a linux audio workstation.
>I don't think the audio software available belongs in a standard linux
>distribution, and there are a lot of things in the standard distributions 
>are not wanted and needed by somebody who wants to use linux as an audio
>workstation primarily. Also, having such a distribution would contribute
>to a necessairy 'survival of the fittest', and it could take care of this
>extra development it takes to make good software usuable software (docu-
>mentation, easy installation, clear bugreporting)

Okay I just said this last night while watching Dave Letterman.

It is important that we make a special distribution.  My thoughts are that
we could also use a hacked kernel that has some sort of asymmetric multi
processing.  This we could then use to designate one processor for dsp
effects.  My question is wether or not this is a good idea.

Frank

From - Thu Jul 29 00:15:20 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA30233
	for <slinkp@ulster.net>; Thu, 29 Jul 1999 00:15:15 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA25453 for linux-audio-dev-list; Wed, 28 Jul 1999 23:26:09 -0400
Received: from sculpscape.wakkanet.fi (cvx-1-23.dyn.nic.fi [62.236.97.23]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA25450 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 28 Jul 1999 23:26:05 -0400
Received: (from root@localhost)
	by sculpscape.wakkanet.fi (8.8.7/8.8.7) id FAA01550;
	Thu, 29 Jul 1999 05:59:10 +0300
Date: Thu, 29 Jul 1999 05:59:09 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
To: Michael Stutz <stutz@dsl.org>
cc: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Recording: What do we need now ?
In-Reply-To: <Pine.LNX.4.10.9907272003010.4574-100000@shell.nacs.net>
Message-ID: <%yC8n38XB4@sculpcave>
X-User-Agent: Mana 4.0beta (Linux)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 4d1d04054b948da1ed9786ad7d9d82c7

On Tue, 27 Jul 1999, Michael Stutz wrote:

> and interest-wise), but what is the use of a hard-disk recorder when you
> only have one input on your sound card?

You can always have multiple sound cards. I have two cards (GUSMAX and 
Awe64G) and this way I have four mono inputs. Works both with ALSA
and OSS/Linux.

> tested it with ALSA yet). Finally, another dream-app is a realitme
> virtual effects processor with a GIMP-like plugin API that the community can
> contribute to. Plug a guitar, mike or other input in the LINE IN, plug the
> amplifier in the LINE OUT and the program is like the ultimate effects box
> collection, and you can pick and choose the effects in your loop: flange,
> chorus, distortion, RAT pedal, superfuzz bigmuff, Fuzzrite, etc. ...

Well, as soon as we can solve the latency problems, this will 
be possible. But big muff and rat... impossible in the digital 
domain. ;)

-- 
Kai Vehmanen ----------------------------- CS, University of Turku, Finland
 : email                                 mailto:kaiv@wakkanet.fi
 : audio processing for linux            http://www.wakkanet.fi/ecasound/
 : my music (ambient-idm-rock-...mp3/ra) http://www.wakkanet.fi/sculpscape/


From - Thu Jul 29 23:21:59 1999
Received: from sculpscape.wakkanet.fi (IDENT:root@cvx-1-9.dyn.nic.fi [62.236.97.9])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id DAA08964
	for <slinkp@ulster.net>; Thu, 29 Jul 1999 03:09:38 -0400
Received: (from root@localhost)
	by sculpscape.wakkanet.fi (8.8.7/8.8.7) id IAA03262;
	Thu, 29 Jul 1999 08:43:08 +0300
Date: Thu, 29 Jul 1999 08:43:08 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
To: Paul Winkler <slinkp@ulster.net>
cc: Kai Vehmanen <kaiv@wakkanet.fi>
Subject: Re: [linux-audio-dev] Recording: What do we need now ?
In-Reply-To: <379FDB3A.2F362A67@ulster.net>
Message-ID: <%Si+n3MKDS@sculpcave>
X-User-Agent: Mana 4.0beta (Linux)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: f5debb28ff9ee942deebd97e47842af2

On Thu, 29 Jul 1999, Paul Winkler wrote:

>> You can always have multiple sound cards. I have two cards (GUSMAX and
>> Awe64G) and this way I have four mono inputs. Works both with ALSA
> Do you have synchronization trouble when you use both cards at once?
> I've never been able to get this to work right; I thought the slightly
> different sample rates were always going to be a problem... What do you
> do?

To be honest, I've haven't done very much testing as usually I just
need one stereo-input. Anyway, I've done a lot of recording using
one card as a monitor-output and the other one for recording. This
has worked quite well. Basicly the sync isn't controlled in any way.
The recording process is started with trigger-functions of OSS and
that's all...

-- 
Kai Vehmanen ----------------------------- CS, University of Turku, Finland
 : email                                 mailto:kaiv@wakkanet.fi
 : audio processing for linux            http://www.wakkanet.fi/ecasound/
 : my music (ambient-idm-rock-...mp3/ra) http://www.wakkanet.fi/sculpscape/


From - Thu Jul 29 23:22:13 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA20789
	for <slinkp@ulster.net>; Thu, 29 Jul 1999 18:42:46 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA02127 for linux-audio-dev-list; Thu, 29 Jul 1999 17:34:09 -0400
Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA02124 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 29 Jul 1999 17:33:55 -0400
Received: from hendrix (kenny9.zip.com.au [61.8.18.137])
	by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id HAA12085;
	Fri, 30 Jul 1999 07:23:25 +1000 (EST)
Message-ID: <37A0C825.724D7542@zip.com.au>
Date: Fri, 30 Jul 1999 07:31:17 +1000
From: Erik de Castro Lopo <erikd@zip.com.au>
Organization: Eric Conspiracy Secret Labs
X-Mailer: Mozilla 3.04Gold (X11; I; Linux 2.2.10 i586)
MIME-Version: 1.0
Newsgroups: comp.dsp
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] ANNOUNCE : libsndfile-0.0.15
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 330cbb81409875723945f7b1d7556bca

ANNOUNCE : libsndfile-0.0.15

    libsndfile is a C library for reading and writing sound files 
    such as AIFF, AU and WAV files through one standard interface. It 
    can currently read/write 8, 16, 24 and 32 bit PCM files as well 
    as 32 bit floating point WAV files and ADPCM (IMA and MS) WAV 
    files. New to this release is the ability to read and write u-law 
    and A-law WAV and AU files and RAW header-less PCM files. This 
    library should compile and run correctly on any unix as well as 
    Win32 (MSVC++) and MacOS (Metrowerks compiler).

    libsndfile is released in source code format under the GNU 
    General Public license.

    http://www.zip.com.au/~erikd/libsndfile/


-- 
+-------------------------------------------------+
     Erik de Castro Lopo     erikd@zip.com.au
+-------------------------------------------------+
Unsolicited Broadcast Email is Forced Pay-per-view 
Advertising.

From - Fri Jul 30 00:53:01 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA31527
	for <slinkp@ulster.net>; Fri, 30 Jul 1999 00:51:03 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA02549 for linux-audio-dev-list; Fri, 30 Jul 1999 00:17:22 -0400
Received: from kaybee.org (kaybee.resnet.gatech.edu [128.61.15.250]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA02546 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 30 Jul 1999 00:17:19 -0400
Received: from localhost (rob@localhost)
	by kaybee.org (8.8.7/8.8.7) with ESMTP id AAA18957
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 30 Jul 1999 00:15:03 -0400
Date: Fri, 30 Jul 1999 00:15:03 -0400 (EDT)
From: rob <rob@kaybee.org>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] opcode usb audio io's
Message-ID: <Pine.LNX.4.10.9907300013560.18952-100000@kaybee.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: bd6ee996864d9f5783635984834da4fb


hey,
        anyone out there know the chipset the opcode usb audio products
like "Sonic Port" use?  looks like it might be one of the phillips
all-in-one codec/usb chips which would probably make it pretty easy to
support.
                        thanks,
                         rob


----
Rob Melby
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
Internet: rob@kaybee.org, gt4255a@prism.gatech.edu

From - Fri Jul 30 19:16:40 1999
Received: from sculpscape.wakkanet.fi (IDENT:root@cvx-1-96.dyn.nic.fi [62.236.97.96])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id DAA07389
	for <slinkp@ulster.net>; Fri, 30 Jul 1999 03:41:37 -0400
Received: (from root@localhost)
	by sculpscape.wakkanet.fi (8.8.7/8.8.7) id IAA08564;
	Fri, 30 Jul 1999 08:00:30 +0300
Date: Fri, 30 Jul 1999 08:00:30 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
To: Paul Winkler <slinkp@ulster.net>
cc: Kai Vehmanen <kaiv@wakkanet.fi>
Subject: Re: [linux-audio-dev] Recording: What do we need now ?
In-Reply-To: <37A11BEA.1B18345D@ulster.net>
Message-ID: <%D9So3oBEq@sculpcave>
X-User-Agent: Mana 4.0beta (Linux)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 0d41cf1e0e655a63fad66d95979980db

On Thu, 29 Jul 1999, Paul Winkler wrote:

>> need one stereo-input. Anyway, I've done a lot of recording using
>> one card as a monitor-output and the other one for recording. This
>> has worked quite well. Basicly the sync isn't controlled in any way.
> REally? I just downloaded ecasound last night (binary no-qt, no-alsa rpm
> ) and I'm having a hard time getting things to sync up _at all_, on just
> one soundcard ... lots of drift going on and I don't know why... I'll
> write again if I do some more extensive testing.

Hmm, what version did you use (stable, 1.3.1 or dev, 1.4.x),
parameters, sound drivers and what kind of machine? As there isn't any
special sync control, you should use smalll buffersizes (-b:64 -> 64
samples works quite nicely) and raise ecasound's priority (-r).

As I released ecasound just a month ago, it really needs testing.
Anyway, I've had success in using two soundcard, but yesterday, when I
tested simultanious input, I didn't get very good results. I guess
I should have tested this more a long time ago...

-- 
Kai Vehmanen ----------------------------- CS, University of Turku, Finland
 : email                                 mailto:kaiv@wakkanet.fi
 : audio processing for linux            http://www.wakkanet.fi/ecasound/
 : my music (ambient-idm-rock-...mp3/ra) http://www.wakkanet.fi/sculpscape/


From - Sun Aug  1 02:26:16 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA04637
	for <slinkp@ulster.net>; Sat, 31 Jul 1999 21:45:29 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA05826 for linux-audio-dev-list; Sat, 31 Jul 1999 21:03:36 -0400
Received: from fep02-svc.tin.it (mta02-acc.tin.it [212.216.176.33]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA05823 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 31 Jul 1999 21:03:33 -0400
Received: from tin.it ([212.216.160.118]) by fep02-svc.tin.it
          (InterMail v4.01.01.02 201-229-111-106) with ESMTP
          id <19990801010103.RVMV16170.fep02-svc@tin.it>;
          Sun, 1 Aug 1999 03:01:03 +0200
Message-ID: <37A39AA4.9BE7068F@tin.it>
Date: Sun, 01 Aug 1999 02:53:56 +0200
From: Maurizio Umberto Puxeddu <umbpux@tin.it>
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Erik de Castro Lopo <erikd@zip.com.au>
CC: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [CUD] Re: [linux-audio-dev] What do we need now ?
References: <379DC861.A2828F74@bright.net> <9907271714410M.13494@mtg150.upf.es> <379DF1FA.8922DEE8@tin.it> <379E1FF1.11BB3EFF@zip.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 9fa1fe51f5bb9280c010284a5da2e99b

Erik de Castro Lopo wrote:
> 
> Maurizio Umberto Puxeddu wrote:

> <snip>
> 
> > 1) Do you think that running audio driver (and other audio services
> > daemons) under RTLinux could improve the quality of the audio for Linux?
> 
> I've been messing about with coompute heavy audio programs and found
> that the built in Linux scheduler has Realtime features (man
> sched_setscheduler).
I'll make some experiment. Thanks. 

> The only drawback is that the program needs
> to be setuid root.
The RTLinux *only* drawback is that you have to write you programs ad
hoc. I found that with pthread_attr_setsched*() calls I can set sched
policy and priority for each thread!

Now I *only* need a more powerful machine :(

Thanks,
Umberto

From - Sun Aug  1 22:55:36 1999
Received: from sculpscape.wakkanet.fi (IDENT:root@cvx-2-13.dyn.nic.fi [62.236.99.13])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id OAA08566
	for <slinkp@ulster.net>; Sun, 1 Aug 1999 14:46:34 -0400
Received: (from root@localhost)
	by sculpscape.wakkanet.fi (8.8.7/8.8.7) id TAA01254;
	Sun, 1 Aug 1999 19:55:31 +0300
Date: Sun, 1 Aug 1999 19:55:31 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
To: Paul Winkler <slinkp@ulster.net>
cc: Kai Vehmanen <kaiv@wakkanet.fi>
Subject: Re: [linux-audio-dev] Recording: What do we need now ?
In-Reply-To: <37A23AB9.38E591AE@ulster.net>
Message-ID: <%tjGp3w9AM@sculpcave>
X-User-Agent: Mana 4.0beta (Linux)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: U
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 88bcb5bd6a40fab70ba96c1a4c53341f

On Fri, 30 Jul 1999, Paul Winkler wrote:

> I was definitely using -r, I think I tried many bufersizes (32, 64, 128)
> but found that I was getting pauses in the monitor track at anything
> less than 128, which made it impossible to play along accurately...
> Larger buffer sizes fixed that but then the new track is badly out of
> sync from start to finish. At 128, I found that things start reasonably
> in sync and then drift quite a lot very rapidly, even when mixing the
> two files to a file rather than /dev/dsp.

Hmm, what command line params did you use? It might help to see the
whole setup. It's a bit odd that it drifts out of sync. From
ecasound's point of view, the critical point is when recording 
is started. After this, streams should stay in sync if no
under/overruns happen. 

> kernel: 2.0.36
> distro: RedHat 5.2
[...]
> cpu: celeron-333 (not overclocked)
> cheap PC100 motherboard, running at 66 mhz bus
> 64 mb SDRAM
> maxtor EIDE hard drive
[...]
> I was running X at the time, maybe I'll try again with it off, see if
> that helps. I might also try running suid root and see if I can set the
> priority to -20.

Well, at least your hardware should be up to. I use a p166mmx 
for testing... I also do most testing with root priledges, so 
this might also help.

> I think the hard-disk recording aspect of ecasound is a great idea, and
> I find the interface not hard to use; I've always thought there should
> be a good, simple command-line full-duplex recording tool.

That's good to hear. These sync issues will need to be solved, but
after that ecasound should be quite a useful tool. And there 
really is lots of room for optimization. So far I've tried to avoid
all system-specific/non-standard optimization hacks and concentrated
on the design.

> Have you considered adding the ability to work with multi-channel files?
> And use some channels for monitoring while recording to other channels?
> The advantage is that it could help reduce the amount of seeking the
> disk has to do. That could help when you start pushing the limits. In
> some ways, reading from one .wav file and writing to another is more
> convenient, but I suspect it limits performance somewhat. At least, that
> makes sense to me; I have not done any kind of testing to really verify
> if that's so...

Hmm, I've tried to keep an open design and multi-channel support
should be an easy thing to add. But this approach has its downsides. 
Using other software with ecasound is easy as all material is in 
separate files. You don't need to import or export and you 
can easily move your recording project to a new environment.
But I'll keep this in mind.

-- 
Kai Vehmanen ----------------------------- CS, University of Turku, Finland
 : email                                 mailto:kaiv@wakkanet.fi
 : audio processing for linux            http://www.wakkanet.fi/ecasound/
 : my music (ambient-idm-rock-...mp3/ra) http://www.wakkanet.fi/sculpscape/


From - Tue Aug  3 03:41:21 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA23744
	for <slinkp@ulster.net>; Mon, 2 Aug 1999 09:10:13 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA07900 for linux-audio-dev-list; Mon, 2 Aug 1999 08:10:39 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA07897 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 2 Aug 1999 08:10:33 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S42810AbPHBMHh>; Mon, 2 Aug 1999 15:07:37 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca,
        csound-unix-dev@ilogic.com.au
In-reply-to: <%rien3YtDw@sculpcave> (message from Kai Vehmanen on Wed, 28 Jul
	1999 02:30:01 +0300 (EEST))
Subject: Re: [CUD] Re: [linux-audio-dev] What do we need now ?
Message-Id: <19990802120739Z42810-2248+2529@nic.funet.fi>
Date:   Mon, 2 Aug 1999 15:07:37 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5b0e65a81e1f6112a4690bf411ae8bf4

>From:   Kai Vehmanen <kaiv@wakkanet.fi>
>
>It seems that many
>ambitious audio projects have died because unrealistic goals.

Absolutely not true! Just take a look at commercial software, they
have not died.

IMHO, many projects have died because people have not realized that
we should organize the project just like they do in Real Work.

GIMP succeeded only because the coders had also a glue about image
processing program -- but still I see the GIMP is not very thought
one and has many lacks starting from user interface. Perhaps some
of those bad UI decisions come from PhotoShop and alike but they are
quite non-intuitive and garbled.

Most users don't have a glue what they should expect from the software.
They use them blindly and may not even see there is something wrong
(e.g., selection problem in most of the audio software). That is why
we should take this seriously even it is only question of the fun for
all of us.

Yours,

Juhana

From - Tue Aug  3 03:41:22 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA26923
	for <slinkp@ulster.net>; Mon, 2 Aug 1999 09:35:03 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA07942 for linux-audio-dev-list; Mon, 2 Aug 1999 08:48:10 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA07939 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 2 Aug 1999 08:48:05 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S42880AbPHBMpT>; Mon, 2 Aug 1999 15:45:19 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <379E7A65.E2314671@ulster.net> (message from Paul Winkler on Tue,
	27 Jul 1999 23:35:01 -0400)
Subject: Re: [linux-audio-dev] Re: [CUD] What do we need now ?
Message-Id: <19990802124520Z42880-2248+2532@nic.funet.fi>
Date:   Mon, 2 Aug 1999 15:45:19 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 6412075dd96b42d4e5d97b327e19c150

>From:   Paul Winkler <slinkp@ulster.net>
>> I have set up GNU Audio Software Project (GASP) webpages at
>> "http://www.funet.fi/~kouhia/gasp/". Any matter related to audio software
>
>This is a very nice idea. Perhaps people on the list would consider
>placing things they're already working on there, so novice developers
>could more easily see what sort of code is available to look at?

Absolutely! I would like to get even very rhough specs and designs of
those software and to write better explanation in GASP pages. Many software
is missing design and implementation documents and I would like to
change that situation.

Specially now I would like to have anything on how flow systems and
MIDI sequencers works and how they work together.
 
I'm quite sure we find a common stuff from all projects and we could
write a common library modules for them. Then if we improve something,
the change can be made only to one place. Well, at least future software
can use the library modules if authors are not used to replace their
code with common code.

>I'm talking about is basically a "multitrack sequencer".  Except that
>protools DOES "store...the audio signal as does the wave editor".

I have written unclear (actually, badly) but basically the drag and drop
mixing window is only handling sequencer data even the events indeed do
control synth emulators and wave players (say).

Yours,
 
Juhana

From - Tue Aug  3 03:41:28 1999
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id NAA29391
	for <slinkp@ulster.net>; Mon, 2 Aug 1999 13:44:12 -0400
Received: from bright.net (find-cas2-cs-48.dial.bright.net [209.143.26.202])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id NAA02203;
	Mon, 2 Aug 1999 13:32:47 -0400 (EDT)
Sender: root@sparticus.bright.net
Message-ID: <37A5DAC5.4BF864D5@bright.net>
Date: Mon, 02 Aug 1999 13:52:05 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Winkler <slinkp@ulster.net>
Subject: Re: Snd question(s) and: STOP THE PRESS !!!
References: <379EA243.62FCC993@bright.net> <379EA7A1.4F8296D@ulster.net> <379F0322.3D7D936F@bright.net> <379F7294.F7F2076B@ulster.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 326b30aef777a1783fc98390576d9056

Paul Winkler wrote:

> I forgot! Yes, I had to upgrade Guile before the RPM would even install
> (that's sometimes a nice feature of rpms...)
> I now have guile-1.3-6

Okay, I'll try the whole thing over again. I really want to check out
the plug-in stuff in order to write about it from 1st-hand experience.
 
> > I really like his idea. Integrating Csound into something like KWave or

> Gak! We had to use vi on the NeXT when I was at Bard... for some reason
> that was the only plain-text editor we had... I couldn't stand it. I
> love emacs. We must fight now.

vi rules ! vi users will conquer Redmond !! You seemed like such a nice
person... well, we all have our faults, I guess... ;)
 
== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Tue Aug  3 03:41:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id CAA24199
	for <slinkp@ulster.net>; Tue, 3 Aug 1999 02:39:30 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id CAA09102 for linux-audio-dev-list; Tue, 3 Aug 1999 02:02:59 -0400
Received: from cs.tut.fi (varis.cs.tut.fi [130.230.4.2]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA09099 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 3 Aug 1999 02:02:56 -0400
Received: from korppi.cs.tut.fi (jams@korppi.cs.tut.fi [130.230.4.3])
	by cs.tut.fi (8.8.8/8.8.8) with ESMTP id JAA04510
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 3 Aug 1999 09:00:41 +0300 (EET DST)
Received: (from jams@localhost)
          by korppi.cs.tut.fi (8.8.5/8.8.4)
	  id JAA23686; Tue, 3 Aug 1999 09:00:20 +0300 (EET DST)
To: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Berkeley sfront
From: jams@cs.tut.fi (Jarno Seppanen)
Reply-To: jams@cs.tut.fi (Jarno Seppanen)
X-Url: http://www.modeemi.cs.tut.fi/~jams/
Date: 03 Aug 1999 09:00:19 +0300
Message-ID: <ruvso61h098.fsf@korppi.cs.tut.fi>
Lines: 3
X-Mailer: Gnus v5.4.66/Emacs 19.31
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 23b531f14d2eaa4fbe76326572887021

Cool software of the week: http://www.cs.berkeley.edu/~lazzaro/sa/index.html
-- 
-Jarno

From - Tue Aug  3 23:21:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA04857
	for <slinkp@ulster.net>; Tue, 3 Aug 1999 07:49:40 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id HAA09620 for linux-audio-dev-list; Tue, 3 Aug 1999 07:05:26 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA09617 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 3 Aug 1999 07:05:23 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m11BcGg-000dzDC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Tue, 3 Aug 1999 12:58:02 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Tue,  3 Aug 1999 12:57:58 +0200 (CEST)
To: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] YAVOM
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14246.51337.985428.785047@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 180d971e39e67257e37f01e0f9670441



Yet Another Version Of Mix
==========================

As I have had terrible problems using Mix on my 1048x768 monitor I have
hacked it to fit on the screen. Additionally I have modified the
tich stuff to do some autodetection of wav and aiff files.

<http://gige.epy.co.at/software/mix/>

mix-0.56.1.tar.gz

Debian slink packages at 
http://gige.epy.co.at/debian/dists/stable/main/binary-i386/

Guenter

From - Tue Aug  3 23:21:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA15586
	for <slinkp@ulster.net>; Tue, 3 Aug 1999 09:31:59 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA09749 for linux-audio-dev-list; Tue, 3 Aug 1999 08:45:55 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA09746 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 3 Aug 1999 08:45:52 -0400
Received: from bright.net (find-cas1-cs-45.dial.bright.net [209.143.26.148])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id IAA26435;
	Tue, 3 Aug 1999 08:43:11 -0400 (EDT)
Message-ID: <37A6E85D.C1D6DC54@bright.net>
Date: Tue, 03 Aug 1999 09:02:21 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Guenter Geiger <geiger@epy.co.at>
CC: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] YAVOM
References: <14246.51337.985428.785047@gige>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 55123120016c08a09ddd7fce7f8f7f53

Guenter Geiger wrote:
 
> Yet Another Version Of Mix
> ==========================

One more doesn't hurt... ;)

> As I have had terrible problems using Mix on my 1048x768 monitor I have
> hacked it to fit on the screen. Additionally I have modified the
> tich stuff to do some autodetection of wav and aiff files.

Nice work on the tich stuff, Guenter. However, I have a problem that you
may be able to help me sort out:

  When I select a new track for a soundfile (in File/Add Soundfile) the
radio buttons go crazy, i.e., the default button (1) and the newly
selected button (whatever) start flashing back & forth like they're
caught in a bad loop. After a few seconds the program segfaults. I can
work around this by changing these settings:

	*trackR.radioBehavior:		True
	*trackR.radioAlwaysOne:		True

to False (which changes the radio buttons to check buttons). I also
tried changing this setting:

	*trackR.orientation:		XmHORIZONTAL

to XmVERTICAL, since I noted that the radio buttons worked fine in other
dialog boxes if the buttons are in a vertical orientation. I was
rewarded with an elongated window but no buttons at all.

This problem exists on any version of Mix that I build. Any commentary
or suggestions ?

Curiously this problem just seems to have started out of nowhere. I
don't recall updating my LessTif stuff recently, yet the problem seems
related to LessTif widget behavior. I'm stumped on this one and would
really appreciate some help solving the problem.

I notice two sliders now per track. What does the added slider do ?

Other additions to pu on the TODO list might include activating the MIDI
support, debugging the network connection stuff, and actually making the
Region selector work (though Dr. Hammer tells me it wasn't completed).

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Tue Aug  3 23:21:28 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA01045
	for <slinkp@ulster.net>; Tue, 3 Aug 1999 11:45:49 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA09915 for linux-audio-dev-list; Tue, 3 Aug 1999 10:55:35 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA09912 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 3 Aug 1999 10:55:31 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m11BfrG-000dzDC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Tue, 3 Aug 1999 16:48:02 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Tue,  3 Aug 1999 16:48:02 +0200 (CEST)
To: Dave Phillips <dlphilp@bright.net>
Cc: Guenter Geiger <geiger@epy.co.at>,
        linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] YAVOM
In-Reply-To: <37A6E85D.C1D6DC54@bright.net>
References: <14246.51337.985428.785047@gige>
	<37A6E85D.C1D6DC54@bright.net>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14246.64911.260139.591885@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: fa757f9149b54f3cde07b375b3cefe9f

Dave Phillips writes:
 > Nice work on the tich stuff, Guenter. However, I have a problem that you
 > may be able to help me sort out:

Sorry .. I can't reproduce this, my version of lesstif is 0.88, what's 
yours ?

 > 
 > Curiously this problem just seems to have started out of nowhere. I
 > don't recall updating my LessTif stuff recently, yet the problem seems
 > related to LessTif widget behavior. I'm stumped on this one and would
 > really appreciate some help solving the problem.
 > 

This is the main problem about apps using motif. It seems that they
constantly break at some point, with some version of lesstif.
Since I have been packaging snd for Debian I'm constantly trying to
get it running, but no chance until now.
It worked quite well, back when I had lesstif-0.83 or so :( 

 > I notice two sliders now per track. What does the added slider do ?
 >

 The new slider was only hidden in the other versions and is used 
to zoom the waveform.
 
 > Other additions to put on the TODO list might include activating the MIDI
 > support, debugging the network connection stuff, and actually making the
 > Region selector work (though Dr. Hammer tells me it wasn't completed).
 > 

Yes, I will add this to the  TODO list. Actually, with a decent waveform
editor mix is not that far away form being a very useful tool.

Additionally, there may be some drawing bugs due to my interface
changes, (just detected one when using the zoom slider on stereo files
:). So keep me posted on bugs, I may be able to fix them.


Guenter

From - Tue Aug  3 23:21:31 1999
Received: from taz.ulster.net (root@taz.ulster.net [208.148.73.10])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id PAA28155
	for <slinkp@ulster.net>; Tue, 3 Aug 1999 15:14:30 -0400
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34]) by taz.ulster.net (8.8.5/8.7.3) with SMTP id IAA12665 for <slinkp@ulster.net>; Tue, 3 Aug 1999 08:11:50 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA10108 for linux-audio-dev-list; Tue, 3 Aug 1999 12:27:30 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA10105 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 3 Aug 1999 12:27:27 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m11BhIM-000dzDC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Tue, 3 Aug 1999 18:20:06 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Tue,  3 Aug 1999 18:20:06 +0200 (CEST)
To: Guenter Geiger <geiger@epy.co.at>
Cc: Dave Phillips <dlphilp@bright.net>,
        linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] YAVOM
In-Reply-To: <14246.64911.260139.591885@gige>
References: <14246.51337.985428.785047@gige>
	<37A6E85D.C1D6DC54@bright.net>
	<14246.64911.260139.591885@gige>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14247.5769.995993.215082@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f803b6f4c8e18c28bb16b6c858428342

Guenter Geiger writes:
 > Sorry .. I can't reproduce this, my version of lesstif is 0.88, what's 
 > yours ?

 precicely said 0.88.1

G.

From - Tue Aug  3 23:21:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA16733
	for <slinkp@ulster.net>; Tue, 3 Aug 1999 13:39:13 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA10153 for linux-audio-dev-list; Tue, 3 Aug 1999 12:52:06 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA10150 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 3 Aug 1999 12:52:03 -0400
Received: from bright.net (find-cas1-cs-50.dial.bright.net [209.143.26.153])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id MAA24999;
	Tue, 3 Aug 1999 12:49:14 -0400 (EDT)
Message-ID: <37A7220C.168D561C@bright.net>
Date: Tue, 03 Aug 1999 13:08:28 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Guenter Geiger <geiger@epy.co.at>
CC: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] YAVOM
References: <14246.51337.985428.785047@gige>
		<37A6E85D.C1D6DC54@bright.net>
		<14246.64911.260139.591885@gige> <14247.5769.995993.215082@gige>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 38d1b93b6957c7bcd304485e27c60a07

Guenter Geiger wrote:

>  precicely said 0.88.1

Well, thanks for the tip, Guenter. Sure enough, the problem was with an
earlier version of LessTif (1.0.2). Linking to a later version (1.2)
fixed the problem.

I would like to make a call to any developers who might be interested in
furthering Mix. I agree that it needs only a few nice items in order to
make it a killer soundfile mixer.

My wish-list would include:

	enabling the MIDI control
	enabling support for regions
	a better configuration tool
	support for network connections (might already work, not tested)

I don't mind that it doesn't have an internal file editor, calling to an
external editor of my choice is sufficient for me. 

Anyone else want to join in the fun ?

Speaking of projects: Boris Nagels has informed me that he will release
Multitrack as a GPL'd program. He's on vacation now, but when he returns
he intends to give the code over to the Linux community. Here's a great
chance to work on a functioning multitrack recorder, one that can be
used from the console or X. It has faults, but perhaps a group would
like to fix those faults ?

A couple of good projects here...

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Tue Aug  3 23:21:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA11286
	for <slinkp@ulster.net>; Tue, 3 Aug 1999 16:47:40 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA10413 for linux-audio-dev-list; Tue, 3 Aug 1999 16:04:46 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA10409 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 3 Aug 1999 16:04:42 -0400
Received: from bright.net (find-cas1-cs-9.dial.bright.net [209.143.26.112])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id QAA20489;
	Tue, 3 Aug 1999 16:02:02 -0400 (EDT)
Message-ID: <37A74F3E.41E3DA0C@bright.net>
Date: Tue, 03 Aug 1999 16:21:18 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Guenter Geiger <geiger@epy.co.at>
CC: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] YAVOM
References: <14246.51337.985428.785047@gige>
		<37A6E85D.C1D6DC54@bright.net> <14246.64911.260139.591885@gige>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 295bc4a8c772bf6a41796750d6b5cea6

Greetings:

  Guenter, in your TODO list you wrote:

	load Soundfile: window should close after OK.  done

and indeed that's what it does. It may seem strange, but I liked having
the window stay open until I cancelled it. That way, I could keep
assigning files to tracks without having to pop open that window each
time. The accelerator keys work fine, so it's not a terrible loss for
me.

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Wed Aug  4 13:11:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA21681
	for <slinkp@ulster.net>; Wed, 4 Aug 1999 06:10:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA11533 for linux-audio-dev-list; Wed, 4 Aug 1999 05:19:57 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA11530 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 4 Aug 1999 05:19:53 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m11Bx62-000dyqC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Wed, 4 Aug 1999 11:12:26 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Wed,  4 Aug 1999 11:12:26 +0200 (CEST)
To: Dave Phillips <dlphilp@bright.net>
Cc: Guenter Geiger <geiger@epy.co.at>,
        linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] YAVOM
In-Reply-To: <37A7220C.168D561C@bright.net>
References: <14246.51337.985428.785047@gige>
	<37A6E85D.C1D6DC54@bright.net>
	<14246.64911.260139.591885@gige>
	<14247.5769.995993.215082@gige>
	<37A7220C.168D561C@bright.net>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14247.65522.329304.488993@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 22398349b39acbcde03ef54b50b31b07

Dave Phillips writes:
 > I would like to make a call to any developers who might be interested in
 > furthering Mix. I agree that it needs only a few nice items in order to
 > make it a killer soundfile mixer.
 > 
 > My wish-list would include:
 > 
 > 	enabling the MIDI control
 > 	enabling support for regions
 > 	a better configuration tool
 > 	support for network connections (might already work, not tested)
 > 
 > I don't mind that it doesn't have an internal file editor, calling to an
 > external editor of my choice is sufficient for me. 
 > 
 > Anyone else want to join in the fun ?
 > 

 I'm on it. I pretty well know the code now.
 Needed is feedback and bug reports, ideas  ...
 and coming to it, I need a copyright for the code, because, legally,
 I'm not allowed to do anything with it at the moment.
 Dave, you are in connection with Dr. Hammer already, can you ask him 
 about that ?

 I've added Dave suggestions to my TODO list.
 If anyone wants to help in developing mix further, I'm open to all
 suggestions ..

 Guenter


From - Wed Aug  4 13:11:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA13828
	for <slinkp@ulster.net>; Wed, 4 Aug 1999 10:24:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA11808 for linux-audio-dev-list; Wed, 4 Aug 1999 09:31:15 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA11805 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 4 Aug 1999 09:31:12 -0400
Received: from bright.net (find-cas1-cs-21.dial.bright.net [209.143.26.124])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id JAA09970;
	Wed, 4 Aug 1999 09:28:10 -0400 (EDT)
Message-ID: <37A84466.3E8C6514@bright.net>
Date: Wed, 04 Aug 1999 09:47:18 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Guenter Geiger <geiger@epy.co.at>,
        Reine Jonsson <reine@mbox314.swipnet.se>,
        Umberto Puxeddu <umbpux@tin.it>
CC: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] YAVOM
References: <14246.51337.985428.785047@gige>
		<37A6E85D.C1D6DC54@bright.net>
		<14246.64911.260139.591885@gige>
		<14247.5769.995993.215082@gige>
		<37A7220C.168D561C@bright.net> <14247.65522.329304.488993@gige>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 90657f6e91f7f8cb8ae8305a0a620655

Guenter Geiger wrote:

>  I'm on it. I pretty well know the code now.
>  Needed is feedback and bug reports, ideas  ...

A few things: If you're planning to hack the MIDI stuff, be sure to
review the original sources, I changed some things that Reine may have
simply included without knowing they were altered. Or are you working
from Dr Hammer's sources from NoTAM ?

Also, there is a program called Apprentice which among other things
provides a viewer for iv files. Perhaps an addition to the app_data
structure would be helpful ?

Docs need revised. Many features aren't mentioned at all in the
documentation, so some experiments will need to be made.

The code for Regions is broken, I think. Dr Hammer indicated that he
never did finish it, so there's a project all by itself.

>  and coming to it, I need a copyright for the code, because, legally,
>  I'm not allowed to do anything with it at the moment.
>  Dave, you are in connection with Dr. Hammer already, can you ask him
>  about that ?

I will do it. Umberto Puxeddu received the okay to utilize Dr Hammer's
code in a GPL'd app, so I don't expect problems there. I'll ask him
about GPLing all his code, but he does make use of some proprietary code
(Matrix.c and Clip.c). Also, in his Ceres he uses F.R. Moore's FFT code
(from Elements Of Computer Music).

Richard Kent will also need to be notified, though again I don't expect
any problems using his code.
 
>  If anyone wants to help in developing mix further, I'm open to all
>  suggestions ..

I'm a bit strapped for time these days, but I was planning to include
Mix in my book anyway. I also planned on including it on the
accompanying CD, so this project is quite timely. I will help as I'm
able. Perhaps I can do most on the documentation ?

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Fri Aug  6 04:36:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA17828
	for <slinkp@ulster.net>; Thu, 5 Aug 1999 06:03:05 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA13448 for linux-audio-dev-list; Thu, 5 Aug 1999 05:26:19 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA13445 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 5 Aug 1999 05:26:14 -0400
Received: from debian (dialup83-4-46.swipnet.se [130.244.83.238]) 
          by mb06.swip.net (8.8.8/8.8.8) with ESMTP 
          id LAA29308; 
          Thu, 5 Aug 1999 11:23:26 +0200 (MET DST)
Received: from debian.mbox314.swipnet.se (really [127.0.0.1]) by debian
	via in.smtpd with esmtp (ident root using rfc1413)
	id <m11C3kE-0017qzC@debian> (Debian Smail3.2.0.101)
	for <dlphilp@bright.net>; Wed, 4 Aug 1999 18:18:22 +0200 (CEST) 
Message-Id: <m11C3kE-0017qzC@debian>
Date: Wed, 4 Aug 1999 18:18:22 +0200 (CEST)
From: reine@mbox314.swipnet.se
Reply-To: reine@mbox314.swipnet.se
Subject: Re: [linux-audio-dev] YAVOM
To: dlphilp@bright.net
cc: linux-audio-dev@ginette.musique.umontreal.ca
In-Reply-To: <37A84466.3E8C6514@bright.net>
MIME-Version: 1.0
Content-Type: TEXT/plain; CHARSET=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d47c08335821cd88ecbbf3c4d948b5d8

On  4 Aug, Dave Phillips wrote:
> Guenter Geiger wrote:
> 
>>  I'm on it. I pretty well know the code now.
>>  Needed is feedback and bug reports, ideas  ...
> 
> A few things: If you're planning to hack the MIDI stuff, be sure to
> review the original sources, I changed some things that Reine may have
> simply included without knowing they were altered. Or are you working
> from Dr Hammer's sources from NoTAM ?
> 

I did not consider Midi at all when I did the small/ugly wav-hack.
Don't be to sure that I knew what I did ;).



From - Wed Aug  4 13:41:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA09464
	for <slinkp@ulster.net>; Wed, 4 Aug 1999 13:43:51 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA12066 for linux-audio-dev-list; Wed, 4 Aug 1999 12:53:56 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA12063 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 4 Aug 1999 12:53:52 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m11C4BH-000dyqC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Wed, 4 Aug 1999 18:46:19 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Wed,  4 Aug 1999 18:46:19 +0200 (CEST)
To: Dave Phillips <dlphilp@bright.net>
Cc: Guenter Geiger <geiger@epy.co.at>,
        Reine Jonsson <reine@mbox314.swipnet.se>,
        Umberto Puxeddu <umbpux@tin.it>,
        linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] YAVOM
In-Reply-To: <37A84466.3E8C6514@bright.net>
References: <14246.51337.985428.785047@gige>
	<37A6E85D.C1D6DC54@bright.net>
	<14246.64911.260139.591885@gige>
	<14247.5769.995993.215082@gige>
	<37A7220C.168D561C@bright.net>
	<14247.65522.329304.488993@gige>
	<37A84466.3E8C6514@bright.net>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14248.20640.524816.779564@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d24766e17ec9a592c7ef572534c40111

Dave Phillips writes:
 > >  and coming to it, I need a copyright for the code, because, legally,
 > >  I'm not allowed to do anything with it at the moment.
 > >  Dave, you are in connection with Dr. Hammer already, can you ask him
 > >  about that ?
 > 
 > I will do it. 

Thanks..

 > >  If anyone wants to help in developing mix further, I'm open to all
 > >  suggestions ..
 > 
 > I'm a bit strapped for time these days, but I was planning to include
 > Mix in my book anyway. I also planned on including it on the
 > accompanying CD, so this project is quite timely. I will help as I'm
 > able. Perhaps I can do most on the documentation ?
 > 

Great, documentation is very important there. The goal for the moment
is to make mix behave like we (or the user) expects it to behave and 
document that behaviour.

If that can be reached we might think of adding pluggin support.

Speaking of that, a "free" plugin specification (VST 1.0 like), but in
"C"  would be great for all projects. We could use mix as a testfield. 
Do you know about something like that ?

Guenter 

From - Thu Aug  5 00:27:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA15302
	for <slinkp@ulster.net>; Wed, 4 Aug 1999 18:15:09 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA12386 for linux-audio-dev-list; Wed, 4 Aug 1999 17:33:44 -0400
Received: from fep02-svc.tin.it (mta02-acc.tin.it [212.216.176.33]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA12383 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 4 Aug 1999 17:33:40 -0400
Received: from tin.it ([212.216.162.168]) by fep02-svc.tin.it
          (InterMail v4.01.01.02 201-229-111-106) with ESMTP
          id <19990804213049.JEWO16170.fep02-svc@tin.it>;
          Wed, 4 Aug 1999 23:30:49 +0200
Message-ID: <37A8AF40.F40EE4D2@tin.it>
Date: Wed, 04 Aug 1999 23:23:12 +0200
From: Maurizio Umberto Puxeddu <umbpux@tin.it>
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Dave Phillips <dlphilp@bright.net>
CC: Guenter Geiger <geiger@epy.co.at>,
        Reine Jonsson <reine@mbox314.swipnet.se>,
        "linux-audio-dev@ginette.musique.umontreal.ca" 
 <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: GPL'ing Dr.Hammer's code [was Re: [linux-audio-dev] YAVOM]
References: <14246.51337.985428.785047@gige>
					<37A6E85D.C1D6DC54@bright.net>
					<14246.64911.260139.591885@gige>
					<14247.5769.995993.215082@gige>
					<37A7220C.168D561C@bright.net> <14247.65522.329304.488993@gige> <37A84466.3E8C6514@bright.net>
Content-Type: text/plain; charset=x-user-defined
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 680cce24a251deca0a7d935ef2f3e83d

Hello.

Dave Phillips wrote:
> Guenter Geiger wrote:
> [...snip...]
> >  and coming to it, I need a copyright for the code, because, legally,
> >  I'm not allowed to do anything with it at the moment.
> >  Dave, you are in connection with Dr. Hammer already, can you ask him
> >  about that ?
> 
> I will do it. Umberto Puxeddu received the okay to utilize Dr Hammer's
> code in a GPL'd app, so I don't expect problems there. I'll ask him
> about GPLing all his code, but he does make use of some proprietary code
> (Matrix.c and Clip.c). Also, in his Ceres he uses F.R. Moore's FFT code
> (from Elements Of Computer Music).
I easily replaced rfft() and cfft() and bitreverse() functions with the
GPL'ed FFTW library (with the nice side-effect of a sensible performance
increasing). I only had to renormalize the FFTW data to make the rest of
the program work
correcly (see listener.cc file in my Libpt).
 
> [...snip...]
I don't know if the *vocoding* code comes from Moore's book too.
I asked to Dr.Hammer who written this functions (I'm talking about
makewindows(), shiftin(), fold() and convert(), that are present in both
ptps and ceres). If this code is by Moore too, it means that the GPL'ing
of the pitchtracking library is not valid and I'll immediately try to
rewrite it from scratch because I'd
like to solve this problem once for all.

I hope I can tell you the final words in few days.

Maurizio Umberto Puxeddu

From - Thu Aug  5 02:18:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id CAA07235
	for <slinkp@ulster.net>; Thu, 5 Aug 1999 02:19:02 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id BAA12926 for linux-audio-dev-list; Thu, 5 Aug 1999 01:40:45 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA12923 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 5 Aug 1999 01:40:41 -0400
Received: from ulster.net (port69.king.ulster.net [208.242.160.70])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id BAA05320
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 5 Aug 1999 01:49:34 -0400
Message-ID: <37A924AA.F35BD562@ulster.net>
Date: Thu, 05 Aug 1999 01:44:10 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Audio-oriented Linux distribution
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8003
X-Mozilla-Status2: 00000000
X-UIDL: d4820c06f844996ed9007e7bbc23027c

The hypothetical audio-oriented linux distribution seems to be a topic
of some interest. Those folks interested might like to keep an eye on
some kernel patches that might help us with the problems of realtime
work (latency and dropouts):

http://www.gardena.net:80/benno/linux/audio

Roger Larsson  <roger.larsson@skelleftea.mail.telia.com> sent me that
link for the Audio-Quality HOWTO. I asked if these patches might
eventaully make it into the kernel; Roger replied that kernel 2.2
feature freeze is imminent, but he has hopes for getting it into 2.4. In
the meantime, if the patches prove stable enough, we might think of
distributing them with the audio distro. From benno's page, it looks
like pretty substantial performance improvements are possible. This
could be another important step in making linux a music/audio platform
of choice.



On a tangent:

Would the hypothetical audio-linux distribution be targeted to
experienced Linux users, or to newbies, or both? If newbies, I've been
thinking about something lately. This doesn't have anything to do with
audio specifically... There's an awful lot of documentation that comes
on any linux CD: man pages, texinfo, HOWTOs... But I know that when I
was first starting out, it took me months to realize just how much was
there, how to find it, and how to read it when I found it. By contrast,
Winblows users can learn by trial and error and searching the built-in
Help system. Of course they will eventually need answers that the
Windows Help can't give, but still, it's a great resource because it is
so centralized -- you can always get into Help, it behaves the same for
every program, etc. 

This is a highly non-trivial problem to solve, but it seems to me that a
newbie-targeted distribution could do a few reasonably simple things to
be more welcoming:

*  A text file (let's call it NewUser.txt or something like that) placed
in your home directory that gives you a few quick introductory lessons:
e.g. 10 essential commands; how to switch to another virtual console so
you can try the examples in this file;  how to shut down the system
properly; where are the HOWTOs and a quick overview of what's in them; 
what's a man page and how do you read it; what is "info"; how to start
X-windows; what is "bash" and some tips on using it; what are the linux
newsgroups and how do I search archives of them; where to find a list of
good linux books, etc. etc. etc. All this information is already present
in any linux distribution, but it takes a long time to find it!

*  /etc/issue could by default have some real simple tips, like "New
user? Please read the file NewUser.txt in your home directory. (Your
home directory is where you start out when you log in, after typing your
password.) A good way to read the file is by typing the command "less
NewUser.txt"..." Something short that makes it very obvious how to get
started learning the system.

* X could be configured to, by default, pop up a window with some basic
tips on using X (like how to copy & paste... ummm... can't think what
else right now.) It should also tell you how to make the window stop
popping up once you're sick of it. We could also include something like
"Josh's Linux Guide" as a bookmark, or even the default home page, in
whatever is the default browser (netscape?). Josh's guide has a lot of
great newbie information and is redistributable:
http://jgo.local.net/LinuxGuide/
(although the links seem to be broken right now.)

* There should be somewhere, easily findable, a document that gives some
basic tips on teaching yourself linux effectively. I went to a LXNY
meeting (new york's free software group, a pseudo-LUG), at which Michael
Smith presented an abstract of a paper he was going to present at the
Bazaar, with a lot of good ideas on this, specifically ideas on taking
notes as you do things (see "man script"!)... things I wish I had known
two years ago.

Thoughts on this? Am I way off-topic?

----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Thu Aug  5 02:29:13 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id CAA07858
	for <slinkp@ulster.net>; Thu, 5 Aug 1999 02:28:53 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id BAA12944 for linux-audio-dev-list; Thu, 5 Aug 1999 01:46:42 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA12941 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 5 Aug 1999 01:46:40 -0400
Received: from ulster.net (port69.king.ulster.net [208.242.160.70])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id BAA05763
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 5 Aug 1999 01:55:34 -0400
Message-ID: <37A92612.11AF9B74@ulster.net>
Date: Thu, 05 Aug 1999 01:50:10 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Possibly useful library
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 78d09f81081f385f29e511a6074c1234

This might be of interest to c++ programmers...

I just downloaded split2000, a lossless compressor. I was interested to
see that the source comes with the following notice, in a libraries
directory called split2000/bcbase:

"This is the library used to build Broadcast 2000, Mix 2000, XPhone, and
Split 2000.  It was optimized for multithreaded audio programs...In
addition to GUI objects it contains various convenience objects of
interest to C++ programmers who don't want to get bogged down in the
standard g++ includes... Since Broadcast 2000 was Too Damn Expensive to
program, consider this library statically linkable in commercial
programs as long as you mention the author and redistribute the
library's source code when called upon.  Aside from this, everything
else from the following license applies...."

Then there follows the text of the GPL version 2.
So, you can use it.

-- 

----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Fri Aug  6 04:36:24 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id DAA09760
	for <slinkp@ulster.net>; Thu, 5 Aug 1999 03:08:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id CAA13082 for linux-audio-dev-list; Thu, 5 Aug 1999 02:31:55 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA13079 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 5 Aug 1999 02:31:52 -0400
Received: from ulster.net (port69.king.ulster.net [208.242.160.70])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id CAA08503
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 5 Aug 1999 02:40:47 -0400
Message-ID: <37A930AB.59BEE6D5@ulster.net>
Date: Thu, 05 Aug 1999 02:35:23 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Audio-oriented Linux distribution
References: <37A924AA.F35BD562@ulster.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b36ccf60cbdaa60ae2c4035e2a787a4d

I wrote:

> "Josh's Linux Guide" as a bookmark, or even the default home page, in
> whatever is the default browser (netscape?). Josh's guide has a lot of
> great newbie information and is redistributable:
> http://jgo.local.net/LinuxGuide/
> (although the links seem to be broken right now.)

They are, but josh just informed me that the page can also be accessed
at:
http://www.local.net/~jgo/LinuxGuide/

If we included something like this with a distribution, there might be
parts worth modifying, e.g. the page on setting up sound. Josh's
copyright permits this.


----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Fri Aug  6 04:36:25 1999
Received: from CS.Princeton.EDU (root@CS.Princeton.EDU [128.112.136.10])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id DAA10161
	for <slinkp@ulster.net>; Thu, 5 Aug 1999 03:17:38 -0400
Received: from ux01 (dgslomin@ux01 [128.112.169.21])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id DAA18303;
	Thu, 5 Aug 1999 03:03:44 -0400 (EDT)
Received: from localhost by ux01 (8.8.8+Sun) id DAA21236; Thu, 5 Aug 1999 03:03:44 -0400 (EDT)
Date: Thu, 5 Aug 1999 03:03:43 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: Paul Winkler <slinkp@ulster.net>
cc: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Audio-oriented Linux distribution
In-Reply-To: <37A924AA.F35BD562@ulster.net>
Message-ID: <Pine.GSO.4.10.9908050242290.19427-100000@ux01.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: afffa91965f9dc72751049811e178d8e


(In response to Paul Winkler's ideas for a guiding newbies in an audio
oriented or even regular Linux distribution:)

I very much like the suggestion of having newbie guides pop up by default.
I would go further by suggesting that context-specific ones come up at 
every stage in the user's experience:

1.  /etc/issue - Prompt them about logging in as root for the first time.

2.  /etc/motd - Welcome them to the system, and tell them how to use less
    to read ~/newuser.txt.  Keep in mind that using space to go forward a
    page and Q to quit is not automatic for them.

3.  ~/newuser.txt - Tell them how to start X (if it isn't set to do it by
    default).

4.  ~/.Xsession - Pop up a notepad-type app displaying preliminary
    instructions on how to use the default window manager / desktop 
    environment.  It should also say how to launch the master help 
    browser.  (These preliminary instructions are necessarily separate
    from the help browser itself because it covers things the are
    prerequisite to being able to use the help browser, like the
    peculiarities of the widget set and window manager.)

5.  There should be an X-based master help browser that can encompass a
    man page reader, info reader, html renderer (for howtos), and text
    viewer (for faqs).  KDE's help browser does a competant, but not
    perfect job at this, and I'm sure Gnome has something equivalent.
    All of the different locally stored help resources should be both
    heirarchically browsable and keyword searchable from here, and there
    should also be links and instructions from that to useful external
    resources (newsgroups, tutorial web sites, common ftp archives, etc).

These sort of guides do not actually solve the problem of inconsistent,
power user only interfaces which are common in Linux, but at least they
can help mitigate the problem in a logical manner.

Don't get me wrong, I like many power user features and appreciate that
they're there, but I prefer interfaces which start extremely simple and
only reveal their more complex features when you ask them to.

Wow, a post to the LAD list that has nothing to do with music.  
Sorry about that,
Div.

From - Fri Aug  6 04:36:34 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA03398
	for <slinkp@ulster.net>; Thu, 5 Aug 1999 09:28:26 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA13652 for linux-audio-dev-list; Thu, 5 Aug 1999 08:49:18 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id IAA13649 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 5 Aug 1999 08:49:15 -0400
From: est@hyperreal.org
Received: (qmail 26691 invoked by uid 162); 5 Aug 1999 12:46:30 -0000
Message-ID: <19990805124630.26690.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] Audio-oriented Linux distribution
In-Reply-To: <Pine.GSO.4.10.9908050242290.19427-100000@ux01.CS.Princeton.EDU>
 from David Slomin at "Aug 5, 1999 03:03:43 am"
To: David Slomin <dgslomin@CS.Princeton.EDU>
Date: Thu, 5 Aug 1999 05:46:30 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: a8c9d01aef5c194d1574204e238ec092

David Slomin discourseth:
> 
> 4.  ~/.Xsession - Pop up a notepad-type app displaying preliminary
>     instructions on how to use the default window manager / desktop 
>     environment.  It should also say how to launch the master help 
>     browser.  (These preliminary instructions are necessarily separate
>     from the help browser itself because it covers things the are
>     prerequisite to being able to use the help browser, like the
>     peculiarities of the widget set and window manager.)

Actually, Redhat 6.0 (for example) defaults to booting into X and the
Gnome help browser is right in front when it does.  So, I think your
aims here could be met by improving, if needed, the Gnome help browser
with tooltips, different content, etc.

E

From - Fri Aug  6 04:36:30 1999
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA01648
	for <slinkp@ulster.net>; Thu, 5 Aug 1999 09:14:14 -0400
From: est@hyperreal.org
Received: (qmail 1765 invoked by uid 162); 5 Aug 1999 13:02:24 -0000
Message-ID: <19990805130224.1764.qmail@hyperreal.org>
Subject: audio-oriented kernels
In-Reply-To: <37A924AA.F35BD562@ulster.net> from Paul Winkler at "Aug 5, 1999
 01:44:10 am"
To: Paul Winkler <slinkp@ulster.net>
Date: Thu, 5 Aug 1999 06:02:24 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8003
X-Mozilla-Status2: 00000000
X-UIDL: f3af8b73e4ea16c11d842a7a1e6fc8a6

Paul Winkler discourseth:
> The hypothetical audio-oriented linux distribution seems to be a topic
> of some interest. Those folks interested might like to keep an eye on
> some kernel patches that might help us with the problems of realtime
> work (latency and dropouts):

I've been helping to test these patches.  Saturday morning I could
reliably produce 50ms dropouts.  With the latest patches (which
haven't been made public yet since we've been resolving stability
problems), I can't produce greater than 3ms dropouts.

> Roger Larsson  <roger.larsson@skelleftea.mail.telia.com> sent me that
> link for the Audio-Quality HOWTO. I asked if these patches might
> eventaully make it into the kernel; Roger replied that kernel 2.2
> feature freeze is imminent, but he has hopes for getting it into 2.4.

True if you add .2 to both those numbers. :)

> In the meantime, if the patches prove stable enough, we might think of
> distributing them with the audio distro.

I think they will be stable enough.  If they're absent from the
standard kernel it may be as much because they point to areas that
really need to be rewritten.  The kernel life-cycle isn't served by
making things more intelligently broken. :)

In addition to latency patches, I'm beginning to regard including a
patch that accerlerates the timer interrupt to greater than the
current 100hz as essential.  It provides a means of escaping from
these monolithic applications that are clocked by the soundcard.

Regards,

Eric

From - Fri Aug  6 04:36:32 1999
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id JAA03133
	for <slinkp@ulster.net>; Thu, 5 Aug 1999 09:26:00 -0400
Received: from bright.net (find-cas1-cs-2.dial.bright.net [209.143.26.105])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id JAA00447;
	Thu, 5 Aug 1999 09:14:11 -0400 (EDT)
Sender: root@sparticus.bright.net
Message-ID: <37A9929A.C72A18F6@bright.net>
Date: Thu, 05 Aug 1999 09:33:14 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Winkler <slinkp@ulster.net>
Subject: Re: [linux-audio-dev] Audio-oriented Linux distribution
References: <37A924AA.F35BD562@ulster.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 62b79a6c1265ca0bdc3080bb24c397ce

Paul Winkler wrote:
 
> The hypothetical audio-oriented linux distribution seems to be a topic
> of some interest.

Indeed. Judging from the number and quality of applications I'm
reviewing for the book I'd say it's time has come (or is very near).

Now, a dilemma: I'm to provide a disc for the book, and it will include
as many of the profiled items as I can get on it. When the publisher and
I began planning the book he was enthusiastic about the possibility of
including a Linux distro along with the apps. It appears that what
you're talking about would be exactly what he had in mind. So I ask you:
given that it actually came to be, what would you think of it being used
as the accompamying disc ?

I have concerns, since the book is going to be sold and people are going
to make money from it. However, if the disc were GPL'd I suppose that
would resolve my dilemma, though I'd still be somewhat uncomfortable.
Any suggestions or advice ?

> Would the hypothetical audio-linux distribution be targeted to
> experienced Linux users, or to newbies, or both? [snip]

Your questions are precisely the ones I've had to keep in mind while
writing chapters. I've opted for a presentation which will hopefully
suit both the new and the experienced users. A little tougher to do than
I thought...

> Thoughts on this? Am I way off-topic?

Even if it's OT it's of considerable importance to us. Getting audio up
and running under Linux isn't necessarily all that difficult, but it can
be touchy, especially so for complete newbies. Anything that helps them
can be considered relevant here.

Just my two pesetas...

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Fri Aug  6 04:36:37 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA10897
	for <slinkp@ulster.net>; Thu, 5 Aug 1999 10:20:02 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA13754 for linux-audio-dev-list; Thu, 5 Aug 1999 09:35:47 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA13751 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 5 Aug 1999 09:35:44 -0400
Received: from bright.net (find-cas1-cs-2.dial.bright.net [209.143.26.105])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id JAA20109;
	Thu, 5 Aug 1999 09:29:05 -0400 (EDT)
Message-ID: <37A99619.3585F0B7@bright.net>
Date: Thu, 05 Aug 1999 09:48:09 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Guenter Geiger <geiger@epy.co.at>
CC: Reine Jonsson <reine@mbox314.swipnet.se>, Umberto Puxeddu <umbpux@tin.it>,
        linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] YAVOM
References: <14246.51337.985428.785047@gige>
		<37A6E85D.C1D6DC54@bright.net>
		<14246.64911.260139.591885@gige>
		<14247.5769.995993.215082@gige>
		<37A7220C.168D561C@bright.net>
		<14247.65522.329304.488993@gige>
		<37A84466.3E8C6514@bright.net> <14248.20640.524816.779564@gige>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 541798b687486ff416bf8097494262fe

Guenter Geiger wrote:

> Great, documentation is very important there. The goal for the moment
> is to make mix behave like we (or the user) expects it to behave and
> document that behaviour.
> 
> If that can be reached we might think of adding pluggin support.

I'll start tracking all available docs for Mix and begin organizing a
new HTML help page.

I especially wanted to let everyone know that I've written to Dr. Hammer
and asked him about simply GPLing everything he's done that is available
for Linux users. I haven't heard from him yet. I also mentioned that we
can be flexible if the GPL doesn't satisfy him.
 
> Speaking of that, a "free" plugin specification (VST 1.0 like), but in
> "C"  would be great for all projects. We could use mix as a testfield.
> Do you know about something like that ?

This has been a major topic on the Csound and music-dsp lists lately. I
think the most knowledgable people on the subject might be Michael
Gogins, Paul Barton-Davis, and Juhana Sadeharju. If they're reading,
perhaps they have some commentary to add ?

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Fri Aug  6 04:36:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA20825
	for <slinkp@ulster.net>; Thu, 5 Aug 1999 11:24:54 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA13849 for linux-audio-dev-list; Thu, 5 Aug 1999 10:45:22 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id KAA13846 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 5 Aug 1999 10:45:13 -0400
From: est@hyperreal.org
Received: (qmail 6941 invoked by uid 162); 5 Aug 1999 14:42:19 -0000
Message-ID: <19990805144219.6938.qmail@hyperreal.org>
Subject: [linux-audio-dev] open plugin specification
In-Reply-To: <37A99619.3585F0B7@bright.net> from Dave Phillips at "Aug 5, 1999
 09:48:09 am"
To: Dave Phillips <dlphilp@bright.net>
Date: Thu, 5 Aug 1999 07:42:18 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 4829319970a7dbf1582a224e2cf08724

Dave Phillips discourseth:
>  
> > Speaking of that, a "free" plugin specification (VST 1.0 like), but in
> > "C"  would be great for all projects. We could use mix as a testfield.
> > Do you know about something like that ?
> 
> This has been a major topic on the Csound and music-dsp lists lately. I
> think the most knowledgable people on the subject might be Michael
> Gogins, Paul Barton-Davis, and Juhana Sadeharju. If they're reading,
> perhaps they have some commentary to add ?

Ooh..my subject acronymizes as OPS.  Kind of appropriate, no? :)

Whatever it's called, I think this topic deserves its own list!  The
potential impact of a successful spec is mind-boggling.  I'd
definitely like to see some draft specs and find out how convenient
they are to code to.  Given that this area is harder than it looks
(well, it looks harder the harder *I* look at it :), I suspect that a
winner will only emerge as various draft specs compete for mindshare.

Eric

From - Fri Aug  6 04:36:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA25822
	for <slinkp@ulster.net>; Thu, 5 Aug 1999 11:59:17 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA13911 for linux-audio-dev-list; Thu, 5 Aug 1999 11:18:03 -0400
Received: from cygnus.com (runyon.cygnus.com [205.180.230.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA13908 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 5 Aug 1999 11:17:59 -0400
Received: from cygnus.com (thudson1.cygnus.com [205.226.144.45])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id IAA29072;
	Thu, 5 Aug 1999 08:15:05 -0700 (PDT)
Message-ID: <37A9AA77.4986B9B9@cygnus.com>
Date: Thu, 05 Aug 1999 11:15:03 -0400
From: Thomas Hudson <thudson@cygnus.com>
Organization: Cygnus Solutions
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: est@hyperreal.org
CC: Dave Phillips <dlphilp@bright.net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] open plugin specification
References: <19990805144219.6938.qmail@hyperreal.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 09df182c1447ec29c5d28df313825d81

est@hyperreal.org wrote:
> 
> Dave Phillips discourseth:
> >
> > > Speaking of that, a "free" plugin specification (VST 1.0 like), but in
> > > "C"  would be great for all projects. We could use mix as a testfield.
> > > Do you know about something like that ?
> >
> > This has been a major topic on the Csound and music-dsp lists lately. I
> > think the most knowledgable people on the subject might be Michael
> > Gogins, Paul Barton-Davis, and Juhana Sadeharju. If they're reading,
> > perhaps they have some commentary to add ?
> 
> Ooh..my subject acronymizes as OPS.  Kind of appropriate, no? :)
> 
> Whatever it's called, I think this topic deserves its own list!  The
> potential impact of a successful spec is mind-boggling.  I'd
> definitely like to see some draft specs and find out how convenient
> they are to code to.  Given that this area is harder than it looks
> (well, it looks harder the harder *I* look at it :), I suspect that a
> winner will only emerge as various draft specs compete for mindshare.
> 
Actually, a somewhat related effort is the Portable Audio project started
by Ross Bencina. There are several volunteers working on various OS
ports. Seems like this spec could be expanded to include a plugin 
specification. 

A plugin spec that was completely cross-platform could bring much
more support to Linux. Ross asked me to set up a mailing list for
this. I should get to it by this weekend. I can post the specifics
when it is done if there is interest.

Thomas

From - Fri Aug  6 04:36:40 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA02611
	for <slinkp@ulster.net>; Thu, 5 Aug 1999 13:01:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA14127 for linux-audio-dev-list; Thu, 5 Aug 1999 12:15:36 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id MAA14123 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 5 Aug 1999 12:15:29 -0400
From: est@hyperreal.org
Received: (qmail 20189 invoked by uid 162); 5 Aug 1999 16:12:39 -0000
Message-ID: <19990805161239.20188.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] open plugin specification
In-Reply-To: <37A9AA77.4986B9B9@cygnus.com> from Thomas Hudson at "Aug 5, 1999
 11:15:03 am"
To: Thomas Hudson <thudson@cygnus.com>
Date: Thu, 5 Aug 1999 09:12:39 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 6ba08774ab61badccabc03d5ccfd7334

Thomas Hudson discourseth:
> 
> A plugin spec that was completely cross-platform could bring much
> more support to Linux.

Yes indeed.  I'm personally interested in something that's about C
and/or C++, not OS bindings.

> Ross asked me to set up a mailing list for
> this. I should get to it by this weekend. I can post the specifics
> when it is done if there is interest.

Oh, please do.  I think this list is interested by definition. :)

Eric

From - Fri Aug  6 04:36:42 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA22596
	for <slinkp@ulster.net>; Thu, 5 Aug 1999 15:20:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA14311 for linux-audio-dev-list; Thu, 5 Aug 1999 14:33:44 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA14308 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 5 Aug 1999 14:33:39 -0400
Received: from bright.net (find-cas1-cs-27.dial.bright.net [209.143.26.130])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id OAA25475;
	Thu, 5 Aug 1999 14:30:50 -0400 (EDT)
Message-ID: <37A9DCD4.117E74A6@bright.net>
Date: Thu, 05 Aug 1999 14:49:56 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Guenter Geiger <geiger@epy.co.at>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Mix and recording
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: a4d9cad5af2e168f85595610875ab8ec

Greetings:

  I tried recording, it doesn't appear to work. The docs aren't
enthusiastic about recording in Mix, but it seems another one of those
things we ought to have. What do you think ?

  I recorded both with and without the audio monitor. Both times the
program ceased accepting keyboard or mouse input. I will keep working on
this, but fixing the code is likely to be beyond me.

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Sat Aug  7 02:18:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA16636
	for <slinkp@ulster.net>; Fri, 6 Aug 1999 11:49:58 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA23924 for linux-audio-dev-list; Fri, 6 Aug 1999 11:10:52 -0400
Received: from cygnus.com (runyon.cygnus.com [205.180.230.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA23921 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 6 Aug 1999 11:10:48 -0400
Received: from cygnus.com (thudson1.cygnus.com [205.226.144.45])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id IAA11953;
	Fri, 6 Aug 1999 08:08:04 -0700 (PDT)
Message-ID: <37AA06FE.D1514633@cygnus.com>
Date: Thu, 05 Aug 1999 17:49:50 -0400
From: Thomas Hudson <thudson@cygnus.com>
Organization: Cygnus Solutions
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jarno Seppanen <jams@cs.tut.fi>
CC: est@hyperreal.org, Dave Phillips <dlphilp@bright.net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] open plugin specification
References: <19990805144219.6938.qmail@hyperreal.org> <ruv7ln9h22r.fsf@korppi.cs.tut.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2aa1ff38d2a61911a60d1edc03e43abf

Jarno Seppanen wrote:
>
>         You can call me a cynic, but I'm afraid that if such a list was put
> up, there would be a lot of enthusiasm for a few months (weeks) but then the
> list would die.  At least this has been my experience in the field of open
> source development so far, and I would love someone to prove me wrong!
>
Well, it is up to the instigator to push development. I think this effort
has managed to keep the scope narrow enough to not be overly ambitous. Many
projects fail because they 
 
>         Why not discuss here at linux-audio-dev?  This list has also been
> struggling occasionally, so why not fill the list with wonderful discussion
> about competing plug-in drafts and the emergence of a winning specification?

I think the main reason for not doing it here, is that the effort includes
people interested in implementing the standard for their chosen platform:
win32, MacOS, BeOS, etc.
> 
>         BTW, the Portable Audio interface, or portaudio, resides at
> http://www.audiomulch.com/portaudio, and AFAIK it's been really quiet on that
> front since February.

This is why Ross took me up on the offer to start a mailing list for this
purpose. He wants to re-energize the discussion. The previous home of the 
discussions was the music-dsp mailing list, where relevant topics are
often lost in a sea of random ASCII drivel.

Thomas

From - Fri Aug  6 04:36:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id CAA05343
	for <slinkp@ulster.net>; Fri, 6 Aug 1999 02:49:54 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id CAA23066 for linux-audio-dev-list; Fri, 6 Aug 1999 02:12:51 -0400
Received: from cs.tut.fi (varis.cs.tut.fi [130.230.4.2]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA23063 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 6 Aug 1999 02:12:48 -0400
Received: from korppi.cs.tut.fi (jams@korppi.cs.tut.fi [130.230.4.3])
	by cs.tut.fi (8.8.8/8.8.8) with ESMTP id JAA19478;
	Fri, 6 Aug 1999 09:10:26 +0300 (EET DST)
Received: (from jams@localhost)
          by korppi.cs.tut.fi (8.8.5/8.8.4)
	  id JAA17863; Fri, 6 Aug 1999 09:10:05 +0300 (EET DST)
To: est@hyperreal.org
Cc: Dave Phillips <dlphilp@bright.net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] open plugin specification
References: <19990805144219.6938.qmail@hyperreal.org>
From: jams@cs.tut.fi (Jarno Seppanen)
Reply-To: jams@cs.tut.fi (Jarno Seppanen)
X-Url: http://www.modeemi.cs.tut.fi/~jams/
Date: 06 Aug 1999 09:10:04 +0300
In-Reply-To: est@hyperreal.org's message of "Thu, 5 Aug 1999 07:42:18 -0700 (PDT)"
Message-ID: <ruv7ln9h22r.fsf@korppi.cs.tut.fi>
Lines: 23
X-Mailer: Gnus v5.4.66/Emacs 19.31
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 931b934dbf537b359f1bdddf0f0b7194

est@hyperreal.org writes:

> Whatever it's called, I think this topic deserves its own list!  The
> potential impact of a successful spec is mind-boggling.  I'd
> definitely like to see some draft specs and find out how convenient
> they are to code to.  Given that this area is harder than it looks
> (well, it looks harder the harder *I* look at it :), I suspect that a
> winner will only emerge as various draft specs compete for mindshare.

	You can call me a cynic, but I'm afraid that if such a list was put
up, there would be a lot of enthusiasm for a few months (weeks) but then the
list would die.  At least this has been my experience in the field of open
source development so far, and I would love someone to prove me wrong!

	Why not discuss here at linux-audio-dev?  This list has also been
struggling occasionally, so why not fill the list with wonderful discussion
about competing plug-in drafts and the emergence of a winning specification?

	BTW, the Portable Audio interface, or portaudio, resides at
http://www.audiomulch.com/portaudio, and AFAIK it's been really quiet on that
front since February.
-- 
-Jarno

From - Fri Aug  6 05:35:43 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id FAA11727
	for <slinkp@ulster.net>; Fri, 6 Aug 1999 05:39:35 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id EAA23393 for linux-audio-dev-list; Fri, 6 Aug 1999 04:45:04 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA23390 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 6 Aug 1999 04:45:01 -0400
Received: from ulster.net (port166.king.ulster.net [208.242.160.167])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id EAA10258
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 6 Aug 1999 04:54:15 -0400
Message-ID: <37AAA16A.C4D999CF@ulster.net>
Date: Fri, 06 Aug 1999 04:48:42 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Audio-oriented Linux distribution
References: <19990805124630.26690.qmail@hyperreal.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 693db1a398ba01fd37d838ded5c1441d

est@hyperreal.org wrote:
> 
> David Slomin discourseth:
> >
> > 4.  ~/.Xsession - Pop up a notepad-type app displaying preliminary
> >     instructions on how to use the default window manager / desktop
> >     environment.  It should also say how to launch the master help
> >     browser.  (These preliminary instructions are necessarily separate
> >     from the help browser itself because it covers things the are
> >     prerequisite to being able to use the help browser, like the
> >     peculiarities of the widget set and window manager.)
> 
> Actually, Redhat 6.0 (for example) defaults to booting into X and the
> Gnome help browser is right in front when it does.  So, I think your
> aims here could be met by improving, if needed, the Gnome help browser
> with tooltips, different content, etc.

Cool! They're a step ahead of me, then. (I'm using RH 5.2 and have yet
to try out Gnome or KDE.)

I agree, improving existing tools is probably better than starting over.
Who has that kind of time anyway?

I think the /etc/issue and /etc/motd things are still important if the
new user is unlucky enough to not have X work right out of the box,
which is not all that unlikely. (Happened to me when I first got
started!)

--PW

----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Fri Aug  6 05:46:23 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id FAA11817
	for <slinkp@ulster.net>; Fri, 6 Aug 1999 05:43:11 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id EAA23404 for linux-audio-dev-list; Fri, 6 Aug 1999 04:47:20 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA23401 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 6 Aug 1999 04:47:17 -0400
Received: from ulster.net (port166.king.ulster.net [208.242.160.167])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id EAA10366;
	Fri, 6 Aug 1999 04:56:31 -0400
Message-ID: <37AAA1F2.4AD1EE36@ulster.net>
Date: Fri, 06 Aug 1999 04:50:58 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: est@hyperreal.org
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: audio-oriented kernels
References: <19990805130224.1764.qmail@hyperreal.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: d3ebc54dfcb8e8c939987b88323ac51d

est@hyperreal.org wrote:
> 
> Paul Winkler discourseth:

> In addition to latency patches, I'm beginning to regard including a
> patch that accerlerates the timer interrupt to greater than the
> current 100hz as essential.  It provides a means of escaping from
> these monolithic applications that are clocked by the soundcard.
> 

My ignorance is showing again-- what's this all about?
What's an example of a monolithic app. clocked by the soundcard?

----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Sat Aug  7 02:18:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id FAA12150
	for <slinkp@ulster.net>; Fri, 6 Aug 1999 05:52:47 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA23455 for linux-audio-dev-list; Fri, 6 Aug 1999 05:10:07 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA23452 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 6 Aug 1999 05:10:04 -0400
Received: from ulster.net (port166.king.ulster.net [208.242.160.167])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id FAA11048;
	Fri, 6 Aug 1999 05:19:17 -0400
Message-ID: <37AAA749.44344CD3@ulster.net>
Date: Fri, 06 Aug 1999 05:13:45 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
CC: Dave Phillips <dlphilp@bright.net>
Subject: Re: [linux-audio-dev] Audio-oriented Linux distribution
References: <37A924AA.F35BD562@ulster.net> <37A9929A.C72A18F6@bright.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c964f5772b4b23c592e7a3fb332f46d2

Dave Phillips wrote:

> Now, a dilemma: I'm to provide a disc for the book, and it will include
> as many of the profiled items as I can get on it. When the publisher and
> I began planning the book he was enthusiastic about the possibility of
> including a Linux distro along with the apps. It appears that what
> you're talking about would be exactly what he had in mind. So I ask you:
> given that it actually came to be, what would you think of it being used
> as the accompamying disc ?

*I* think it would be cool, but my contributions to the world of linux
audio consist of random bits of documentation. How do those folks feel
who put their mental sweat into all the fun code I use?
 
> > Would the hypothetical audio-linux distribution be targeted to
> > experienced Linux users, or to newbies, or both? [snip]
> 
> Your questions are precisely the ones I've had to keep in mind while
> writing chapters. I've opted for a presentation which will hopefully
> suit both the new and the experienced users. A little tougher to do than
> I thought...

I think this difficulty -- the level of experience presumed by most
existing documentation -- continues to be an area that the linux
community battles with. People want linux to be widely adopted, but not
at the expense of dumbing down the system; and people who already know
their way around a gnu/linux/xfree86 system aren't that motivated to
write entry-level documentation since they've gotten used to the
expert-level docs.

I think plenty of people want to give linux a try, but are intimidated
by the perceived (and actual!) difficulty of getting started; and even
though progress is continually made on this front, there's still a lot
that can go wrong for a new user and people have limited patience. For
this reason you can still find plenty of disgruntled postings on
comp.os.linux.misc along the lines of, "I heard Linux was great, I tried
it, something didn't work right, I asked a question and nobody on the
newsgroups could help, I'm giving up and going back to Windows."

When I think how simple it is to put useful messages in /etc/motd and
/etc/issue, I'm amazed that the commercial distributions aren't already
doing it. 
True, people like linux to be wide open to user configuration, but
anyone who would be annoyed by these messages probably already knows
enough to know how to get rid of them!
I think part of the objective for any such entry-level documentation
should be to provide useful information that's a little more welcoming
in its tone (while telling you where to get the real deep stuff if
you're ready for it).

Well, that's probably enough of this tangent. It occurs to me that such
a documentation project would be useful to a whole class of linux users
who have no interest in music/audio; it could be a separate project
(perhaps affiliated with the LDP?), which, of course, the hypothetical
audio-dev distribution would be free to make use of, extend, etc...


----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Sat Aug  7 02:18:22 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id IAA21523
	for <slinkp@ulster.net>; Fri, 6 Aug 1999 08:17:04 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id HAA23619 for linux-audio-dev-list; Fri, 6 Aug 1999 07:40:12 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id HAA23616 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 6 Aug 1999 07:40:05 -0400
From: est@hyperreal.org
Received: (qmail 17582 invoked by uid 162); 6 Aug 1999 11:37:34 -0000
Message-ID: <19990806113734.17581.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] open plugin specification
In-Reply-To: <ruv7ln9h22r.fsf@korppi.cs.tut.fi> from Jarno Seppanen at "Aug 6,
 1999 09:10:04 am"
To: Jarno Seppanen <jams@cs.tut.fi>
Date: Fri, 6 Aug 1999 04:37:34 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c49144373a2ea3e868be8c00d2dc2c30

Jarno Seppanen discourseth:
> est@hyperreal.org writes:
> 
> > Whatever it's called, I think this topic deserves its own list!
[...]
> 
> 	Why not discuss here at linux-audio-dev?

Because it's not linux-specific, anymore than it's csound-specific.
Interested parties need to be able to participate without having to
wade through stuff that doesn't interest them.

Eric

From - Sat Aug  7 02:18:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA26152
	for <slinkp@ulster.net>; Fri, 6 Aug 1999 09:01:45 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA23693 for linux-audio-dev-list; Fri, 6 Aug 1999 08:22:08 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id IAA23690 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 6 Aug 1999 08:22:05 -0400
From: est@hyperreal.org
Received: (qmail 27736 invoked by uid 162); 6 Aug 1999 12:19:32 -0000
Message-ID: <19990806121932.27735.qmail@hyperreal.org>
Subject: [linux-audio-dev] audio app timing architectures
In-Reply-To: <37AAA1F2.4AD1EE36@ulster.net> from Paul Winkler at "Aug 6, 1999
 04:50:58 am"
To: Paul Winkler <slinkp@ulster.net>
Date: Fri, 6 Aug 1999 05:19:31 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 085734114d6270c5b899b16db0d8bbb2

Paul Winkler discourseth:
> est@hyperreal.org wrote:
> > 
> > Paul Winkler discourseth:
> 
> > In addition to latency patches, I'm beginning to regard including a
> > patch that accerlerates the timer interrupt to greater than the
> > current 100hz as essential.  It provides a means of escaping from
> > these monolithic applications that are clocked by the soundcard.
> > 
> 
> My ignorance is showing again-- what's this all about?
> What's an example of a monolithic app. clocked by the soundcard?

www.hyperreal.org/~est/oolaboola :) ..or wavplay for that matter.  How
do these apps know when to sleep?  They know by blocking in their
writes to the soundcard when the soundcard driver's buffers are full.
Having to do this leads to a pc-like i-must-seize-control-of-the-hardware 
style of coding.  That's what I mean by `monolithic' as compared to a 
unix-like device-independent style.

What's a real example of the latter?  Well, I'm adding quadrophonic
(actually more general multi-channel) output to oolaboola, and I want
people to be able to do it with a couple of cheap soundcards.  Now,
your excellent Audio-Quality HOWTO explains, I believe, why this won't
work; but I think I can make it work. :)

I'm planning on having separate processes, one for each soundcard,
that take their input from oola and output to their soundcard doing
resampling to deal with timing descrepancies.  (I've got a design in
mind for a general audio process architecture that does this sort of
thing via shared-memory and/or network connections.) But if I do that,
oola can't block on it's writes to these processes, it has to output
to them at a fixed rate of *its* choice, and it can do this by calling
nanosleep() at appropriate times.

However, currently, linux on x86 has a timer interrupt at 100 hz.
This is too coarse to allow the above strategy *and* have
low-latencies/high-responsiveness.  Something more like 1024 hz timer
interrupts would be more practical.  Switching to that is as easy as
changing the definition of HZ in the kernel, however, their are issues
with that.  Some user-space apps that assume HZ=100 would need to be
fixed and/or rebuilt.  Some of this could be handled by kernel patches
that have been floating around that would lie to these user-space
apps, but there's some disagreement about the right approach.  There
may also be some issues in ther kernel itself, and there are proposed
patches for some of these.

I hope this helps explain my concerns. :)

Eric

From - Sat Aug  7 02:18:30 1999
Received: from kaybee.org (IDENT:rob@kaybee.resnet.gatech.edu [128.61.15.250])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id JAA27545
	for <slinkp@ulster.net>; Fri, 6 Aug 1999 09:13:25 -0400
Received: from localhost (rob@localhost)
	by kaybee.org (8.8.7/8.8.7) with ESMTP id JAA16194;
	Fri, 6 Aug 1999 09:01:26 -0400
Date: Fri, 6 Aug 1999 09:01:26 -0400 (EDT)
From: rob <rob@kaybee.org>
To: est@hyperreal.org
cc: Paul Winkler <slinkp@ulster.net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] audio app timing architectures
In-Reply-To: <19990806121932.27735.qmail@hyperreal.org>
Message-ID: <Pine.LNX.4.10.9908060855110.16151-100000@kaybee.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0a2e8de84c567f922a993505589b808b

hi, 
	most x86 platforms have a real time clock in LSI, which can be set
to 1024Hz without affecting most other drivers.  adding the enhanced
support for /dev/rtc will give you access to it.
	i used this method of timing in a userland sequencer i was messing
with and had good success with it even under varying cpu. 
		
			rob

On Fri, 6 Aug 1999 est@hyperreal.org wrote:

> However, currently, linux on x86 has a timer interrupt at 100 hz.
> This is too coarse to allow the above strategy *and* have
> low-latencies/high-responsiveness.  Something more like 1024 hz timer
> interrupts would be more practical.  Switching to that is as easy as
> changing the definition of HZ in the kernel, however, their are issues
> with that.  Some user-space apps that assume HZ=100 would need to be


---
Rob Melby
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
Internet: rob@kaybee.org, gt4255a@prism.gatech.edu

From - Sat Aug  7 02:18:37 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA32061
	for <slinkp@ulster.net>; Fri, 6 Aug 1999 09:48:21 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA23788 for linux-audio-dev-list; Fri, 6 Aug 1999 09:10:09 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id JAA23785 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 6 Aug 1999 09:10:06 -0400
From: est@hyperreal.org
Received: (qmail 13148 invoked by uid 162); 6 Aug 1999 13:07:35 -0000
Message-ID: <19990806130735.13147.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] audio app timing architectures
In-Reply-To: <Pine.LNX.4.10.9908060855110.16151-100000@kaybee.org> from rob at
 "Aug 6, 1999 09:01:26 am"
To: rob <rob@kaybee.org>
Date: Fri, 6 Aug 1999 06:07:35 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2d4438e58b22d1424eff68190d68f258

rob discourseth:
> hi, 
> 	most x86 platforms have a real time clock in LSI, which can be set
> to 1024Hz without affecting most other drivers.  adding the enhanced
> support for /dev/rtc will give you access to it.

Indeed.  I even designed a nanosleep daemon (/tmp/rtcd :) that would
grab the rtc and serve `nanosleep requests' from multiple processes.
I wanted something like that, again, to get away from the monolithic,
my-app-seizes-the-hardware (in this case, /dev/rtc) approach.  Given
that this would work on current distributions, maybe I should go with
it, even though changing HZ in the kernel seems more The Right Thing
to me.

Eric

From - Sat Aug  7 14:29:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA15939
	for <slinkp@ulster.net>; Sat, 7 Aug 1999 12:13:26 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA25958 for linux-audio-dev-list; Sat, 7 Aug 1999 11:33:41 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA25955 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 7 Aug 1999 11:33:38 -0400
Received: from debian (dialup49-4-15.swipnet.se [130.244.49.207]) 
          by mb05.swip.net (8.8.8/8.8.8) with ESMTP 
          id RAA20395; 
          Sat, 7 Aug 1999 17:30:58 +0200 (MET DST)
Received: from debian.mbox314.swipnet.se (really [127.0.0.1]) by debian
	via in.smtpd with esmtp (ident root using rfc1413)
	id <m11D8Rk-0017r0C@debian> (Debian Smail3.2.0.101)
	for <geiger@epy.co.at>; Sat, 7 Aug 1999 17:31:44 +0200 (CEST) 
Message-Id: <m11D8Rk-0017r0C@debian>
Date: Sat, 7 Aug 1999 17:31:38 +0200 (CEST)
From: reine@mbox314.swipnet.se
Reply-To: reine@mbox314.swipnet.se
Subject: [linux-audio-dev] Mix, sndplay and  SNDCTL_DSP_SETFRAGMENT
To: geiger@epy.co.at
cc: linux-audio-dev@ginette.musique.umontreal.ca
In-Reply-To: <14248.20640.524816.779564@gige>
MIME-Version: 1.0
Content-Type: TEXT/plain; CHARSET=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: d41cea2e45651eaf83d9584f18565481


Testing mix with long clean nice sounds i noticed that
mix hade the same problem on my Thinkpad 560 (133mHz pentium) 
as my homebrewed "play" program. Odd almost "clicks,glitches..."
that I could not hear on the on no/laptop/133mHzpentium.
One program worked: the sndplay program from Bill Schottstaedt.

So I started to study his code and found out that if I
added something like

   static int FRAGMENTS = 4;
   static int FRAGMENT_SIZE = 12;
   if (!fragments_locked) {if (srate > 30000) FRAGMENTS = 4; else FRAGMENTS = 2;}
      buffer_info = (FRAGMENTS<<16) | (FRAGMENT_SIZE);

In fact I since my little play program is just for me and not need to
be as clever as Bills (thank You Bill) I shortened it to

   int svar=(4<<16)|(12);
   ioctl(sound,SNDCTL_DSP_SETFRAGMENT,&svar);

And now my little play program was much more stable.
I also made the same change in the mixw source in the
DPTich_linux_audio.c. I guess the same appplies for the new
mix.

  queuetwo = ((int) (log (bufferbytes) / log (2.0))) + 1;
//Out_with_tho_old_line: argument = 0x7fff0000 | (queuetwo & 0x0000ffff);
//In with the new:
	argument=(4<<16)|(12);
  if (ioctl (port->file,SNDCTL_DSP_SETFRAGMENT,&argument) == -1)

And the new is more stable than the old.
I'm not sure why. It did not sound as "normal ;)" underrun-clicks.

Reine




From - Sat Aug  7 14:29:34 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA25723
	for <slinkp@ulster.net>; Sat, 7 Aug 1999 13:57:19 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA26080 for linux-audio-dev-list; Sat, 7 Aug 1999 13:19:42 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA26077 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 7 Aug 1999 13:19:39 -0400
Received: from bright.net (find-cas1-cs-11.dial.bright.net [209.143.26.114])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id NAA17425;
	Sat, 7 Aug 1999 13:17:00 -0400 (EDT)
Message-ID: <37AC6E7C.EAC5FB84@bright.net>
Date: Sat, 07 Aug 1999 13:35:56 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: reine@mbox314.swipnet.se
CC: geiger@epy.co.at, linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Mix update
References: <m11D8Rk-0017r0C@debian>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 24e0185e8cf96fee1e533fb60a81aaae

Greetings:

  I added Reine's code to my copy here of Guenter's sources, everything
seems to work fine. Should it go in as a fixture ?

  A few more observations:

	1. The mixed file (track 10) is drawn rather poorly on my machine, with
no x axis visible. Reine, didn't you fix that once before ?

	2. The PAN button in track 10 reads PAR. Where can that be repaired ?

	3. WAV files load fine, but now AIFF files are unrecognized.

  Guenter, it appears that you've made some more features available for
customization via the resource file. Is it possible to set the screen
size that way ? I'm only asking because that seems to be a common
request from users. Looking through mix.c I cringe whenever I see fixed
values, I wonder whether they could be defined in Mix.ad instead, but I
don't know how much of that process would be practical. I'd certainly
like to leave as much customization as possible to the user's whim.

  The LessTif version seems to be somewhat critical too. I'm not sure
what version I'm using, though the Xm lib is libXm.so.1.2 _not_
libXm.so.1.0.2 (which will cause the flashing radio buttons and segfault
in the file browser box).

  Still no word from Dr. Hammer.

  Okay, it's looking better all the time. I'll start in on the docs this
week. I have to get a new soundapps page up yet this weekend. Lots of
new things...

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Mon Aug  9 13:39:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA15213
	for <slinkp@ulster.net>; Mon, 9 Aug 1999 12:04:57 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA29003 for linux-audio-dev-list; Mon, 9 Aug 1999 11:18:46 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA28999 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 9 Aug 1999 11:18:33 -0400
Received: from bright.net (find-cas2-cs-5.dial.bright.net [209.143.26.159])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id LAA20996;
	Mon, 9 Aug 1999 11:15:59 -0400 (EDT)
Message-ID: <37AEF518.5A8E4532@bright.net>
Date: Mon, 09 Aug 1999 11:34:48 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Linux Audio/Music CD: Where things stand now...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8003
X-Mozilla-Status2: 00000000
X-UIDL: c4dd9c10220c70aba39ba856ec753548

Greetings:

  WRT a Linux audio distro, a friend wrote to say that he felt it was
quite premature to plan such a beast, when so few Linux audio
applications are truly "ready to rock". So I decided to list what is
stable and usable on my machine. Here's a partial list of what I've come
up with:

	Csound
	RTCmix
	Cecilia
	jMax
	DAP
	Snd
	MiXViews
	Jazz++
	Ceres
	Mix
	Silence
	HPKComposer
	Common LISP Music
	terminatorX
	Green Box
	Freebirth
	gSynth
	Xsynth
	KeyKit
	kooBase
	xphat
	SoftWerk
	RTSynth
	SoundTracker
	BladeEnc
	GRip	
	playmidi
	TiMidity
	aRts
	Quasimodo
	KWave
	Oolaboola

and actually a bunch of other small progs. So what would you add
to/delete from that list ? Are we shy of our projected distribution ?

Btw, we could also add numerous tools as well as items such as ALSA, the
latest OSS/Free, and perhaps a trial version of OSS/Linux.

As always, just my two drachmas. Commentary and suggestions welcome...

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Mon Aug  9 13:39:57 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA23960
	for <slinkp@ulster.net>; Mon, 9 Aug 1999 13:10:30 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA29111 for linux-audio-dev-list; Mon, 9 Aug 1999 12:24:24 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id MAA29108 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 9 Aug 1999 12:24:21 -0400
From: est@hyperreal.org
Received: (qmail 4279 invoked by uid 162); 9 Aug 1999 16:21:32 -0000
Message-ID: <19990809162132.4278.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] Linux Audio/Music CD: Where things stand now...
In-Reply-To: <37AEF518.5A8E4532@bright.net> from Dave Phillips at "Aug 9, 1999
 11:34:48 am"
To: Dave Phillips <dlphilp@bright.net>
Date: Mon, 9 Aug 1999 09:21:32 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 48e469e0d8c85e89684d3f0f18ae7d5a

Dave Phillips discourseth:
> 
>   WRT a Linux audio distro, a friend wrote to say that he felt it was
> quite premature to plan such a beast, when so few Linux audio
> applications are truly "ready to rock". So I decided to list what is
> stable and usable on my machine. Here's a partial list of what I've come
> up with:
> 
[...]
> 	Oolaboola

Woowoo!  In self-promotional news, oola is opensound.com's killer app
of the month!

> and actually a bunch of other small progs. So what would you add
> to/delete from that list ? Are we shy of our projected distribution ?

I notice that you list cdj on your page as a program you haven't
tried (or haven't been able to try).  It works for me. :)

Now `stable and usable' may not be entirely the same thing as `ready
to rock'.  For example, the last kooBase I checked couldn't record
midi input, your friend might consider something like that `unready'.
(Please note that I *do* appreciate the kooBase effort; to criticize
is easy, to create is hard.)  Similarly, oolaboola can't yet handle
mp3 (it's coming on the equinox :)

Actually, I must admit that I find a stock linux kernel unready for
real-time use.  Patches are in the works, but it may be a long time
before they are in the standard kernel.

So, I'd say that a CD of current material would be like a snapshot of
the slingshot of linux multimedia being drawn back..the release is yet
to come.

That's my couple of denarii, :)

Eric

From - Tue Aug 10 22:04:48 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id EAA26176
	for <slinkp@ulster.net>; Tue, 10 Aug 1999 04:05:06 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id DAA00062 for linux-audio-dev-list; Tue, 10 Aug 1999 03:11:31 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA00059 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 10 Aug 1999 03:11:28 -0400
Received: from ulster.net (port134.king.ulster.net [208.242.160.135])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id DAA24372;
	Tue, 10 Aug 1999 03:21:16 -0400
Message-ID: <37AFD186.7FDECBFD@ulster.net>
Date: Tue, 10 Aug 1999 03:15:18 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Dave Phillips <dlphilp@bright.net>
CC: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Linux Audio/Music CD: Where things stand now...
References: <37AEF518.5A8E4532@bright.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 86f1ec17586f06c2d805a1539e66ca8a

Dave Phillips wrote:
>   WRT a Linux audio distro, a friend wrote to say that he felt it was
> quite premature to plan such a beast, when so few Linux audio
> applications are truly "ready to rock". So I decided to list what is
> stable and usable on my machine. Here's a partial list of what I've come
> up with:
(snip)
>         Silence
(snip)

I was just looking at M. Gogins' license for Silence at:
http://www.pipeline.com/~gogins/Silence/Silence.htm#License
NOtice that he uses the GPL but then adds a $100 download fee for any
"non-personal" useage. Unusual. Would this be a problem? I can't really
figure it out. Might be a good idea to write to him before including
Silence in anything.

> and actually a bunch of other small progs.

Most notably SoX. Love it or loathe it, it's hard to avoid using SoX!

> So what would you add
> to/delete from that list ? Are we shy of our projected distribution ?

Hmm. Personally I think it's still a _bit_ early; I'd like to see nearly
everything on that list developed a bit further before making a distro
out of it. In particular I'd like so see one of the truly-free sequencer
projects (not Jazz++) get to a stage of real production useability:
working midi input and output, etc. Anyone know when the much-fabled
Rosegarden 3.0 might arise? 2.1 looked promising but didn't seem to work
very well ... And what's up with Cantor? No new version in  a long
time...

I was just at a friends' house playing with 303seq on a windoze box.
Very fun little proggy. Sort of like SoftWerk only not. Would be a cool
thing to clone and/or make obsolete!
 
--PW

From - Tue Aug 10 22:04:50 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA32322
	for <slinkp@ulster.net>; Tue, 10 Aug 1999 06:33:30 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA00391 for linux-audio-dev-list; Tue, 10 Aug 1999 05:24:18 -0400
Received: from gate.fzi.de (gate.fzi.de [141.21.4.3]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id FAA00388 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 10 Aug 1999 05:24:14 -0400
Received: from prost1.fzi.de by gate.fzi.de with SMTP (PP);
          Tue, 10 Aug 1999 11:21:30 +0200
Received: from fzi.de (actually mahagoni) by prost1.fzi.de with SMTP (PP);
          Tue, 10 Aug 1999 11:21:15 +0200
Message-ID: <37AFEF08.53048DE1@fzi.de>
Date: Tue, 10 Aug 1999 11:21:12 +0200
From: Stefan Nitschke <nitschke@fzi.de>
Organization: Forschungszentrum Informatik (FZI), Karlsruhe, Germany
X-Mailer: Mozilla 4.02 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Linux Audio/Music CD: Where things stand now...
References: <37AEF518.5A8E4532@bright.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2f2ff0535d865bb09c62f3b8d51bb68a

> ...
> Actually, I must admit that I find a stock linux kernel unready for
> real-time use.  Patches are in the works, but it may be a long time
> before they are in the standard kernel.

Just, a question:
I read several mails about linux and real-time audio. Things about
drop outs, bad latancy, ....

I wonder a little bit about ... RTSynth e.g. runs just fine on my linux 2.2.x
system without any dropouts and a very fast response. It uses a fragment size
of 256/512 bytes (mono/stereo). On linux 2.0.x I tried out a fragment size down
to 64 bytes without any problems.
I use a patched MAD/Mozart kernel-OSS-driver and a MiroPCM12-PnP sound card.

- Stefan




From - Tue Aug 10 22:04:53 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA12607
	for <slinkp@ulster.net>; Tue, 10 Aug 1999 09:12:15 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA00629 for linux-audio-dev-list; Tue, 10 Aug 1999 08:15:54 -0400
Received: from sculpcave.localdomain (cvx-1-185.dyn.nic.fi [62.236.97.185]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA00625 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 10 Aug 1999 08:15:50 -0400
Received: (from root@localhost)
	by sculpcave.localdomain (8.8.7/8.8.7) id MAA01458;
	Tue, 10 Aug 1999 12:54:42 +0300
Date: Tue, 10 Aug 1999 12:54:40 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
To: Juhana Sadeharju <kouhia@nic.funet.fi>
cc: linux-audio-dev@ginette.musique.umontreal.ca,
        csound-unix-dev@ilogic.com.au
Subject: Re: [CUD] Re: [linux-audio-dev] What do we need now ?
In-Reply-To: <19990802120739Z42810-2248+2529@nic.funet.fi>
Message-ID: <%r8tq3gFBE@sculpcave>
X-User-Agent: Mana 4.0beta (Linux)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 31169b47f5e47510884d9e57b6ca5afc

On Mon, 2 Aug 1999, Juhana Sadeharju wrote:

>> It seems that many
>> ambitious audio projects have died because unrealistic goals.
> Absolutely not true! Just take a look at commercial software, they
> have not died.

That isn't a very good argument. You really can't compare commercial
software development with open-source projects. A commercial software
project with unrealistic goals will result in a bad product. In
open-source environment, these kinds of projects just die away.

> IMHO, many projects have died because people have not realized that
> we should organize the project just like they do in Real Work.

This is a different subject. I was talking about unrealistic 
goals, you're talking about organizing. And I don't have anything 
agains organizing projects. In fact, this open plugin specification
project would be a good place to start.

Also one thing that could help many open-source projects is that 
they'd offer something usable from early on. A project with a fancy
web site, big plans, etc but nothing concrete doesn't attract 
new developers and beta-testers.

Btw; One odd thing about linux audio is that so many apps are released
     without sources. Slab, Taon, Multitrack, Bcast, Jazz, etc, etc...
     I don't want blame the authors as these are all really good
     software and I'm glad that they're freely available. I just wish
     that projects like Roxen and Qt would encourage more people 
     to use open-source. These projects have proved that open-source 
     can be used in combination with commercial sw development.

-- 
Kai Vehmanen ----------------------------- CS, University of Turku, Finland
 : email                                 mailto:kaiv@wakkanet.fi
 : audio processing for linux            http://www.wakkanet.fi/ecasound/
 : my music (ambient-idm-rock-...mp3/ra) http://www.wakkanet.fi/sculpscape/

From - Tue Aug 10 22:04:55 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA16705
	for <slinkp@ulster.net>; Tue, 10 Aug 1999 09:43:01 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA00712 for linux-audio-dev-list; Tue, 10 Aug 1999 09:02:04 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id JAA00709 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 10 Aug 1999 09:02:01 -0400
From: est@hyperreal.org
Received: (qmail 6365 invoked by uid 162); 10 Aug 1999 12:59:26 -0000
Message-ID: <19990810125926.6364.qmail@hyperreal.org>
Subject: [linux-audio-dev] can't get any dropouts?
In-Reply-To: <37AFEF08.53048DE1@fzi.de> from Stefan Nitschke at "Aug 10, 1999
 11:21:12 am"
To: Stefan Nitschke <nitschke@fzi.de>
Date: Tue, 10 Aug 1999 05:59:26 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 636f7bb4731b40189421a3a2f77a8205

Stefan Nitschke discourseth:
> 
> Just, a question:
> I read several mails about linux and real-time audio. Things about
> drop outs, bad latancy, ....
> 
> I wonder a little bit about ... RTSynth e.g. runs just fine on my linux 2.2.x
> system without any dropouts and a very fast response. It uses a fragment size
> of 256/512 bytes (mono/stereo). On linux 2.0.x I tried out a fragment size down
> to 64 bytes without any problems.
> I use a patched MAD/Mozart kernel-OSS-driver and a MiroPCM12-PnP sound card.

Stefan,

Please try latencytest (http://www.gardena.net/benno/linux/audio/).

Possible reasons for your RTSynth results: 

* You give fragment sizes but not the number of fragments..the product
  of those is the total audio buffer size.

* RTSynth probably doesn't have a lot of disk activity.

* It may also not use much of your processor leaving a lot of slack in
  which to catch up.

If you want to generate dropouts in RTSynth, try running top at the
same time.  You'll also find out RTSynth's processor load. :)  You can
also try creating a 200M file (head -c 200000000 /dev/zero >tmpfile)
while RTSynth is running.  Deleting the file is probably even more
likely to cause dropouts.

Best,

Eric

From - Tue Aug 10 22:05:01 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA19855
	for <slinkp@ulster.net>; Tue, 10 Aug 1999 10:08:14 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA00772 for linux-audio-dev-list; Tue, 10 Aug 1999 09:19:11 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA00769 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 10 Aug 1999 09:19:08 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46886AbPHJNQW>; Tue, 10 Aug 1999 16:16:22 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <37AEF518.5A8E4532@bright.net> (message from Dave Phillips on
	Mon, 09 Aug 1999 11:34:48 -0400)
Subject: Re: [linux-audio-dev] Linux Audio/Music CD: Where things stand now...
Message-Id: <19990810131624Z46886-550+388@nic.funet.fi>
Date:   Tue, 10 Aug 1999 16:16:22 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1673882f459a8ea27ab0bcb7298f41c1

>From:   Dave Phillips <dlphilp@bright.net>
>
>	BladeEnc

Impressive list. Having such a distribution surely helps us to find out
what still is missing and what is needed so that existing programs would
co-work seamlessly. Or, for example, do we already have audio or MIDI
copy/paste in GNOME? Sync between different programs? Esound allows already
run of the multiple applications but perhaps the sync is not there yet.

Ok, I just wanted to say that LAME mpeg encoder seems to be superious
to BladeEnc. If BladeEnc has moved to use LAME's encoding code, then
I have got wrong info.

Yours,

Juhana

From - Tue Aug 10 22:04:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA17085
	for <slinkp@ulster.net>; Tue, 10 Aug 1999 09:45:47 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA00717 for linux-audio-dev-list; Tue, 10 Aug 1999 09:02:33 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA00714 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 10 Aug 1999 09:02:31 -0400
Received: from bright.net (find-cas1-cs-31.dial.bright.net [209.143.26.134])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id IAA19510;
	Tue, 10 Aug 1999 08:59:52 -0400 (EDT)
Message-ID: <37B026AD.8EA6D8A1@bright.net>
Date: Tue, 10 Aug 1999 09:18:37 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Kai Vehmanen <kaiv@wakkanet.fi>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [CUD] Re: [linux-audio-dev] What do we need now ?
References: <%r8tq3gFBE@sculpcave>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 61feb850ebf17db813e2e7f456e6799c

Kai Vehmanen wrote:

> Btw; One odd thing about linux audio is that so many apps are released
>      without sources. Slab, Taon, Multitrack, Bcast, Jazz, etc, etc...
>      I don't want blame the authors as these are all really good
>      software and I'm glad that they're freely available. I just wish
>      that projects like Roxen and Qt would encourage more people
>      to use open-source. These projects have proved that open-source
>      can be used in combination with commercial sw development.

Just so you know: Jazz (not Jazz++) is indeed available as source code,
which I find most interesting. The sources for an entire MIDI sequencer
are publicly available, yet I wonder how many have used that codebase as
a starting point. According to Boris Nagels, Multitrack will soon be
available as source code covered by the GPL. Broadcast 2.1 is available
as source code (I have it right here), but Broadcast 2000 isn't (in
fact, it isn't available at all). Adam Williams has indicated that if he
could pay off the loans he took out to create Broadcast 2000 then he
would likely release it under the GPL; as it stands, the bank owns his
source code. TAON's authors seem a bit confused about what the GPL could
do for them: their Web page states "In case we really want to release
TAON in a commercial manner...in the future, we would not be happy to
find our source and product patented somewhere in Taiwan or
something...", which I believe wouldn't be a problem for them if they
GPL'd their sources. I may be wrong about that. I'm not sure what Nick
Copeland eventually intends for Slab.

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Tue Aug 10 22:05:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA19198
	for <slinkp@ulster.net>; Tue, 10 Aug 1999 10:03:15 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA00793 for linux-audio-dev-list; Tue, 10 Aug 1999 09:26:48 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA00789 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 10 Aug 1999 09:26:45 -0400
Received: from bright.net (find-cas1-cs-31.dial.bright.net [209.143.26.134])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id JAA23086;
	Tue, 10 Aug 1999 09:24:08 -0400 (EDT)
Message-ID: <37B02C5D.AEF4C9F@bright.net>
Date: Tue, 10 Aug 1999 09:42:53 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Bill Schottstaedt <bil@ccrma.Stanford.EDU>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Linux Audio/Music CD: Where things stand now...
References: <37AEF518.5A8E4532@bright.net> <199908101251.FAA27519@cmn14.stanford.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4d8c5e3e09bf86d06d7dbb125a79d460

Bill Schottstaedt wrote:
 
> It might be nice to include music notation programs on
> your CD:  CMN (ccrma-ftp.stanford.edu:pub/Lisp/cmn.tar.gz)
> and (if it's ok with the author) LilyPond (ftp://ftp.gnu.org/pub/lilypond/,
> Han-Wen Nienhuys, hanwen@cs.uu.nl) come to mind.

Whoops, I forgot to put them on the list.

I also forgot to mention that the list was not intended to indicate what
would go on the CD, only to show what I personally have working here at
home. I received a good message from another Linux audio friend who
stated that he didn't think there were enough working programs to
constitute a full CD, so I responded with the list. There's been some
confusion about that. ;)

I compiled the latest Snd, everything works again except for the
Listener. As before, I can type in a line, but when I hit the Enter key
the cursor just sits there at the end of the line. I think I asked you
before, but: am I supposed to have LISP somewhere on my system for
Listener to work ? You have suggested it's a problem with LessTif, and
it could be, but I have no problems elsewheres with text entry in apps
built with it. Btw, my LessTif is libXm.so.1.2.

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Tue Aug 10 22:05:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA23077
	for <slinkp@ulster.net>; Tue, 10 Aug 1999 10:34:22 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA00874 for linux-audio-dev-list; Tue, 10 Aug 1999 09:49:40 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA00871 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 10 Aug 1999 09:49:38 -0400
Received: from bright.net (find-cas1-cs-31.dial.bright.net [209.143.26.134])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id JAA23127;
	Tue, 10 Aug 1999 09:45:36 -0400 (EDT)
Message-ID: <37B03166.9045A352@bright.net>
Date: Tue, 10 Aug 1999 10:04:22 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Gogins <gogins@nyc.pipeline.com>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Re: compiling Linux Csound (official)
References: <003301bee320$109f8160$79d496c0@Realizer.ngt.sungard.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 1875f65ced93c901f788f6a9b34d51b0

Greetings, Michael:

  Thank you for your interest in this matter. My idea was to simply
carve the existing code into smaller pieces and add a command-line flag
to indicate inclusion (something like -DLINUX_MIDI) with the build.
However, I see your point in the need for an eventual redesign of
Csound, though I'm not at all convinced it will happen any time soon.
There seems to be some invisible weight attached to "things as they
are".

> As I've said before, if this redesign is not done and done well, then Csound
> will be replaced as a de facto serious software synthesis standard by
> something else, such as an efficient implementation of SAOL, or a
> cross-platform SuperCollider, or something like Reaktor, or something not
> yet imagined. If it is done and done well, then the weight of all the great,
> working instrument definitions, scores, and orchestras will keep Csound
> alive and a contender for years if not decades to come.

Considering the enormous work required to create something which would
be as much as and more than Csound, I doubt we'll see anything replacing
it Real Soon Now, at least nothing with open sources and freely
available (amazing what money can achieve, no ?). SAOL is progressing at
a snail's pace: it may indeed be the Csound of the future, but I
probably won't be around to use it. A cross-platform Super Collider
would be nice, and apparently its author is leaning towards a Linux
implementation. But will it accomodate existing Csound orc/sco files and
its numerous amenities and support softwares ? That would create another
great burden for the porter.
 
> In other words, the real value in Csound is what has been written in the
> Csound languages, not the C code that implements those languages.

I agree, but I also think Csound is something of an unsearched treasure
chest for DSP code and other interesting sources. So, in point of fact,
I think it does indeed have great intrinsic value.
 
> I've followed Quasimodo, but I'm Windows based while it is Linux based, and
> I haven't yet and may never take the time to see if I could adapt it as a
> newer cross-platform implementation of the Csound languages.

Q has the immediate distinction of compatibility with existing Csound
opcodes and orc/sco files. I don't know of any other software doing
that, and Paul may indeed supply the engine to realize what you've
suggested. I have no idea what it would require for Q to be implemented
in Windows, though I can't imagine it would be any trivial effort.

Abstracting the synthesis/DSP engines from the interface seems to be a
hot topic and practice these days (Quasimodo and aRts come to mind), as
your own excellent posts have indicated. But I agree with you that the
eventually accepted engines will have to make serious efforts to ensure
compatibility with the existing Csound codebase. At this time I have no
idea how that could be accomplished to the satisfaction of every one and
their chosen platform.

Well, we live in exciting times, yes ?

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Tue Aug 10 22:05:06 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA23080
	for <slinkp@ulster.net>; Tue, 10 Aug 1999 10:34:23 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA00887 for linux-audio-dev-list; Tue, 10 Aug 1999 09:53:57 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA00884 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 10 Aug 1999 09:53:55 -0400
Received: from bright.net (find-cas1-cs-31.dial.bright.net [209.143.26.134])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id JAA01084;
	Tue, 10 Aug 1999 09:51:18 -0400 (EDT)
Message-ID: <37B032BB.2EEE5BFA@bright.net>
Date: Tue, 10 Aug 1999 10:10:03 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Richard Dobson <rwd@cableinet.co.uk>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Re: compiling Linux Csound (official)
References: <003301bee320$109f8160$79d496c0@Realizer.ngt.sungard.com> <37B02CC3.B36D8C7F@cableinet.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 371d7e6335fb4378bc27599b30963a0f

Richard Dobson wrote:

> I see two likely scenarios:
> 
> (1) Michael and or others with just go ahead and make changes, which may
> all have great virtues, but there will then be a heated semi-political
> debate over email about what the changes should be, what goes into the
> canonical version, and who takes most responsibility for maintaining it;

Which is the situation we have now.
 
> (2) it is time we have a full International Csound Conference, perhaps
> as part of ICMC 2000 (if it's in Europe, I have a batting chance of
> attending it!), where everyone concerned with this issue can meet round
> a table, complete with modern presentation tools, and a consensus can be
> arrived at once and for all.

I'll see you there ! ;)

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Tue Aug 10 22:05:07 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA29406
	for <slinkp@ulster.net>; Tue, 10 Aug 1999 11:18:25 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA00959 for linux-audio-dev-list; Tue, 10 Aug 1999 10:39:01 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA00956 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 10 Aug 1999 10:38:59 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46871AbPHJOgG>; Tue, 10 Aug 1999 17:36:06 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca,
        csound-unix-dev@ilogic.com.au
In-reply-to: <%r8tq3gFBE@sculpcave> (message from Kai Vehmanen on Tue, 10 Aug
	1999 12:54:40 +0300 (EEST))
Subject: Re: [CUD] Re: [linux-audio-dev] What do we need now ?
Message-Id: <19990810143611Z46871-548+451@nic.funet.fi>
Date:   Tue, 10 Aug 1999 17:36:06 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0586c0c1a4bbe51bd9a3f65b5b0a069f

>From:   Kai Vehmanen <kaiv@wakkanet.fi>
>
>Also one thing that could help many open-source projects is that 
>they'd offer something usable from early on. A project with a fancy
>web site, big plans, etc but nothing concrete doesn't attract 
>new developers and beta-testers.

Well, with the GASP I want to test if there are real interest in
to non-"tell me when you have something which compiles" project
organization.

The concrete there is the material which may give ideas to readers.
Submitting those ideas to me will be one of the GASP request.

Of course, when I progress with the GASP and put more material there,
those will tease further ideas out the same way as an incomplete code
teases programmers to code further. Plain simple!

Yours,

Juhana

From - Tue Aug 10 22:05:14 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA06369
	for <slinkp@ulster.net>; Tue, 10 Aug 1999 12:22:31 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA01099 for linux-audio-dev-list; Tue, 10 Aug 1999 11:33:15 -0400
Received: from mustec.bgsu.edu (mustec.bgsu.edu [129.1.57.200]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA01096 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 10 Aug 1999 11:33:12 -0400
Received: from mustec.bgsu.edu (azygmun@mustec.bgsu.edu [129.1.57.200])
	by mustec.bgsu.edu (8.8.7/8.8.7) with ESMTP id LAA00952
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 10 Aug 1999 11:30:47 -0400
Date: Tue, 10 Aug 1999 11:30:47 -0400 (EDT)
From: Adam Zygmunt <azygmun@bgnet.bgsu.edu>
X-Sender: azygmun@mustec.bgsu.edu
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] My 2 cents
Message-ID: <Pine.LNX.4.10.9908101010590.922-100000@mustec.bgsu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: aa22f3590ae3024dea69375936dfe1c0


I've been following this discussion for quite a while, and I have tried to
at least install a good deal of the software that's come along, and before
I continue, forgive me if I step on some toes. My main suggestion is this:
before we start talking distributions, plug-in architectures, how much
stuff we can do at once on our machines, we need to focus on one thing:
working, useful, compilable applications. I hate to say this, as I'm one
of the biggest Linux advocates I know (having made a few converts,
actually), but when I want to play, I use Linux, and when I want to get
real work done, I use Windows (or even, heaven forbid, a Mac). This
message is going to be extremely long, but please hear me out.

I think there is some excellent music software for Linux. For example,
grip w/LAME is as good as anything out there. XCDRoast is good (though DAO
would be nice). The little stuff like mixers, players (kmedia and
x11amp/xmms spring to mind), timidity, SoftOSS, CD player w/CDDB, etc.
satisfy me. The rest, well...

A lot of the other programs have, in my opinion, critical problems that
prevent them from being actually useful. Most of the editors out there
don't have the fatal flaw that they don't have plugins. They have the
fatal flaw that they choke on large soundfiles on a reasonable system (say
5 min. of CD-quality audio on an 80M P300). The only one I've found so far
that hasn't used so much swap the system becomes unusable (or crashes
outright) is TAON, and it's not GPL.

So here's what I would suggest if it were all up to me (a grand
statement!)

Editors: At a minimum, it should handle large files. All the Windows
editors I've seen except the Windows Sound Recorder can. Trying to load
the entire sound file into memory at once is clearly a bad idea, and makes
working with multiple files simultaneously (a la Cool Edit Pro or any
other multitrack editor) prohibitive. To raise the bar a little, I would
add nonlinear editing. Add proper crossfading at edit points, and you've
got one up on Cool Edit or anything else that just uses .wav file cue
points for this. Then I might start to worry about plugins, after there's
a debugged, responsive editor that can do at least this. Multitrack
editing and realtime effects would come last, or be more likely handled by
a decent audio sequencer. Check out the latest version of Vision DSP to
see how this is supposed to work.

Sequencers: Working MIDI in and out. No offense to kooBase, which at
present is very promising and well-appreciated. Good, responsive,
intuitive editing (where kooBase is the best yet). I actually hate most
sequencers with a passion for various reasons. The interfaces are usually
overly cumbersome and the editing that actually deals with the MIDI
information itself is underpowered and buried under layers of virtual
faders, windows, and bells and whistles (Logic Audio being the prime
offender and IMHO not one to emulate). What I would suggest would be that
cutting, pasting, and copying MIDI events be as easy as possible. Ditto
for adding/editing velocity, duration, and custom continuous controllers,
as these are what makes a sequence lively and what separates the good work
from the mediocre. I have actually been quite impressed with Mark of the
Unicorn's Freestyle, which isn't targeted as a high-end sequencer, but
which has editing capability that puts many of them to shame. The ability
to overlay recordings of just continuous controllers to a pre-existing
track is also a nifty and unique feature of Jazz++ that would be good to
keep.
     Adding digital audio would be the logical second step. I'd suggest
minimum destructive editing capability, but with the ability to set cue
points and volume/pan envelopes (maybe like the Cool Edit Pro multitrack
view, but included in a sequencer instead. Double-clicking the wave would
load it into the aforementioned Ideal Editor, no CORBA needed). Maybe
finally real-time effects, controlled similarly as with real MIDI
controller events and edited with the already well-designed continuous
controlled edit mechanism.

Notation: Forget about it. It's such a complex art that to really do it
justice requires a truly rare breed of programmer. Maybe if an expert in
typesetting, a composer or two, and a Ted Ross fanatic got together, it
could happen. As of right now, all of the Unix notation programs I've seen
combine the complexity of Score with the look of Pro Composer. Ugh. How
many actual musicians are going to learn TeX to write a simple score?
    One workable place I can think of to start, though, it to try and read
Score export files. For those not familiar with Score's workings, they
avoid the abstractions that get in the way of so many well-intentioned
text-based attempts. Every object is described by what it is, where it is,
and what its object-specific attributes are, all encoded numerically
(quite a bit like Csound, actually). Very simple. What Score does is offer
some help in filling in default values for positions and attributes, as
well as interactive group numerical editing of objects. The flexibily of
Score comes not from the inclusiveness of its entry system, but rather
that it allows easy access to a well-designed low-level of object
description.

Realtime synths/processors: Csound is making progress in this direction,
as are a number of other packages. RTSynth and jMax have worked the best
for me (two of the few I've gotten to compile actually). For now, there
are realtime issues, but these programs (especially jMax) have
demonstrated that they're not insurmountable. So what if you can't max out
your disk access, compile the kernel, and play Doom at the same time? Can
you expect to do this on ANYTHING right now? Multitasking or not,
resources are limited, and something has to give. Aren't you too busy
playing your synth anyway? If I were to expect it to do anything else, I
would want a disk output (Csound doesn't seem to have a problem with
this) and/or a driver synth device interface (you would of course lose
some interactivity here. See Yamaha's SoftXG or any of the Seer stuff for
examples.)


To be continued...

Adam Zygmunt
azygmun@bgnet.bgsu.edu

From - Tue Aug 10 22:05:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA10713
	for <slinkp@ulster.net>; Tue, 10 Aug 1999 12:53:28 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA01057 for linux-audio-dev-list; Tue, 10 Aug 1999 11:20:50 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA01054 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 10 Aug 1999 11:20:48 -0400
Received: from bright.net (find-cas1-cs-31.dial.bright.net [209.143.26.134])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id LAA03183;
	Tue, 10 Aug 1999 11:18:07 -0400 (EDT)
Message-ID: <37B04715.1CD367E1@bright.net>
Date: Tue, 10 Aug 1999 11:36:53 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Juhana Sadeharju <kouhia@nic.funet.fi>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Linux Audio/Music CD: Where things stand now...
References: <19990810131624Z46886-550+388@nic.funet.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: eb7ff693de0da6dd3e916b3f160c8bda

Juhana Sadeharju wrote:

> Impressive list. Having such a distribution surely helps us to find out
> what still is missing and what is needed so that existing programs would
> co-work seamlessly. Or, for example, do we already have audio or MIDI
> copy/paste in GNOME? Sync between different programs? Esound allows already
> run of the multiple applications but perhaps the sync is not there yet.

A few more words about that list:

  1. It wasn't meant to indicate what I thought should go on the disc,
only to show what I actually have running here. No, not everything
listed works absolutely perfectly (like everything on Windows does...),
but everything there works well for my applications. I had received mail
concerning the actual number of usable programs, so I wrote the list.

  2. Yes, it does show where we're short. IMO, Linux excels at the more
experimental types of audio and music apps, and it falls short in the
domains of MIDI sequencing, wave editing, and software more oriented
towards making music in popular styles

  3. Bill Schottstaedt pointed out that it lacked notation progs, so he
would add CMN (Common Music Notation) and LilyPond to the list.

  4. There are dozens of smaller, excellent applications not on the
list. For instance, I've been using Mike Oliphant's GRip, a nice
front-end for cdparanoia (a ripper), BladeEnc, (an MP3 encoder), and
Mike's own GCD (a CD player). GRip utilizes the cddb, an on-line
database of CD titles and their contents, very handy when grabbing
tracks. Then there's Maurizio Puxeddu's PitchTracker suite, a neat new
GUI for Oyvind Hammer's PTPS code, which Maurizio revisedand updated
using the FFTW library. Kai Vehmanen's powerful ecasound is now equipped
with a Qt interface, but is perfectly happy at the command-line. And so
and so forth...


******************************************************************************

Finally, I must apologize for some of my recent mail, it was supposed to
be sent to the Csound mail-list but I hit the wrong button. Now aren't
you all happy I don't work for a nuclear power plant ?!

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Tue Aug 10 22:05:13 1999
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id LAA32540
	for <slinkp@ulster.net>; Tue, 10 Aug 1999 11:39:13 -0400
Received: from bright.net (find-cas1-cs-31.dial.bright.net [209.143.26.134])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id LAA16422;
	Tue, 10 Aug 1999 11:26:38 -0400 (EDT)
Sender: root@sparticus.bright.net
Message-ID: <37B04915.3B25954D@bright.net>
Date: Tue, 10 Aug 1999 11:45:25 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Winkler <slinkp@ulster.net>, Michael Gogins <gogins@nyc.pipeline.com>
CC: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Linux Audio/Music CD: Where things stand now...
References: <37AEF518.5A8E4532@bright.net> <37AFD186.7FDECBFD@ulster.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7cfae22a421d94d840a9a7cd17ad2556

Paul Winkler wrote:

> I was just looking at M. Gogins' license for Silence at:
> http://www.pipeline.com/~gogins/Silence/Silence.htm#License
> NOtice that he uses the GPL but then adds a $100 download fee for any
> "non-personal" useage. Unusual. Would this be a problem? I can't really
> figure it out. Might be a good idea to write to him before including
> Silence in anything.

Perhaps Michael could clarify this point for us ? It is an odd rider,
particularly considering his dedication to providing Silence in a very
open-source package. He was very quick to remove the proprietary stuff
from Silence, and that move enabled Silence for Linux (and I assume
other platforms with Java).
 
> > and actually a bunch of other small progs.
> 
> Most notably SoX. Love it or loathe it, it's hard to avoid using SoX!

Yep, gotta have sox...
 
> ...I'd like to see nearly
> everything on that list developed a bit further before making a distro
> out of it. In particular I'd like so see one of the truly-free sequencer
> projects (not Jazz++) get to a stage of real production useability:
> working midi input and output, etc. Anyone know when the much-fabled
> Rosegarden 3.0 might arise? 2.1 looked promising but didn't seem to work
> very well ... And what's up with Cantor? No new version in  a long
> time...

Rosegarden is in CVS, but at last gander Chris Cannam was in China.
Projects without leaders tend to languish.
 
> I was just at a friends' house playing with 303seq on a windoze box.
> Very fun little proggy. Sort of like SoftWerk only not. Would be a cool
> thing to clone and/or make obsolete!

Have you played with either freebirth or Green Box ? Nice apps, great
fun.

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Tue Aug 10 22:05:28 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA17394
	for <slinkp@ulster.net>; Tue, 10 Aug 1999 13:42:15 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA01221 for linux-audio-dev-list; Tue, 10 Aug 1999 12:56:10 -0400
Received: from mustec.bgsu.edu (mustec.bgsu.edu [129.1.57.200]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA01218 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 10 Aug 1999 12:56:07 -0400
Received: from mustec.bgsu.edu (azygmun@mustec.bgsu.edu [129.1.57.200])
	by mustec.bgsu.edu (8.8.7/8.8.7) with ESMTP id MAA00980
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 10 Aug 1999 12:53:41 -0400
Date: Tue, 10 Aug 1999 12:53:41 -0400 (EDT)
From: Adam Zygmunt <azygmun@bgnet.bgsu.edu>
X-Sender: azygmun@mustec.bgsu.edu
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] My 2 cents (contd.)
Message-ID: <Pine.LNX.4.10.9908101133240.922-100000@mustec.bgsu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: a2ddf50338428ddd65f69e6b9af68121


Analog-type sequencers: Kind of fun. Nice toys. Usually pretty bad 
interfaces, if only that they don't look for default sounds and don't
label much. Would be even nicer if more of them exported files.

And now for the programming side...

Sound drivers: Enough has already been said on this that I'll keep it to a
minimum. Suffice it to say there are sill significant problems with any of
them. OSS/Free still has quite a few bugs that it would be nice to fix.
The latest shows up with OSS/Free PnP Soundblasters (I've tried an AWE-32)
and jMax. If audio in is enabled, the system locks up hard. I personally
have an Ensoniq Audio PCI, and OSS/Free doesn't support /dev/sequencer for
this card at all. I know the wavetable interface for this card is
proprietary, but I don't want to use that. I have external MIDI stuff that
I quite enjoy and would prefer to use anyway, thank you. Trying to explain
this to some of the OSS/Free developers was like talking to a brick wall.
/dev/sndstat support for many of the newly added cards would be nice, too.
Personally, I use ALSA, which suits me well for most purposes. It, however
doesn't support /dev/sequencer2, so I have to go to Windows now to use
Jazz++.
    More documentation of both the OSS and ALSA API's would be extremely
helpful, as would more short, working examples of code. OSS is notoriously
bad in this regard (their oficial documentation is still unfinished after
what, at least three years?) ALSA's is considerably better, though I
haven't been able to write working raw MIDI code yet. I've compiled the
sample code in the docs, and although it runs, it doesn't work for me as
advertized. The audio/MIDI C++ lib mentioned a few messages back, with
accompanying code, looks quite helpful and along the lines of what I'm
talking about.

Compilation issues: I have recently tried to compile some of this
alpha-level software and have had less than spectacular results. I'm using
a RH 5.2 system, with as few non-RPM upgrades of libraries as I can. I am
of the opinion that keeping as few versions of libraries in different
places keeps upgrades easy, keeps fewer things from breaking, and keeps
everything (including myself) from getting confused. I recently spent
hours trying to get jMax to run. It didn't because some little throwaway
piece of java software that I installed and forgot about put an early
version of the JRE somewhere in my path, which jMax kept trying to use. If
I had been able to rpm -e the old java package. As a result of my
compilation troubles, I'll post a my developer wish list:

1. Use as few extra libraries as possible. Use even fewer large,
memory-intensive libraries. If you have to use a lot of them, see what
versions other large packages are using (i.e., if you are using gtk+/glib,
see what version the official, compiled version of Gnome uses. You'll save
those folks endless trouble.) I enjoy source code as much as the next guy,
but for the really big stuff, I don't want to spend hours wating for a
compile, see if works, try again if necessary. For example, for the latest
version of aRts, I needed to get and compile mico...twice. As far as I
know, it's still sitting at home recompiling. Good thing I don't have
anything else that I use on the system that needs mico, which would in all
likelihood would have become broken.

2. Avoid development-version libraries if possible. This is especially
true of whatever latest-and-greatest glibc is out there. I'm willing to
test and debug software, but not at the expense of making the rest of my
system flaky. To try to get some of this stuff up and running, I installed
glibc-2.1 from RH6.0 on a machine yesterday, and suddenly xfstt stopped
working, which kept X from opening, and system shutdown didn't unmount
disks properly. Worked okay the next time after a disk check and an xfstt
recompile, but who knows what else is flaky that I didn't test. I remember
the nightmare with Gnome for a while, where this app insisted on
gtk-1.1.5, while the other one insisted on gtk-1.1.7, while the GIMP would
have none of this and wanted 1.0. Personally, it's a real drag to have to
recompile everything that uses a library just because something new I want
to add requires a new version of the library. I enjoy the source trees
that can deal with a >= version of a lib.

3. Sensibility in downloading and compiling. configure;make;make install
is ideal. Even better when the dependencies work flawlessly. A prime
example is quasimodo, which although it's labeled alpha, is still a little
"creative" in its organization. Would it be too much trouble to combine
all three required files into one, as they all need to extract into the
main directory anyway? Having to run the main build from a subdirectory is
also unusual, especially considering there is a root-level Makefile. To
quasimodo's credit, the compilation procedure is at least well documented.

4. Compiler-independence. Avoid compilation options that are known to be
incompatible between egcs-1.0/egcs-1.1/pgcc/gcc-2.8. When in doubt, expect
the earliest-version compiler that will work. If someone could please
explain to me (as I'm not particularly familiar with the differences) the
advantages of requiring a cutting-edge compiler, please let me know. I
personally have been wary of pgcc, as it is know to have some issues with
kernel compilation.

5. The KISS principle. Make something that works and is useful before
adding all sorts of incomplete bits and pieces of your grand killer app. A
plug-in architecture, I think, is a good example of this.  It would be one
thing if we had anything to plug them into, but right now it's putting the
cart before the horse. Another example is the heavy interest in
interprocess communication and simultaneous use of soundcards.
These are noble goals, but should be attacked after there's working
software. If you do have a grand plan, I'd recommend instead a
well-organized subdivision of source code. So realtime audio isn't up to
your liking right now, put all the low-level audio in and out code in
separate files that can easily be updated when support improves with a
minimum of changes to the core program code.
   One thing I've noticed is that there's very little development of much
Linux audio software. Programs get released at alpha-versions, then they
get debugged, then they get minor updates. What you see on first release
is basically what you're going to get. I haven't seen many major feature
enhancements or interface improvements that would signify a version 2.0.
How many sound editors have we already seen come and go that have
something in the README that goes basically like "I've decided to write
this editor because there are no good ones out there. It's still in alpha
stage right now, but it'll be great. I have it ready for plug-ins and
everything. It'll be the (insert useful application here) of sound..."?

As has already been said, it's easy to criticize but hard to create. My
own GUI and autoconf/automake skill are not up to snuff at this point to
contribute much in the way of code, either. I do also truly appreciate all
the hard work that anyone has put in to create an audio app for Linux, as
it's certainly rocky, uncharted territory. I will also do my best to
continue to try out what's out there. and contribute what I can. Who 
knows, I may even take up gtk one of these days, sort through the morass
that is the sound API documentation, or otherwise jump on a project that
shows some promise and that I can contribute to.

Thanks for listening, and flame away!

Adam Zygmunt
azygmun@bgnet.bgsu.edu

From - Tue Aug 10 22:05:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA27190
	for <slinkp@ulster.net>; Tue, 10 Aug 1999 14:51:12 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA01338 for linux-audio-dev-list; Tue, 10 Aug 1999 14:09:37 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA01334 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 10 Aug 1999 14:09:35 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id OAA19114;
	Tue, 10 Aug 1999 14:06:23 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id OAA15893; Tue, 10 Aug 1999 14:06:22 -0400 (EDT)
Date: Tue, 10 Aug 1999 14:06:22 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: Adam Zygmunt <azygmun@bgnet.bgsu.edu>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] My 2 cents
In-Reply-To: <Pine.LNX.4.10.9908101010590.922-100000@mustec.bgsu.edu>
Message-ID: <Pine.GSO.4.10.9908101249390.11431-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b8b1bc94455ef017711cd4d2c685daef

On Tue, 10 Aug 1999, Adam Zygmunt wrote:

> Multitrack editing and realtime effects would come last, or be more
> likely handled by a decent audio sequencer. 

That's the first time I've heard the term "audio sequencer", but I rather
like what it implies... all the power and then some of an audio-extended
MIDI sequencer (Jazz++, Cakewalk Pro Audio, Cubase VST, etc) without the
MIDI stuff getting in the way.  The right interface for the right task,
not some half-hearted attempt to combine the two.

I'd been using the term "multitrack harddisk recorder" to refer to this,
but many of the multitrack recorders I've seen recently, especially open
source ones, have no more power than an analog 8-track.  What I mean is
you really can't edit the tracks the way you can in a sequencer.  Which of
the multitrack recorder projects in our community here would you folks
consider worthy of the "audio sequencer" name?

> What I would suggest would be that cutting, pasting, and copying MIDI
> events be as easy as possible. Ditto for adding/editing velocity,
> duration, and custom continuous controllers.

Here, here.  For simply entering notes, the piano roll is my tool of
choice (other than live recording), but for anything advanced, you need a
well-designed, powerful event list view.  The shameful thing is that this
is much easier to implement than a good piano roll, but everybody seems to
forget to do it!

BTW, this is the third task on my to do list for Songpad, my Java-based
MIDI sequencer in progress.  The only things ahead of it are (1) internal
data structures (nearly completed), and (2) SMF I/O (starting tonight).
Piano roll and plugin architecture come later.

> Notation: Forget about it. It's such a complex art that to really do it
> justice requires a truly rare breed of programmer.

I'm not a Score user, but I have been using Encore extensively for years,
and have experimented with Finale, Lilypond, and numerous others.  Based
on this experience, I would say that it would not be impossible for
someone from our open source community to do it properly, only difficult.

The key thing is a concept that you left out... do not limit the scope to
only simple features, but keep simple tasks simple.  Encore, and almost
all sequencers which include notation capabilities fail because they only
have simple features.  Score and Finale fail not from lack of features but
because they do not keep simple actions simple for the user.

My hope for the future on this front lies with Guido (see Dave's page for
a link), which is based around just what I've described. At the moment,
they've only implemented the simple features, but their design plan is
very clearly spelled out to continue to fill in the advanced stuff without
sacrificing usability at all.

Just my two centimes (use them while you can, before the Euro obsoletes
them),
Div.

From - Tue Aug 10 22:05:36 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA29436
	for <slinkp@ulster.net>; Tue, 10 Aug 1999 15:06:09 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA01360 for linux-audio-dev-list; Tue, 10 Aug 1999 14:25:43 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA01357 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 10 Aug 1999 14:25:41 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id OAA20111;
	Tue, 10 Aug 1999 14:21:34 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id OAA16728; Tue, 10 Aug 1999 14:21:33 -0400 (EDT)
Date: Tue, 10 Aug 1999 14:21:33 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: Adam Zygmunt <azygmun@bgnet.bgsu.edu>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] My 2 cents (contd.)
In-Reply-To: <Pine.LNX.4.10.9908101133240.922-100000@mustec.bgsu.edu>
Message-ID: <Pine.GSO.4.10.9908101413300.11431-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 357c36e6a513d89044fb6c37b83358a3

On Tue, 10 Aug 1999, Adam Zygmunt wrote:

> 5. The KISS principle. Make something that works and is useful before
> adding all sorts of incomplete bits and pieces of your grand killer app. A
> plug-in architecture, I think, is a good example of this.  It would be one
> thing if we had anything to plug them into, but right now it's putting the
> cart before the horse. Another example is the heavy interest in
> interprocess communication and simultaneous use of soundcards.
> These are noble goals, but should be attacked after there's working
> software. 

I do agree that all architecture and no functionality is a useless
combination.  However, I wouldn't recommend that people throw away all
plans they might have for making some sort of architecture.  Many existing
programs, especially the supposedly well-designed commercial ones, are
crippled because they are not built upon an expandable architecture.
Retrofitting a plugin API or multiple soundcard support takes much more
work than designing it right the first time.

>    One thing I've noticed is that there's very little development of much
> Linux audio software. Programs get released at alpha-versions, then they
> get debugged, then they get minor updates. What you see on first release
> is basically what you're going to get. I haven't seen many major feature
> enhancements or interface improvements that would signify a version 2.0.
> How many sound editors have we already seen come and go that have
> something in the README that goes basically like "I've decided to write
> this editor because there are no good ones out there. It's still in alpha
> stage right now, but it'll be great. I have it ready for plug-ins and
> everything. It'll be the (insert useful application here) of sound..."?

I think this all stems from the "scratch what itches" school of open
source development.  Put a month's worth of work into a program, and often
the original itch might not seem anywhere near as bad as the
implementation issues you discovered when you tried to fix it.  Once the
original developer gives up, it's unfortunately not always the case that
someone will step in to continue the effort.  Maybe we should start a
centralized "open source adoption agency" for projects that were orphaned
by their initial developers.  Anybody think that this might work?

Div.

From - Tue Aug 10 22:05:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA30705
	for <slinkp@ulster.net>; Tue, 10 Aug 1999 15:14:29 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA01368 for linux-audio-dev-list; Tue, 10 Aug 1999 14:28:02 -0400
Received: from mustec.bgsu.edu (mustec.bgsu.edu [129.1.57.200]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA01365 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 10 Aug 1999 14:27:58 -0400
Received: from mustec.bgsu.edu (azygmun@mustec.bgsu.edu [129.1.57.200])
	by mustec.bgsu.edu (8.8.7/8.8.7) with ESMTP id OAA01028;
	Tue, 10 Aug 1999 14:25:22 -0400
Date: Tue, 10 Aug 1999 14:25:22 -0400 (EDT)
From: Adam Zygmunt <azygmun@bgnet.bgsu.edu>
X-Sender: azygmun@mustec.bgsu.edu
To: Dave Phillips <dlphilp@bright.net>
cc: Juhana Sadeharju <kouhia@nic.funet.fi>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Linux Audio/Music CD: Where things stand now...
In-Reply-To: <37B04715.1CD367E1@bright.net>
Message-ID: <Pine.LNX.4.10.9908101341040.1005-100000@mustec.bgsu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c413065f1296f99bbdf55502b8bb934e



On Tue, 10 Aug 1999, Dave Phillips wrote:

> Juhana Sadeharju wrote:
> 
>   1. It wasn't meant to indicate what I thought should go on the disc,
> only to show what I actually have running here. No, not everything
> listed works absolutely perfectly (like everything on Windows does...),
> but everything there works well for my applications. I had received mail
> concerning the actual number of usable programs, so I wrote the list.
> 

I've already written back to you on my progress on these, and I'm still
working on the challenge of getting them all to run without breaking the
rest of my system. The one nice advantage of preparing these as a distro
or better yet, supplimental disks for a particular package system or two,
is that if would force the issue of compilation to be resolved. If it
can't be compiled with reasonably recent, stable libraries, it wouldn't
get included. It might also help us, as a group, decide what basics to 
include in the system. It's reasonable to expect a program to have some
trouble with compilation - a bad include, an undefined #define, etc. - but
this library/compiler pickiness is getting out of hand IMHO. Even if
something compiles, does it segfault because it's a bug in the program or
because I've got libxxx-2.0.7.3 instead of libxxx-2.0.7.2? You see my
point.

>   2. Yes, it does show where we're short. IMO, Linux excels at the more
> experimental types of audio and music apps, and it falls short in the
> domains of MIDI sequencing, wave editing, and software more oriented
> towards making music in popular styles

I'd like to counter and say that tools like these are necessary for ANY
type of composition. Without them, output from "experimental" music
programs (I'm thinking of fractal music in particular) usually doesn't
rise above the level of sonic curiosity. Unless there's some way to add
human judgement, provided in the form of choosing/assembling the good
bits, layering, processing, or mastering a final piece, it's hard to cross
that line between composing and simply messing around. Same thing with all
the wonderful FFT/PVOC sound-altering programs. It'd be nice to have
something you can do with the output.

>   3. Bill Schottstaedt pointed out that it lacked notation progs, so he
> would add CMN (Common Music Notation) and LilyPond to the list.

I haven't really tried either of these, though I installed them both.
Quite frankly, I don't have the patience to learn them (although the
output from CMN does look workable from the manual), even though I've
bothered to learn the notorious Score. I've already expressed my views on
notation a couple of messages ago. Because notation is such a tricky
thing, even the minimum level of interactivity is a must (see Score for
example, where at least every page and usually every system is in its own
file, but you can at least bump objects without having to type a few lines
of code.)

>   4. There are dozens of smaller, excellent applications not on the
> list. For instance, I've been using Mike Oliphant's GRip, a nice
> front-end for cdparanoia (a ripper), BladeEnc, (an MP3 encoder), and
> Mike's own GCD (a CD player). GRip utilizes the cddb, an on-line
> database of CD titles and their contents, very handy when grabbing

Agreed. Nice programs (don't know Mike's own, though). LAME produces
better files, but BladeEnc is good and license-friendly.

> tracks. Then there's Maurizio Puxeddu's PitchTracker suite, a neat new
> GUI for Oyvind Hammer's PTPS code, which Maurizio revisedand updated
> using the FFTW library. Kai Vehmanen's powerful ecasound is now equipped
> with a Qt interface, but is perfectly happy at the command-line. And so
> and so forth...
> 

Don't know about ecasound (what is it?), but these others seem to me do be
more intermediate steps in the sound-creation process (see above).
Pitchtracker is neat and all, but it's the sort of thing
ethnomusicologists got a kick out of 40 years ago. A pitch-to-MIDI or
pitch-to-frequency converter for csound, on the other hand...

I'll stop complaining now for the time being,
Adam Zygmunt

From - Tue Aug 10 22:05:40 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA31544
	for <slinkp@ulster.net>; Tue, 10 Aug 1999 15:20:27 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA01400 for linux-audio-dev-list; Tue, 10 Aug 1999 14:37:05 -0400
Received: from mustec.bgsu.edu (mustec.bgsu.edu [129.1.57.200]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA01397 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 10 Aug 1999 14:37:02 -0400
Received: from mustec.bgsu.edu (azygmun@mustec.bgsu.edu [129.1.57.200])
	by mustec.bgsu.edu (8.8.7/8.8.7) with ESMTP id OAA01035;
	Tue, 10 Aug 1999 14:34:28 -0400
Date: Tue, 10 Aug 1999 14:34:27 -0400 (EDT)
From: Adam Zygmunt <azygmun@bgnet.bgsu.edu>
X-Sender: azygmun@mustec.bgsu.edu
To: est@hyperreal.org
cc: Stefan Nitschke <nitschke@fzi.de>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] can't get any dropouts?
In-Reply-To: <19990810125926.6364.qmail@hyperreal.org>
Message-ID: <Pine.LNX.4.10.9908101427070.1005-100000@mustec.bgsu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 570dfb9d5e1037ce491b818078c5e88b



On Tue, 10 Aug 1999 est@hyperreal.org wrote:

> Please try latencytest (http://www.gardena.net/benno/linux/audio/).
> 
> Possible reasons for your RTSynth results: 
> 
> * You give fragment sizes but not the number of fragments..the product
>   of those is the total audio buffer size.
> 
> * RTSynth probably doesn't have a lot of disk activity.
> 
> * It may also not use much of your processor leaving a lot of slack in
>   which to catch up.
> 
> If you want to generate dropouts in RTSynth, try running top at the
> same time.  You'll also find out RTSynth's processor load. :)  You can
> also try creating a 200M file (head -c 200000000 /dev/zero >tmpfile)
> while RTSynth is running.  Deleting the file is probably even more
> likely to cause dropouts.
> 
> Best,
> 
> Eric
> 

Not to be snotty, but this reminds me of the old joke, "Doctor, it hurts
when I do this." "So don't do that!" My take is that we may actually have
some helpful hints for making a software sequencer - avoid disk access in 
the synth, and avoid taxing the CPU. I also wouldn't expect to use a web  
or central X server as a software synth at the same time with even the
most ideal kernel, either.

Adam Zygmunt


From - Tue Aug 10 22:05:51 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA21139
	for <slinkp@ulster.net>; Tue, 10 Aug 1999 17:47:53 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA01609 for linux-audio-dev-list; Tue, 10 Aug 1999 16:58:43 -0400
Received: from fep03-svc.tin.it (mta03-acc.tin.it [212.216.176.34]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA01606 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 10 Aug 1999 16:58:35 -0400
Received: from tin.it ([212.216.160.122]) by fep03-svc.tin.it
          (InterMail v4.01.01.02 201-229-111-106) with ESMTP
          id <19990810205554.POTQ11176.fep03-svc@tin.it>
          for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Tue, 10 Aug 1999 22:55:54 +0200
Message-ID: <37B09027.C25E765F@tin.it>
Date: Tue, 10 Aug 1999 22:48:39 +0200
From: Maurizio Umberto Puxeddu <umbpux@tin.it>
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Linux Audio/Music CD: Where things stand now...
References: <Pine.LNX.4.10.9908101341040.1005-100000@mustec.bgsu.edu>
Content-Type: text/plain; charset=x-user-defined
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 003a8611de96e8c065f101123aa8dfb6

Hello Adam, hello all.

Adam Zygmunt wrote:
> Pitchtracker is neat and all, but it's the sort of thing
> ethnomusicologists got a kick out of 40 years ago. A pitch-to-MIDI or
> pitch-to-frequency converter for csound, on the other hand...
If you are are talking about an opcode that works like midi opcodes but
listens to a acoustic instrument in real time, I'm not so far from this.

1) My Pitchtrack is a bit more than a port with portable GUI for ptps.
It can also read an audio file or listen to the audiocard DAC and dump
an output of this kind:

<PITCH> <START TIME> <DURATION>

that is equivalent to a MIDI file (anyone has C or C++ code for
generating MIDI files?).

2) The latest version of the underlying pitchtracking library (libpt)
has a new class: PitchSequencer. You can connect a PitchSequencer object
to an AudioFile or AudioADC object and it will store in its memory a
list of Pitch object containing the pitches you played on the mic. The
application can pop Pitches from this FIFO. It's (trasparently)
multithreaded, so you application can do whatever you want in the
meantime. In short you can do something like this:

	// AudioADC (a wrapper to the audiocard code) is derived from the
	// abstract base
	// class AudioSource. AudioFile (a wrapper to Pruett's AFL) is also
	// derived from	
	// the same base class and you can use AudioFiles or AudioADC
	// indifferently.  
	AudioADC mic(BUFFLEN, gain, srate, AudioADC::MIC);

	// This is the pitchtracking engine with the original Hammer's
	// algorithm
	// This istance listens to "mic"
	Listener listener(mic, ... [ some other technical stuff]);

	// This performs the freq->pitch conversion. At the moment there is
	// only one kind of PitchQuantizer (equally tempered half tones)
	PitchQuantizer pq(listener, smothing, central_A_freq, base);

	PitchSequencer seq(pq, [few options]);	

	seq.start();

	// .......
	// Here you can do what you want
	// .......
	// and when you want to ask what pitches have been played you do

	cout << seq.Count() << " notes!!!\n";

	Note *melody;

	melody = seq.GetAll();	

	// Or if you want just one note

	Note *note = seq.Get();

And so on.
As you can see there's enough to make such kind of opcode.

The note parsing algorithm is not perfect but it works. I'll soon start
to test it on a catalogue of acoustic instruments samples I'm recording,
so I can make it more sensible and ready.  I have some toy-application
("mic2mu", a bare-bone melody dictation software that speaks
Mudela(Lilypond), and "Sensual", a command line control for doing tests,
and I'm working to a toy-composition "Interactive Electroacoustic
Variations": a real-time algorithmic composition software is influenced
by the tunes singed or played on the mic, variate them and mixes them
with random generated ones, and uses Csound as real-time synthesis
engine: I need lots of computational power!)

I was wondering what is the better way to use it in interactive
composition and a csound opcode may be a choice. If one or two of you
are interested in a csound opcode I could work on it. I never wrote an
opcode so help is WELCOME.

Maurizio Umberto Puxeddu

From - Wed Aug 11 11:39:02 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id FAA24704
	for <slinkp@ulster.net>; Wed, 11 Aug 1999 05:51:19 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id EAA02702 for linux-audio-dev-list; Wed, 11 Aug 1999 04:54:48 -0400
Received: from sculpcave.localdomain (cvx-2-101.dyn.nic.fi [62.236.99.101]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA02699 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 11 Aug 1999 04:54:44 -0400
Received: (from root@localhost)
	by sculpcave.localdomain (8.8.7/8.8.7) id AAA01889;
	Wed, 11 Aug 1999 00:34:58 +0300
Date: Wed, 11 Aug 1999 00:34:57 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
To: Adam Zygmunt <azygmun@bgnet.bgsu.edu>
cc: Dave Phillips <dlphilp@bright.net>, Juhana Sadeharju <kouhia@nic.funet.fi>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Linux Audio/Music CD: Where things stand now...
In-Reply-To: <Pine.LNX.4.10.9908101341040.1005-100000@mustec.bgsu.edu>
Message-ID: <%oJJs3k9Ag@sculpcave>
X-User-Agent: Mana 4.0beta (Linux)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b798d92f45fb281cedaee96e4a576778

On Tue, 10 Aug 1999, Adam Zygmunt wrote:

> Don't know about ecasound (what is it?), but these others seem to me do be
> more intermediate steps in the sound-creation process (see above).

Ecasound can be used as a audiofile player, fx processor, signal
router, format converter, multitrack recorder&mixer, etc etc... 
If you want to do these things in console mode, you might 
find ecasound useful. Others should wait for the next stable release
(1.4.xxx) which will have a more usable X-interface. This really isn't 
a new project as I've been developing (and using) it since 1997. I
released the first public version just a month a ago. I guess the 
main reason why I didn't release this before was the user interface.
Writing a good, intuitive interface means a _lot_ of work. If you are
the only user, you can skip most of it (which I did). Now I've spent
the last few months improving the UI, but I still have a lot of work
ahead of me.

-- 
Kai Vehmanen ----------------------------- CS, University of Turku, Finland
 : email                                 mailto:kaiv@wakkanet.fi
 : audio processing for linux            http://www.wakkanet.fi/ecasound/
 : my music (ambient-idm-rock-...mp3/ra) http://www.wakkanet.fi/sculpscape/


From - Tue Aug 10 22:06:02 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA10798
	for <slinkp@ulster.net>; Tue, 10 Aug 1999 20:35:23 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA01851 for linux-audio-dev-list; Tue, 10 Aug 1999 19:56:01 -0400
Received: from mustec.bgsu.edu (mustec.bgsu.edu [129.1.57.200]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA01848 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 10 Aug 1999 19:55:58 -0400
Received: from mustec.bgsu.edu (azygmun@mustec.bgsu.edu [129.1.57.200])
	by mustec.bgsu.edu (8.8.7/8.8.7) with ESMTP id TAA01115;
	Tue, 10 Aug 1999 19:53:35 -0400
Date: Tue, 10 Aug 1999 19:53:35 -0400 (EDT)
From: Adam Zygmunt <azygmun@bgnet.bgsu.edu>
X-Sender: azygmun@mustec.bgsu.edu
To: David Slomin <dgslomin@CS.Princeton.EDU>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] My 2 cents
In-Reply-To: <Pine.GSO.4.10.9908101249390.11431-100000@ux02.CS.Princeton.EDU>
Message-ID: <Pine.LNX.4.10.9908101820470.1039-100000@mustec.bgsu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f87a4bd91bed3e5c5fb7a8b32aa45303



On Tue, 10 Aug 1999, David Slomin wrote:

> On Tue, 10 Aug 1999, Adam Zygmunt wrote:
> 
> > Multitrack editing and realtime effects would come last, or be more
> > likely handled by a decent audio sequencer. 
> 
> That's the first time I've heard the term "audio sequencer", but I rather
> like what it implies... all the power and then some of an audio-extended
> MIDI sequencer (Jazz++, Cakewalk Pro Audio, Cubase VST, etc) without the
> MIDI stuff getting in the way.  The right interface for the right task,
> not some half-hearted attempt to combine the two.
> 

I don't necessarily think the two shouldn't be combined, which is what I
meant by audio sequencer. Until recently, audio-extended sequencers have
been half-hearted, but they've certainly gotten a lot better. The newest
version of Vision DSP, for example, has significant improvements on both
the audio and MIDI fronts, and actually works quite capably as a
multitrack recorder. It even has a few nifty features like analyzing the
beats in an audio file and quantizing the MIDI to it. 

A good example, though, of an audio-only type program that works extremely
well with nonlinear multitrack audio (save for splicing, but you can't
have everything now, can you?) is the multitrack view of Cool Edit Pro.
I hadn't thought of the concept of audio-only sequencer before, but this
probably fits the bill. Other than pan and volume, though, there are no
realtime effects. These are either done to the source files beforehand or
to the final mix.

I would say that there is enough commonality between sequencing and
multitrack recording that even if they are separate programs, they could
certainly share a lot of code and have similar look-and-feel.

> you really can't edit the tracks the way you can in a sequencer.  Which of
> the multitrack recorder projects in our community here would you folks
> consider worthy of the "audio sequencer" name?
> 
I would say Multitrack would be the closest thing, though it's certainly
got its issues. Namely, the source code thing and the proprietary SVGA
interface (new X interface was very unstable for me, I'm afraid). It's
exceptionally responsive, but it's so "unique" that getting it to play
nice with others might be difficult.

> > What I would suggest would be that cutting, pasting, and copying MIDI
> > events be as easy as possible. Ditto for adding/editing velocity,
> > duration, and custom continuous controllers.
> 
> Here, here.  For simply entering notes, the piano roll is my tool of
> choice (other than live recording), but for anything advanced, you need a
> well-designed, powerful event list view.  The shameful thing is that this
> is much easier to implement than a good piano roll, but everybody seems to
> forget to do it!

So true, but being able to draw in extra parameters easily is good too.
Most sequencers already do this. Some do it better than others. Some of my
pet peeves with various sequencers are (if you're open to suggestions):
1. Event lists that don't list ALL the events. ESPECIALLY initialization
events.
2. Sequencers that force all the MIDI events in one track onto one
channel. Particularly a problem with some imported MIDI files.
3. Sequencers that only allow you to change a few controllers by GM name,
instead of all by number. Not everything, especially external stuff, works
according to GM (having all the XG controllers named is nice, though).
4. Sequencers that force a GM reset at the beginning of a piece.
Especially bad when combined with 1. 3 and 4 are why I use Jazz++ almost
exclusively for sequencing (for a Yamaha CS1x), despite its clunkiness.
5. Other general stupidity. One sequencer I used, for example, would send
a patch change AFTER a note whenever they had the same time code! I ended
up having to manually find all the patch changes (orchestra piece squeezed
down to 16 MIDI tracks) and retype their times a little earlier in the
event list. Only sequencer I had access to at the time, though.

> I'm not a Score user, but I have been using Encore extensively for years,
> and have experimented with Finale, Lilypond, and numerous others.  Based
> on this experience, I would say that it would not be impossible for
> someone from our open source community to do it properly, only difficult.
> 
> The key thing is a concept that you left out... do not limit the scope to
> only simple features, but keep simple tasks simple.  Encore, and almost
> all sequencers which include notation capabilities fail because they only
> have simple features.  Score and Finale fail not from lack of features but
> because they do not keep simple actions simple for the user.

So true!

> My hope for the future on this front lies with Guido (see Dave's page for
> a link), which is based around just what I've described. At the moment,
> they've only implemented the simple features, but their design plan is
> very clearly spelled out to continue to fill in the advanced stuff without
> sacrificing usability at all.

I've checked out Guido, and I would not necessarily say it keeps simple
things simple. There's too much punctuation to keep track of and too much
typing to do for anything past Three Blind Mice. It's not interactive,
either, which as I said before, is a major drawback. Even Score is more of
an interpreter than a compiler. I looked at the docs, and the simple
Beethoven Quartet example is hellishly like TeX gone wrong.
The thought of having to deal with
 \crescBegin<dx=1.28,dy=-5.76> d2/8 \space<6.4>
 \merge( b1/16 \crescEnd<dy-5.76>
to get a simple crescendo is frightening, and I don't scare easily.
Especially trying to work without feedback this way. That the docs were
obviously set in TeX, to so it is probably safe to assume the authors are
not real human beings, but are rather some of those odd creatures still
fluent in TeX. Not only that, but Guido's language structure simply does
not seem abstract enough for music. Complex things will necessarily get
REAL complex. It doesn't even look like this is a suitable core for a
interactive shell, as there's WAY too much grammar involved and not enough
control over individual objects.

Score's got plenty of faults, and it's not what choose to use for most
projects, but it does have one good feature. It's internal representation
of things is so elegant, there's little room for improvement. The
representation is numerical, but could easily have one-word substitutions
where appropriate to make it easier to deal with. For example, a line of
code could be:
note quarter 1 50.0 3 1, for a quarter note on the first staff, 50.0
whatevers from the left margin, middle line (3 whole space units up from
baseline), regular size (1). note tells the printer (or interactive outer
layer) what the rest of the parameters stand for and quarter stands for
whatever number represents a quarter note in the font table.
note quarter 1 50.0 3 1 up    for same note, stem up
note quarter 1 50.0 3 1 default 2 for same note, default stem direction, 2
staff-unit-length stem, and so on. Notice default is sort of a
placeholder, and less-used options are assigned positions further down the
list. Score's method of object representation is only a little more
complicated, the main addition being a 1 in there somewhere for duration
(used for spacing) which should probably be in there explicitly and not
assumed from quarter.
   It would be up to the outer, interactive layer of the program to
calculate good horizontal positions of objects, provide for easy selection
of objects, allow editing, and do MIDI translation. It's an abstract
enough format that with the proper selection of primitives, it can be made
to do anything relatively simply. You want feathered beaming, just draw in
another beam. Copy the line representing the beam you want to feather,
change the parameter for vertical height, and presto! Another advantage
of this sort of development is that the translation from this sort of text
representation to an actual printout would be quite a bit simpler than the
other Unix notation packages out there, could be used right away, and
could have an iteractive outer layer that could be expanded bit by bit.
Not to mention the possibility of a selection of outer layers.
   I personally use Sibelius right now for notation (easy to use, yet as
flexible as Finale and certainly smarter), but jumping into a 
Sibelius-type program immediately would be insanity. It could eventually
be built on top of something like this, though.

> Just my two centimes (use them while you can, before the Euro obsoletes
> them),
> Div.
> 

Adam Zygmunt

From - Tue Aug 10 22:05:55 1999
Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.74])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id UAA06689
	for <slinkp@ulster.net>; Tue, 10 Aug 1999 20:05:42 -0400
Received: from Realizer (user-2ive5hj.dialup.mindspring.com [165.247.22.51])
	by smtp6.mindspring.com (8.8.5/8.8.5) with SMTP id TAA09604;
	Tue, 10 Aug 1999 19:53:09 -0400 (EDT)
Message-ID: <003101bee38b$d4dc01a0$79d496c0@Realizer.ngt.sungard.com>
From: "Michael Gogins" <gogins@nyc.pipeline.com>
To: "Dave Phillips" <dlphilp@bright.net>, "Paul Winkler" <slinkp@ulster.net>
Cc: "LAD Mail" <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Linux Audio/Music CD: Where things stand now...
Date: Tue, 10 Aug 1999 19:55:29 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 841d1bc6f36fc75eeca1440e410add40

Let me emphasize that the download fee for Silence is not a software
license. The source code is pure GPL. You can turn right around and throw
disks of it out the windows of tall buildings and I will not complain.

Let me also emphasize that there is no fee if you do not publish music made
with Silence. You can play with it at home all you like for free. You can
redistribute it all you like for free.  If you spend thousands of dollars
putting together a CD using Silence I assume you will not mind paying me
$100.

I simply hate the thought of doing all this work not even receiving any
symbolic or token compensation.

I may change my mind on this, too.

I got into this situation by using Csound for synthesis... I have capitalist
instincts and would naturally want to charge for software... but Csound was
the best thing I could find for my purposes and I could not sell it (or buy
it, for that matter). Music is more important to me than money, so I made
the Silence license the way I did so I could continue to use Csound as part
of my system.

-----Original Message-----
From: Dave Phillips <dlphilp@bright.net>
To: Paul Winkler <slinkp@ulster.net>; Michael Gogins
<gogins@nyc.pipeline.com>
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Date: Tuesday, August 10, 1999 11:26 AM
Subject: Re: [linux-audio-dev] Linux Audio/Music CD: Where things stand
now...


>Paul Winkler wrote:
>
>> I was just looking at M. Gogins' license for Silence at:
>> http://www.pipeline.com/~gogins/Silence/Silence.htm#License
>> NOtice that he uses the GPL but then adds a $100 download fee for any
>> "non-personal" useage. Unusual. Would this be a problem? I can't really
>> figure it out. Might be a good idea to write to him before including
>> Silence in anything.
>
>Perhaps Michael could clarify this point for us ? It is an odd rider,
>particularly considering his dedication to providing Silence in a very
>open-source package. He was very quick to remove the proprietary stuff
>from Silence, and that move enabled Silence for Linux (and I assume
>other platforms with Java).
>
>> > and actually a bunch of other small progs.
>>
>> Most notably SoX. Love it or loathe it, it's hard to avoid using SoX!
>
>Yep, gotta have sox...
>
>> ...I'd like to see nearly
>> everything on that list developed a bit further before making a distro
>> out of it. In particular I'd like so see one of the truly-free sequencer
>> projects (not Jazz++) get to a stage of real production useability:
>> working midi input and output, etc. Anyone know when the much-fabled
>> Rosegarden 3.0 might arise? 2.1 looked promising but didn't seem to work
>> very well ... And what's up with Cantor? No new version in  a long
>> time...
>
>Rosegarden is in CVS, but at last gander Chris Cannam was in China.
>Projects without leaders tend to languish.
>
>> I was just at a friends' house playing with 303seq on a windoze box.
>> Very fun little proggy. Sort of like SoftWerk only not. Would be a cool
>> thing to clone and/or make obsolete!
>
>Have you played with either freebirth or Green Box ? Nice apps, great
>fun.
>
>== Dave Phillips
>
>       http://www.bright.net/~dlphilp/index.html
>   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Tue Aug 10 22:06:08 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA12754
	for <slinkp@ulster.net>; Tue, 10 Aug 1999 20:50:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA01904 for linux-audio-dev-list; Tue, 10 Aug 1999 20:11:05 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id UAA01901 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 10 Aug 1999 20:11:03 -0400
From: est@hyperreal.org
Received: (qmail 13199 invoked by uid 162); 11 Aug 1999 00:08:26 -0000
Message-ID: <19990811000826.13198.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] can't get any dropouts?
In-Reply-To: <Pine.LNX.4.10.9908101427070.1005-100000@mustec.bgsu.edu> from Adam
 Zygmunt at "Aug 10, 1999 02:34:27 pm"
To: Adam Zygmunt <azygmun@bgnet.bgsu.edu>
Date: Tue, 10 Aug 1999 17:08:26 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d4e7510e9b090e99c71dde513d637f73

Adam Zygmunt discourseth:
> 
> > If you want to generate dropouts in RTSynth, try running top at the
> > same time.  You'll also find out RTSynth's processor load. :)  You can
> > also try creating a 200M file (head -c 200000000 /dev/zero >tmpfile)
> > while RTSynth is running.  Deleting the file is probably even more
> > likely to cause dropouts.
> 
> Not to be snotty, but this reminds me of the old joke, "Doctor, it hurts
> when I do this." "So don't do that!"

Well, the point of such experiments is to realize that even though you
haven't heard any dropouts yet, it's because you've been lucky.  Do
you want to count on continuing to be lucky (going into single-user
mode helps), or do you want reliability and convenience?

Eric

From - Tue Aug 10 22:06:11 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA12911
	for <slinkp@ulster.net>; Tue, 10 Aug 1999 20:51:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA01914 for linux-audio-dev-list; Tue, 10 Aug 1999 20:15:42 -0400
Received: from mustec.bgsu.edu (mustec.bgsu.edu [129.1.57.200]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA01911 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 10 Aug 1999 20:15:39 -0400
Received: from mustec.bgsu.edu (azygmun@mustec.bgsu.edu [129.1.57.200])
	by mustec.bgsu.edu (8.8.7/8.8.7) with ESMTP id UAA01141;
	Tue, 10 Aug 1999 20:13:16 -0400
Date: Tue, 10 Aug 1999 20:13:16 -0400 (EDT)
From: Adam Zygmunt <azygmun@bgnet.bgsu.edu>
X-Sender: azygmun@mustec.bgsu.edu
To: Maurizio Umberto Puxeddu <umbpux@tin.it>
cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Linux Audio/Music CD: Where things stand now...
In-Reply-To: <37B09027.C25E765F@tin.it>
Message-ID: <Pine.LNX.4.10.9908101956490.1039-100000@mustec.bgsu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f214b3a28a7453a7fed1e1065eb6f1a3



On Tue, 10 Aug 1999, Maurizio Umberto Puxeddu wrote:

> Hello Adam, hello all.
> 
> Adam Zygmunt wrote:
> > Pitchtracker is neat and all, but it's the sort of thing
> > ethnomusicologists got a kick out of 40 years ago. A pitch-to-MIDI or
> > pitch-to-frequency converter for csound, on the other hand...
> If you are are talking about an opcode that works like midi opcodes but
> listens to a acoustic instrument in real time, I'm not so far from this.

Fantastic!

> 1) My Pitchtrack is a bit more than a port with portable GUI for ptps.
> It can also read an audio file or listen to the audiocard DAC and dump
> an output of this kind:
> 
> <PITCH> <START TIME> <DURATION>
> 
> that is equivalent to a MIDI file (anyone has C or C++ code for
> generating MIDI files?).
> 

Sounds neat. I'll definitely check that out when I can. Through an error
of mine, it got wiped out when I did a disk upgrade to our server at
mustec.bgsu.edu, where it was last seen. I've emailed Dave Phillips
already today asking him to reupload it to mustec.bgsu.edu if he still has
it, but if you could also send it up to the incoming directory, I'll be 
sure that it gets put back right away.
   What I meant before what that having just the printout by itself isn't
particularly useful, but it sounds like your work is a long way from that.
Like I said, I'll give it a shot as soon as I can get it.

> As you can see there's enough to make such kind of opcode.
> 
> The note parsing algorithm is not perfect but it works. I'll soon start
> to test it on a catalogue of acoustic instruments samples I'm recording,
> so I can make it more sensible and ready.  I have some toy-application
> ("mic2mu", a bare-bone melody dictation software that speaks
> Mudela(Lilypond), and "Sensual", a command line control for doing tests,
> and I'm working to a toy-composition "Interactive Electroacoustic
> Variations": a real-time algorithmic composition software is influenced
> by the tunes singed or played on the mic, variate them and mixes them
> with random generated ones, and uses Csound as real-time synthesis
> engine: I need lots of computational power!)
> 
> I was wondering what is the better way to use it in interactive
> composition and a csound opcode may be a choice. If one or two of you
> are interested in a csound opcode I could work on it. I never wrote an
> opcode so help is WELCOME.

Sounds good to me. This is one area where things have actually gone quite
a bit backwards. There used to be some hardware pitch detectors on the
market for musical applications (i.e. pitch-to-MIDI, pitch-to-CV), but I
don't think any are still being made outside of one-offs and custom
equipment. There are a couple of Windows programs that I know of, but an
open source alternative could certainly step in to fill a void. A csound
opcode would probably be one of the best ways to put such an algorithm to
use.

> 
> Maurizio Umberto Puxeddu
> 


From - Wed Aug 11 11:38:58 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA11769
	for <slinkp@ulster.net>; Wed, 11 Aug 1999 01:43:42 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id BAA02266 for linux-audio-dev-list; Wed, 11 Aug 1999 01:09:06 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA02263 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 11 Aug 1999 01:09:03 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id BAA23727;
	Wed, 11 Aug 1999 01:04:53 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id BAA10552; Wed, 11 Aug 1999 01:04:52 -0400 (EDT)
Date: Wed, 11 Aug 1999 01:04:52 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: Adam Zygmunt <azygmun@bgnet.bgsu.edu>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] My 2 cents
In-Reply-To: <Pine.LNX.4.10.9908101820470.1039-100000@mustec.bgsu.edu>
Message-ID: <Pine.GSO.4.10.9908102242360.6300-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b377cf6e385382e83643bf40bcbcff58

On Tue, 10 Aug 1999, Adam Zygmunt wrote:

> 1. Event lists that don't list ALL the events. ESPECIALLY initialization
> events.

I certainly agree, but the question can arise as to what constitutes an
event.  Is there such a thing as a note, or is it a note on and a note
off?  Is an RPN one event or two?  In my current design, I support both
forms for each, and provide functions to convert between the two according
to your needs.  I plan to propogate this functionality through to the
end-user interface as well.

> 2. Sequencers that force all the MIDI events in one track onto one
> channel. Particularly a problem with some imported MIDI files.

This definitely stems from the piano roll centric view of the world.  It's
fairly hard to present tracks containing multiple channels in a manageable
manner in a two dimentional interface.  I have a potential plan for how to
handle this reasonably in the piano roll (why do I feel like this is
Fermat's last sequencer?) and it's certainly easy enough in the event list
view.

> 3. Sequencers that only allow you to change a few controllers by GM name,
> instead of all by number. Not everything, especially external stuff, works
> according to GM (having all the XG controllers named is nice, though).

Agreed.  To me, a MIDI sequencer should handle raw MIDI.  Shortcuts for
GM, XG (Yamaha), GS (Roland), MTC (SMPTE sync), MSC (stage lighting
control) and any other such conventions should definitely be treated as
that... shortcuts, not the primary interface.  This is of particular
interest to me, since my own external synth (Yamaha SY22) is older than
GM, and uses its own patch map.

> 4. Sequencers that force a GM reset at the beginning of a piece.
> Especially bad when combined with 1. 3 and 4 are why I use Jazz++ almost
> exclusively for sequencing (for a Yamaha CS1x), despite its clunkiness.

I hadn't even thought of adding one, but I guess it would be a nice option
to throw in, as long as people like us who don't need it can turn it off.

> 5. Other general stupidity. One sequencer I used, for example, would send
> a patch change AFTER a note whenever they had the same time code! I ended
> up having to manually find all the patch changes (orchestra piece squeezed
> down to 16 MIDI tracks) and retype their times a little earlier in the
> event list. Only sequencer I had access to at the time, though.

That brings up a question... is it the job of the sequencer to decide how
to order events with the same timestamp?  Should you honor the order they
appeared in the file or came over the wire?  Should you leave it up to the
user by adding "nudge" commands to the interface?

> The thought of having to deal with
>  \crescBegin<dx=1.28,dy=-5.76> d2/8 \space<6.4>
>  \merge( b1/16 \crescEnd<dy-5.76>
> to get a simple crescendo is frightening, and I don't scare easily.

Agreed.  I wouldn't call it a perfect or even decent solution, but a
project that sets intelligent goals.

> Especially trying to work without feedback this way. That the docs were
> obviously set in TeX, to so it is probably safe to assume the authors are
> not real human beings, but are rather some of those odd creatures still
> fluent in TeX. 

As someone who programs in compiled languages for a living, I've
personally become very used to the edit, compile, test, repeat cycle, but
I wouldn't expect it to work for everyone.  I write HTML by hand, too.

> note quarter 1 50.0 3 1, for a quarter note on the first staff, 50.0
> whatevers from the left margin, middle line (3 whole space units up from
> baseline), regular size (1). note tells the printer (or interactive outer
> layer) what the rest of the parameters stand for and quarter stands for
> whatever number represents a quarter note in the font table.

This is pretty clean.  Actually, it looks a lot like CSound score syntax,
which is probably not accidental at all if you trace the history back far
enough (they're both old programs).  If I had personal experience with the
real thing, I would probably look towards an open source, portable Score
clone as a target for a notation project.

In any event, the difference is that Score looks like it's very closely
tied to the visual end of notation, whereas Guido tries to stay more
towards the musical expression end (a la Common Music).  The Guido
developers want to use it for musical analysis, not just for notation.
It might well be that no single score language or program can decently
do both.

Interesting thoughts though,
Div.

From - Wed Aug 11 11:39:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA25963
	for <slinkp@ulster.net>; Wed, 11 Aug 1999 11:29:58 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA03136 for linux-audio-dev-list; Wed, 11 Aug 1999 10:29:21 -0400
Received: from sculpcave.localdomain (cvx-1-83.dyn.nic.fi [62.236.97.83]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA03133 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 11 Aug 1999 10:29:16 -0400
Received: (from root@localhost)
	by sculpcave.localdomain (8.8.7/8.8.7) id PAA02719;
	Wed, 11 Aug 1999 15:49:01 +0300
Date: Wed, 11 Aug 1999 15:49:00 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
To: Adam Zygmunt <azygmun@bgnet.bgsu.edu>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] My 2 cents (contd.)
In-Reply-To: <Pine.LNX.4.10.9908101133240.922-100000@mustec.bgsu.edu>
Message-ID: <%WsJs3k9Ah@sculpcave>
X-User-Agent: Mana 4.0beta (Linux)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0521f46666ea130ddefa75ec81311564

On Tue, 10 Aug 1999, Adam Zygmunt wrote:

> Compilation issues: I have recently tried to compile some of this
> alpha-level software and have had less than spectacular results. I'm using

This seems to be a common problem. I've tried to keep this in mind 
while developing my programs, but it's difficult to avoid these
things.

> true of whatever latest-and-greatest glibc is out there. I'm willing to
> test and debug software, but not at the expense of making the rest
> of my system flaky. To try to get some of this stuff up and running,
> I installed glibc-2.1 from RH6.0 on a machine yesterday, and
> suddenly xfstt stopped working, which kept X from opening, and

Glibc has sure caused a lot of confusion. I guess glibc was adopted 
too early by major linux distributions. Glibc versions >=2.0.6 were 
classified as "production quality" while 2.1.x series is said to be 
"ready for mainstream use". So hopefully these problems will slowly
disappear as more people upgrade to 2.1.x.

> the nightmare with Gnome for a while, where this app insisted on
> gtk-1.1.5, while the other one insisted on gtk-1.1.7, while the GIMP would
> have none of this and wanted 1.0. Personally, it's a real drag to have to

This is one big advantage of Qt. You don't have this kind of trouble 
with it as Qt developers are _really_ careful with binary and source
compatibility.

> 4. Compiler-independence. Avoid compilation options that are known to be
> incompatible between egcs-1.0/egcs-1.1/pgcc/gcc-2.8. When in doubt, expect
> the earliest-version compiler that will work. If someone could please

Hopefully the new gcc 2.95 will solve most of these problems, as it 
combines the gcc and egcs projects. It also makes C++ development 
easier. Previously you had a quite a mess with gcc, egcs, libstdc++, 
libg++, ... Now gcc 2.95 is all you need. At least for me, using 
older versions of gcc/egcs is not an option as they don't work well
with some C++ features. C++ exceptions are a good example of this. If
you choose not to use them because the compiler can't handle them,
you'll have to make _major_ changes to your software. 

> 5. The KISS principle. Make something that works and is useful before
> adding all sorts of incomplete bits and pieces of your grand killer app. A
> plug-in architecture, I think, is a good example of this.  It would be one

I disagree with you on this. Time is what all open-source developers are
short of and this is why plug-in architecture is important. This is also
why libaudiofile, libsndfile and others have helped linux audio so much.

-- 
Kai Vehmanen ----------------------------- CS, University of Turku, Finland
 : email                                 mailto:kaiv@wakkanet.fi
 : audio processing for linux            http://www.wakkanet.fi/ecasound/
 : my music (ambient-idm-rock-...mp3/ra) http://www.wakkanet.fi/sculpscape/


 

From - Wed Aug 11 11:39:03 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA25915
	for <slinkp@ulster.net>; Wed, 11 Aug 1999 11:29:45 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA03163 for linux-audio-dev-list; Wed, 11 Aug 1999 10:39:22 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA03160 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 11 Aug 1999 10:39:20 -0400
Received: from bright.net (find-cas2-cs-48.dial.bright.net [209.143.26.202])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id KAA07517;
	Wed, 11 Aug 1999 10:36:39 -0400 (EDT)
Message-ID: <37B18ED9.2683DAC4@bright.net>
Date: Wed, 11 Aug 1999 10:55:21 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Kai Vehmanen <kaiv@wakkanet.fi>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] My 2 cents (contd.)
References: <%WsJs3k9Ah@sculpcave>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 846a25e37cf79a87906a9414d2861e00

Kai Vehmanen wrote:

> ...one big advantage of Qt. You don't have this kind of trouble
> with it as Qt developers are _really_ careful with binary and source
> compatibility.

Not careful enough, it seems. I would advise anyone upgrading from 1.42
to 2.00 to keep their previous installation as a backup. The 2.00
headers broke my attempt at compiling thud, and I could not fix it until
I replaced those headers with those from 1.42.

Measure twice, cut once...

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Fri Aug 13 01:46:12 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA23175
	for <slinkp@ulster.net>; Wed, 11 Aug 1999 19:07:28 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA04119 for linux-audio-dev-list; Wed, 11 Aug 1999 18:31:08 -0400
Received: from sculpcave.localdomain (cvx-1-11.dyn.nic.fi [62.236.97.11]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA04116 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 11 Aug 1999 18:31:04 -0400
Received: (from root@localhost)
	by sculpcave.localdomain (8.8.7/8.8.7) id SAA07060;
	Wed, 11 Aug 1999 18:14:48 +0300
Date: Wed, 11 Aug 1999 18:14:48 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
To: Dave Phillips <dlphilp@bright.net>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] My 2 cents (contd.)
In-Reply-To: <37B18ED9.2683DAC4@bright.net>
Message-ID: <%Q5Ys38vA4@sculpcave>
X-User-Agent: Mana 4.0beta (Linux)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ae9856ea0b16f94d18cbcd40c069d725

On Wed, 11 Aug 1999, Dave Phillips wrote:

>> ...one big advantage of Qt. You don't have this kind of trouble
>> with it as Qt developers are _really_ careful with binary and source
>> compatibility.
> Not careful enough, it seems. I would advise anyone upgrading from 1.42
> to 2.00 to keep their previous installation as a backup. The 2.00
> headers broke my attempt at compiling thud, and I could not fix it until
> I replaced those headers with those from 1.42.

But this is a different thing. 1.x -> 2.x is a big change in Qt.
Major version number was changed because 1.x and 2.x are not 
binary nor source compatible. When installing 2.x versions of Qt, 
you shouldn't install them over the old ones. The first KDE version
to use Qt 2.0 will be KDE 2.0 and it'll take quite some time before
it is released (the next release will be 1.1.2). So you still need 
to have Qt 1.xx runtime libs and include files.

Btw; Qt 2.x packages even include a script, which converts 1.x based
source code to 2.x compatible code... So Trolltech really takes these
things seriously.

--
Kai Vehmanen ----------------------------- CS, University of Turku, Finland
 : email                                 mailto:kaiv@wakkanet.fi
 : audio processing for linux            http://www.wakkanet.fi/ecasound/
 : my music (ambient-idm-rock-...mp3/ra) http://www.wakkanet.fi/sculpscape/


From - Fri Aug 13 01:45:59 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA14835
	for <slinkp@ulster.net>; Wed, 11 Aug 1999 14:07:01 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA03565 for linux-audio-dev-list; Wed, 11 Aug 1999 13:05:58 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA03545 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 11 Aug 1999 13:04:29 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id NAA27377
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 11 Aug 1999 13:00:17 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id NAA06706; Wed, 11 Aug 1999 13:00:08 -0400 (EDT)
Date: Wed, 11 Aug 1999 13:00:08 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] MIDI question
In-Reply-To: <37B18ED9.2683DAC4@bright.net>
Message-ID: <Pine.GSO.4.10.9908111250250.6068-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: d1acb45c6b49811fe13780f20ea21971


So I'm working on my sequencer, reading over the MIDI specs, and I
realize that I don't have a really clear understanding of how MIDI
controller messages work.

I understand the simple case: coarse value adjust only of one of the
base controllers (modulation, sustain, etc), which is sent in a single
message.

What I'd like to how the other three cases work:

1.  Fine value adjust of one of the base controllers.  I think this is
sent by sending the coarse value (MSB) as one message followed immediately
by the corresponding fine value (LSB) as the second message.

2.  Fine value adjust for an [N]RPN.  I think you do this by sending the
MSB of the [N]RPN number in one message, followed by the LSB of the [N]RPN
number in a second message, followed by the MSB of the value in a coarse
Data Entry controller message, followed by the the LSB of the value in a 
fine Data Entry controller message.

3.  Is there ever a case of a coarse value only [N]RPN?

Anybody know if I'm on the right track?

Thanks,
Div.

From - Fri Aug 13 01:46:01 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA22330
	for <slinkp@ulster.net>; Wed, 11 Aug 1999 15:01:39 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA03679 for linux-audio-dev-list; Wed, 11 Aug 1999 14:09:46 -0400
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id OAA03676 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 11 Aug 1999 14:09:43 -0400
Message-Id: <199908111809.OAA03676@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] can't get any dropouts?
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Wed, 11 Aug 1999 14:06:24 -0400 (EDT)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
In-Reply-To: <Pine.LNX.4.10.9908101427070.1005-100000@mustec.bgsu.edu> from "Adam Zygmunt" at Aug 10, 99 02:34:27 pm
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5f562abf207846e6f7f150b07df2265e

Adam Zygmunt wrote:
> Not to be snotty, but this reminds me of the old joke, "Doctor, it hurts
> when I do this." "So don't do that!" My take is that we may actually have
> some helpful hints for making a software sequencer - avoid disk access in 
> the synth, and avoid taxing the CPU.

Which would mean that Linux couldn't support DAW software -- needs to
a) stream many tracks off disk, and b) run them through CPU-intensive
plugins.  I don't feel that "don't do that then" is acceptable
indefinitely as a workaround for OS performance bugs with these
consequences.

A vanilla 2.2 installation has possibly the crummiest timing of any
widely-used OS.  W98 has problems, oh yeah, but at least disk access
doesn't hammer timing like this.  (Well, but the sliding menus do.)
This issue deserves the attention it's now getting.

I wish I had the expertise to go through the kernel nailing RT bugs.
The least I can do is help make a lot of noise so the work being done
by others is noticed and maybe merged into the kernel eventually.

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Fri Aug 13 01:46:02 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA25986
	for <slinkp@ulster.net>; Wed, 11 Aug 1999 15:30:05 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA03728 for linux-audio-dev-list; Wed, 11 Aug 1999 14:45:49 -0400
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id OAA03725 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 11 Aug 1999 14:45:47 -0400
Message-Id: <199908111845.OAA03725@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] My 2 cents
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Wed, 11 Aug 1999 14:42:51 -0400 (EDT)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
In-Reply-To: <Pine.GSO.4.10.9908102242360.6300-100000@ux02.CS.Princeton.EDU> from "David Slomin" at Aug 11, 99 01:04:52 am
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 68a74c84fbed39b62d64b42cbb10bf79

David Slomin wrote:
> > 3. Sequencers that only allow you to change a few controllers by GM name,
> > instead of all by number. Not everything, especially external stuff, works
> > according to GM (having all the XG controllers named is nice, though).
> 
> Agreed.  To me, a MIDI sequencer should handle raw MIDI.

The way I think, I'd prefer a music sequencer that handles abstract
time-structured data and maps it to MIDI.  For example, if I have some
wiggly control gesture, I don't want to record it as a stream of some
controller.  Because I _might_ want to map it to that controller, but I
might also want to apply it to attack velocity, note duration, whatever.
MIDI sequencers tend to think these are mutually incomprehensible sorts
of data, whereas I think they're all piecewise-constant one-dimensional
signals.

> That brings up a question... is it the job of the sequencer to decide how
> to order events with the same timestamp?  Should you honor the order they
> appeared in the file or came over the wire?  Should you leave it up to the
> user by adding "nudge" commands to the interface?

I would definitely respect ordering information that came from the file
or wire.  In the absence of that, it would be interesting to get clever
with ordering patch changes before controller events before note-ons,
etc.  But what's indispensable, IMO, is that whatever ordering is used
be predictable, visible, and modifiable.

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Fri Aug 13 01:46:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA03005
	for <slinkp@ulster.net>; Wed, 11 Aug 1999 16:36:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA03827 for linux-audio-dev-list; Wed, 11 Aug 1999 15:41:15 -0400
Received: from kaybee.org (kaybee.resnet.gatech.edu [128.61.15.250]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA03824 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 11 Aug 1999 15:41:12 -0400
Received: from localhost (rob@localhost)
	by kaybee.org (8.8.7/8.8.7) with ESMTP id PAA27128
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 11 Aug 1999 15:38:37 -0400
Date: Wed, 11 Aug 1999 15:38:37 -0400 (EDT)
From: rob <rob@kaybee.org>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] can't get any dropouts?
In-Reply-To: <199908111809.OAA03676@ginette.musique.umontreal.ca>
Message-ID: <Pine.LNX.4.10.9908111533010.27105-100000@kaybee.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e3676f1a5250335ef128d6c82a62a953

> A vanilla 2.2 installation has possibly the crummiest timing of any
> widely-used OS.  W98 has problems, oh yeah, but at least disk access
> doesn't hammer timing like this.  (Well, but the sliding menus do.)
> This issue deserves the attention it's now getting.
> 
> I wish I had the expertise to go through the kernel nailing RT bugs.
> The least I can do is help make a lot of noise so the work being done
> by others is noticed and maybe merged into the kernel eventually.

	the reason linux has crappy timing is because the kernel is
non-reenterant and can hold onto the processor for relatively long periods
of times servicing disk access, etc (iirc). 
	the rt problem on the other hand has already been solved by the
kids at the rtlinux project.  (it would be a huge pain to modify the
kernel itself to be reenterant which is why they didn't do that).  you can
get pretty near microsecond timing with some jitter.  the hard part is
that you don't have access to alot of the normal kernel services.
	basically everything is avialable in one form or another...rt
support, high-end audio cards, sequencer, daw stuff--it just needs to be
put together into a system, which is a quite complex software endeavor.

				rob 

---
Rob Melby
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
Internet: rob@kaybee.org, gt4255a@prism.gatech.edu

From - Fri Aug 13 01:46:07 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA10119
	for <slinkp@ulster.net>; Wed, 11 Aug 1999 17:22:37 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA03941 for linux-audio-dev-list; Wed, 11 Aug 1999 16:41:33 -0400
Received: from mustec.bgsu.edu (mustec.bgsu.edu [129.1.57.200]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA03938 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 11 Aug 1999 16:41:22 -0400
Received: from mustec.bgsu.edu (azygmun@mustec.bgsu.edu [129.1.57.200])
	by mustec.bgsu.edu (8.8.7/8.8.7) with ESMTP id QAA01556;
	Wed, 11 Aug 1999 16:38:42 -0400
Date: Wed, 11 Aug 1999 16:38:42 -0400 (EDT)
From: Adam Zygmunt <azygmun@bgnet.bgsu.edu>
X-Sender: azygmun@mustec.bgsu.edu
To: David Slomin <dgslomin@CS.Princeton.EDU>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MIDI question
In-Reply-To: <Pine.GSO.4.10.9908111250250.6068-100000@ux02.CS.Princeton.EDU>
Message-ID: <Pine.LNX.4.10.9908111412430.1488-100000@mustec.bgsu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 46a79ecb6874f324aaf1c5ac364acb0c



On Wed, 11 Aug 1999, David Slomin wrote:

> 
> So I'm working on my sequencer, reading over the MIDI specs, and I
> realize that I don't have a really clear understanding of how MIDI
> controller messages work.
> 
> I understand the simple case: coarse value adjust only of one of the
> base controllers (modulation, sustain, etc), which is sent in a single
> message.
> 
> What I'd like to how the other three cases work:
> 

I don't have my own synth manual with me right now (I'm at work and it's
at home), but I did some double-checking at www.midi.org. The way I
understand it is this:

All controls except pitch bend are coarse. Control change and pitch bend
are actually two different types of messages. Control change is of the
form Bx (hex) y z, where x is the MIDI channel, y is the controller
number, and z is the controller value (both 7-bit). Pitch bend is of the
form Ex l m, where x the channel, and l and m are the least- and
most-significant bytes, respectively. Both of these are also 7 bit, which
is a little weird.
    [N]RPN are actually just extensions to the controllers. As there are
only 127 available controllers, some of the more esoteric things have been
put here. I'm pretty sure (I'd have to double-check a manual to be
absolutely certian) that you use [N]RPN by sending three sequential
controller-type (Bx) messages. The first, 62 or 64 (hex), sets the RPN or
NRPN parameter number lsb. 63 or 65 sets the msb. controller 6 would then
set the value (coarse only). There are a couple of special controllers for
[N]RPN - 60 (increment) and 61(decrement) which can be used instead of 6,
though these seem a little unusual to me. To summarize, [N]RPNs are a way
of giving MIDI devices 32,000 controllers (2^14 RPNs+2^14 NRPNs), instead
of just 127. As they're all still fundamentally controllers, they still
only have 7 bits of resolution, though.

Hope this helps, and I'll post any corrections if I find any inaccuracies.

Adam Zygmunt

From - Fri Aug 13 01:46:21 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA05890
	for <slinkp@ulster.net>; Wed, 11 Aug 1999 21:02:32 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA04269 for linux-audio-dev-list; Wed, 11 Aug 1999 20:25:12 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA04266 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 11 Aug 1999 20:25:10 -0400
Received: from bright.net (find-cas2-cs-33.dial.bright.net [209.143.26.187])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id UAA15327;
	Wed, 11 Aug 1999 20:22:31 -0400 (EDT)
Message-ID: <37B2182F.2B5CC1C@bright.net>
Date: Wed, 11 Aug 1999 20:41:19 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Kai Vehmanen <kaiv@wakkanet.fi>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] My 2 cents (contd.)
References: <%Q5Ys38vA4@sculpcave>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: cc1dfe9e4764db6d3226291903e3a7de

Kai Vehmanen wrote:

> ...1.x -> 2.x is a big change in Qt.
> ...you still need
> to have Qt 1.xx runtime libs and include files.

I had some advance advice that that might be true, so I did rename the
older stuff to keep it separate from 2.00 while it installed. No harm
done, but I was prepared.
 
> Btw; Qt 2.x packages even include a script, which converts 1.x based
> source code to 2.x compatible code... So Trolltech really takes these
> things seriously.

Once again, I learn something new. I'll have to try that on something...

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Fri Aug 13 01:46:23 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA10731
	for <slinkp@ulster.net>; Wed, 11 Aug 1999 21:35:24 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA04308 for linux-audio-dev-list; Wed, 11 Aug 1999 21:01:50 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA04305 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 11 Aug 1999 21:01:47 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id UAA23579;
	Wed, 11 Aug 1999 20:57:23 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id UAA28181; Wed, 11 Aug 1999 20:57:22 -0400 (EDT)
Date: Wed, 11 Aug 1999 20:57:22 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: Adam Zygmunt <azygmun@bgnet.bgsu.edu>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MIDI question
In-Reply-To: <Pine.LNX.4.10.9908111412430.1488-100000@mustec.bgsu.edu>
Message-ID: <Pine.GSO.4.10.9908112017020.26468-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: cc9ddcf80381a7ab0a991e81b11489a1

On Wed, 11 Aug 1999, Adam Zygmunt wrote:

> All controls except pitch bend are coarse. Control change and pitch bend
> are actually two different types of messages. Control change is of the
> form Bx (hex) y z, where x is the MIDI channel, y is the controller
> number, and z is the controller value (both 7-bit). Pitch bend is of the
> form Ex l m, where x the channel, and l and m are the least- and
> most-significant bytes, respectively. Both of these are also 7 bit, which
> is a little weird.

I understand that pitch bend is not a controller in terms of MIDI,
although I tend to agree with another poster (forgive me for not checking
up on the name) who said that such similar things should be able to be
editted in a similar manner.  For that matter, aftertouch in its two forms
(note specific and channel-wide) is not considered a controller either.

What I'm referring to is that there are pairs of controller numbers for
many of the defined types of controllers.  For instance, controller number
1 sets the most significant 7 bits for the mod wheel, and controller
number 0x21 sets the least significant 7 bits for the mod wheel.  Older
and cheaper synthesizers will only send the first, allowing only a course
level of control, but the standard supports a full 14 bits of resolution,
spread across two messages.  At least, that's what it really looks like
from the spec; I wanted to make sure what limitations there were in terms
of order and intervening messages.

>     [N]RPN are actually just extensions to the controllers. As there are
> only 127 available controllers, some of the more esoteric things have been
> put here. I'm pretty sure (I'd have to double-check a manual to be
> absolutely certian) that you use [N]RPN by sending three sequential
> controller-type (Bx) messages. The first, 62 or 64 (hex), sets the RPN or
> NRPN parameter number lsb. 63 or 65 sets the msb. controller 6 would then
> set the value (coarse only). There are a couple of special controllers for
> [N]RPN - 60 (increment) and 61(decrement) which can be used instead of 6,
> though these seem a little unusual to me. To summarize, [N]RPNs are a way
> of giving MIDI devices 32,000 controllers (2^14 RPNs+2^14 NRPNs), instead
> of just 127. As they're all still fundamentally controllers, they still
> only have 7 bits of resolution, though.

This seems to coincide with the scattered documentation I found, all
except the 7 bit limit.  To send a value of 1234 (0x4D2) to RPN number
5678 (0x162E), I believe the sequence would be:

           / 0xB0 controller message on channel 1
message 1 <  0x64 RPN number LSB
           \ 0x2E bottom seven bits of 0x162E

           / 0xB0 controller message on channel 1
message 2 <  0x65 RPN number MSB
           \ 0x2C top seven bits of 0x162E

           / 0xB0 controller message on channel 1
message 3 <  0x26 data entry LSB
           \ 0x52 bottom seven bits of 0x4D2

           / 0xB0 controller message on channel 1
message 4 <  0x06 data entry MSB
           \ 0x09 top seven bits of 0x4D2

Notice the 14 bits of resolution in both the RPN number and the value to
which it is being set.  My questions were really:

1.  Can you reverse the order of 1 and 2, likewise 3 and 4, and still have
it be valid?  In other words, does MIDI really have an "endian"
preference?  (Not the IFF based SMF files, which definitely do, but the
wire messages themselves?)

2.  Is a sequence like 1, 2, 3, 4, 3, 4 valid, where you don't repeat the
RPN number?  This seems like it should be valid, because otherwise the
data increment and decrement controllers (0x60 and 0x61 respectively)
would be pretty inefficient, but then again I'm not sure.

3.  Can you leave out 4 so that the RPN number has 14 bits of resolution,
but the value to which it is set has only 7 bits, like with the "coarse"
versions of regular controllers?

This would be easy to test out if my synth actually sent or recognised
RPNs and fine-grained regular controllers, but unfortunately it is too old
for that.

Thanks for your help,
Div.

From - Fri Aug 13 01:46:25 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA15783
	for <slinkp@ulster.net>; Wed, 11 Aug 1999 22:07:44 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA04368 for linux-audio-dev-list; Wed, 11 Aug 1999 21:33:01 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA04365 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 11 Aug 1999 21:32:58 -0400
Received: from bright.net (find-cas2-cs-33.dial.bright.net [209.143.26.187])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id VAA17723;
	Wed, 11 Aug 1999 21:30:10 -0400 (EDT)
Message-ID: <37B2280B.181ADCFC@bright.net>
Date: Wed, 11 Aug 1999 21:48:59 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Guenter Geiger <geiger@epy.co.at>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Mix curiosity
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 4fdc4db73f86f321cb2df904b9feb70f

Greetings:

  While revising the Mix docs I came across the significance of the
csound variable. Apparently on an SGI machine it's possible to trigger a
Csound compilation with realtime audio output, along with any other
material in the track(s). I tried it, after editing the mix.c code a
bit, and indeed the Csound session initiates. Of course, it dies because
it can't access the soundcard.

  So I wondered: Is it at all possible to make that work in Linux Mix ?
I loaded the esound daemon, but playback froze and output no audio
anyway. I'd like to be able to do this trick: any suggestions ?

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Fri Aug 13 01:46:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA14047
	for <slinkp@ulster.net>; Wed, 11 Aug 1999 17:53:40 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA04011 for linux-audio-dev-list; Wed, 11 Aug 1999 17:14:55 -0400
Received: from chekov.Belgium.EU.net (chekov.belgium.eu.net [193.74.208.161]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA04008 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 11 Aug 1999 17:14:52 -0400
Received: from (adial065.liege.eunet.be [195.207.174.65])
	by chekov.Belgium.EU.net  with SMTP id XAA05079 
	for <linux-audio-dev@ginette.musique.umontreal.ca>;
	Wed, 11 Aug 1999 23:12:12 +0200 (MET DST)
Message-Id: <199908112112.XAA05079@chekov.Belgium.EU.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] can't get any dropouts?
Date: Wed, 11 Aug 1999 23:06:16 Set the time zone in the Time preference utility
From: "Benjamin GOLINVAUX" <golinvaux@benjamin.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1251"
Reply-To: golinvaux@benjamin.net
X-Mailer: BeOS Mail [R4.5.1]
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5119e7738040b8536955ffdf22cbecc2

>	basically everything is avialable in one form or another...rt
>support, high-end audio cards, sequencer, daw stuff--it just needs to 
be
>put together into a system, which is a quite complex software 
endeavor.

I would add that drivers are still lacking... Can you give me an 
example of a high-end
card that is fully supported under Linux ? I mean, with full duplex and 
every inputs and outputs working together (be it digital, analog or 
both) ?

And even if some drivers exist, they need to be rewritten for RTlinux.

It is a huge workload (if not impossible, being given how reluctant 
card manufacturers are to give away specs... really seem they are 
afraid to sell less cards if doing so...).

I know this is _not_ the place to advocate another OS, and I _love_ 
Linux open source model and stability. I'd dream to have my full suite 
of dev tools, modelers, and real-time 3D software under Linux but I 
switched to BeOS because I want to have good latency before I get too 
old ;-)

All the delicate timing kernel issues are being solved by BeOS R4(.5.1) 
and I think audio developers wanting to code audio stuff instead of 
drivers and kernel patches should try BeOS (furthermore, the GUI API is 
fantastic). 

I'm not pessimistic, I just say a good Linux evolution for audio will 
take a huge time to be available with decent drivers and... I don't 
want to wait anymore...

Good luck.

Benjamin GOLINVAUX

From - Fri Aug 13 01:46:31 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA13464
	for <slinkp@ulster.net>; Thu, 12 Aug 1999 11:07:36 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA05384 for linux-audio-dev-list; Thu, 12 Aug 1999 10:22:17 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA05381 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 12 Aug 1999 10:22:14 -0400
Received: from bright.net (find-cas1-cs-35.dial.bright.net [209.143.26.138])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id KAA26928;
	Thu, 12 Aug 1999 10:19:37 -0400 (EDT)
Message-ID: <37B2DC57.2973F2F0@bright.net>
Date: Thu, 12 Aug 1999 10:38:15 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] various nags
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: a9fa5a635fae95f99a6131058bde7919

Greetings:

  I'm still sifting through the various commentaries regarding the state
of Linux audio software. I'm beginning to make a provisional list of the
Most Important Things that need done. Here's where I'm at so far:

    Problem 1. We need a soundfile editor that can handle arbitrarily
large files.
    Solutions: Can any of the existing editors (MiXViews, DAP, Snd, etc)
be retrofitted for that capacity ? What would be involved ? Should the
attempt be skipped in favor of a whole new editor ? I agree with Adam
Zygmunt that this a very serious issue.

    Problem 2. We need to resolve issues of latency and dropouts caused
by system activity. It will make no difference how cool our software is
if dropouts kill its efficiency. Maybe I can get by with one or three
minute files now, but what will happen with my 20-minute pieces ?
    Solutions: RTLinux ? A customized kernel for audio ? Can we fix the
existing kernel to adapt to audio concerns ? It seems to me that this is
also a most important concern: has Alan Cox been apprised of its
significance ? The kernel developers must take note of this problem, and
audio should not be left as a sort of backwater concern. Put it out
front, don't let sound matters remain secondary or even tertiary
concerns in kernel development. And I'm not just talking about drivers
here ! ;)

    Problem 3. We need a good basic MIDI and/or audio sequencer.
    Solutions: Jazz++ ? Multitrack ? Something not yet seen ? Multitrack
is slated for open-source, but will it fit the need ? Jazz++ is not
open-source, but its developers may be responsive to suggestions
regarding its stability and use. Is there another project more deserving
of developers' focus ?

    Problem 4. There are perhaps too many projects undertaken and not
enough cooperation. IMO, we need to focus on the development of only a
few superlative applications instead of any number of private projects,
no matter how nice those projects may be. Without the larger-scale stuff
Linux will never be consider a serious audio development and composition
platform.
    Solutions: Make more project leaders aware of LAD and the Csound
UNIX/Linux Development group. Contact each other, write to start-up
project leaders, ask what their goals are, see whether we aren't
re-inventing the wheel. For instance, just how many audio and audiofile
libraries are out there now, but how many do we really need ? I should
think that one or two could provide all necessary services, provided its
design considers everything needed by common (or even uncommon) audio
applications.


  I have a pet project that I would like to see come to pass. I want to
make the NoTAM applications capable of handling large files, and I want
their feature sets to be completely working (especially in Mix). I would
have a pretty slick composition/processing environment with Csound,
Ceres, and Mix, but only if the issues of file size and record/playback
latency are resolved. Csound 3.57 is impressive enough already, but I'm
not sure Cecilia will work with it. Ceres and Mix have well-known
problems and they are being addressed, but I wonder whether they can be
fit to modern needs.

  Okay, just kicking things around here. As always, comments and
criticism are welcome...

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Fri Aug 13 01:46:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA19643
	for <slinkp@ulster.net>; Thu, 12 Aug 1999 11:52:31 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA05441 for linux-audio-dev-list; Thu, 12 Aug 1999 11:04:01 -0400
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id LAA05438 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 12 Aug 1999 11:03:58 -0400
Message-Id: <199908121503.LAA05438@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] can't get any dropouts?
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Thu, 12 Aug 1999 11:01:00 -0400 (EDT)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
In-Reply-To: <Pine.LNX.4.10.9908111533010.27105-100000@kaybee.org> from "rob" at Aug 11, 99 03:38:37 pm
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: dbbf4214db0be37857f346f381587027

rob wrote:
> 	the reason linux has crappy timing is because the kernel is
> non-reenterant and can hold onto the processor for relatively long periods
> of times servicing disk access, etc (iirc). 

Yeah, the IDE drivers are reported to be tools of the devil in this
respect.

> 	the rt problem on the other hand has already been solved by the
> kids at the rtlinux project.

But RTLinux doesn't do anything for Linux itself -- it's an RT monitor
that happens to run on the same machine as Linux.  As you say: no
protection, no system calls, bare-bone synch primitives, and you talk
to the Linux subprocess through the moral equivalent of a serial line.

Sure, people got a lot done under this sort of programming model back
in the Dark Ages, but I'm fond of running under an OS; it helps my
productivity.  Personally, I'd gladly trade off some average-case
speed to get Linux's worst case to the point where I could do
millisecond-range RT programming with POSIX RT under Linux proper.
For microsecond-range, yeah, my guess is that RTLinux is the right
way.

>  (it would be a huge pain to modify the
> kernel itself to be reenterant which is why they didn't do that).  

I bet the Linux-kernel community could muster up resources to match
the efforts of Sun or SGI or IBM, but it _would_ be a grievous pain in
the ass, and the idea would probably... not match Linus' aesthetic.

Rather than go all the way to preemptability, though, we can get some
mileage out of getting rid of too-long critical sections.  Uh, "`we'".

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Fri Aug 13 01:46:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA23826
	for <slinkp@ulster.net>; Thu, 12 Aug 1999 12:22:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA05534 for linux-audio-dev-list; Thu, 12 Aug 1999 11:39:46 -0400
Received: from kaybee.org (kaybee.resnet.gatech.edu [128.61.15.250]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA05531 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 12 Aug 1999 11:39:43 -0400
Received: from localhost (rob@localhost)
	by kaybee.org (8.8.7/8.8.7) with ESMTP id LAA02723;
	Thu, 12 Aug 1999 11:37:05 -0400
Date: Thu, 12 Aug 1999 11:37:05 -0400 (EDT)
From: rob <rob@kaybee.org>
To: Dave Phillips <dlphilp@bright.net>
cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] various nags
In-Reply-To: <37B2DC57.2973F2F0@bright.net>
Message-ID: <Pine.LNX.4.10.9908121107590.2541-100000@kaybee.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 12f3584ce55816dc72d08c4bf36b9d8b


	the ones you've mentioned cover pretty much all my major concerns.
problem one is relatively easy to implement.  the easiest least intrusive
way to do it i think would just be to allow editing via cut/play lists and
then have the editor apply those to create the final saved file. 
	the second issue is i think the most difficult and important.
linus et. al. have stated (iirc) that they don't really intend to cater
to every group  who wants a kernel feature added to make their lives
easier.  so we should make some noise at them but be prepared to do
without.  
	i think rtlinux is still the most promising.  audio drivers will
need to be written to live in the realtime part of the kernel, so the
available number of cards will be limited...on the other hand perhaps an
OSS boot can provide an enviroment that existing drivers can be added to
the real time level...ie we make the audio subsystem live in the rt
kernel, not the linux kernel.  
	we can then provide sample accurate feedback to the application as
to what the sound card is doing similar to sgi's implementation and can
put some scheduling capabilities on the realtime level to insure on time
delivery of events.  the biggest problem with this is that at least some
of the sequencing code has to live in the realtime code which is
inherhently dangerous.  on the other hand we could make a further hack
that allows timers and enforced scheduling to call an application's
callback to run.  the callback however would be limited in it's ability to
make system calls.  (is this an adequate compromise ?)
	perhaps all that need live in the rt level is a few timers which
will tell the linux scheduler what must be done "now"...this would require
a bit of kernel hacking but might be the cleanest way.  
	no matter what it will require a bit of study to figure out how to
best do this.   
 	that said, i would prefer to have a single decent digital IO card
supported and a single midi IO card, rather than alot of cheaper cards
available with questionable performance.  this is not the ideal situation,
but it seems more realistic in actually being accomplished.
	on a side note, i really want some usb interfaces to be supported
so that one could use a laptop alone to control synths and record...thats
what i really want. 
	anyway.
	harddrive interrupts may still have to be addressed (not for rt
support but because any daw system interacts heavily with the filesystem
and the audiosystem). 
	the final problems are less of a technical challenge and more of a
straightforward organizational effort and just basically sitting down to
write the code.  i'm sure we can still easily argue for days as to just
how to go about it.  

				rob		


On Thu, 12 Aug 1999, Dave Phillips wrote:
>     Problem 1. We need a soundfile editor that can handle arbitrarily
> large files.
>     Solutions: Can any of the existing editors (MiXViews, DAP, Snd, etc)
> be retrofitted for that capacity ? What would be involved ? Should the
> attempt be skipped in favor of a whole new editor ? I agree with Adam
> Zygmunt that this a very serious issue.
> 
>     Problem 2. We need to resolve issues of latency and dropouts caused
> by system activity. It will make no difference how cool our software is
> if dropouts kill its efficiency. Maybe I can get by with one or three
> minute files now, but what will happen with my 20-minute pieces ?
>     Solutions: RTLinux ? A customized kernel for audio ? Can we fix the
> existing kernel to adapt to audio concerns ? It seems to me that this is
> also a most important concern: has Alan Cox been apprised of its
> significance ? The kernel developers must take note of this problem, and
> audio should not be left as a sort of backwater concern. Put it out
> front, don't let sound matters remain secondary or even tertiary
> concerns in kernel development. And I'm not just talking about drivers
> here ! ;)
> 
>     Problem 3. We need a good basic MIDI and/or audio sequencer.
>     Solutions: Jazz++ ? Multitrack ? Something not yet seen ? Multitrack
> is slated for open-source, but will it fit the need ? Jazz++ is not
> open-source, but its developers may be responsive to suggestions
> regarding its stability and use. Is there another project more deserving
> of developers' focus ?
> 
>     Problem 4. There are perhaps too many projects undertaken and not
> enough cooperation. IMO, we need to focus on the development of only a
> few superlative applications instead of any number of private projects,
> no matter how nice those projects may be. Without the larger-scale stuff
> Linux will never be consider a serious audio development and composition
> platform.
>     Solutions: Make more project leaders aware of LAD and the Csound
> UNIX/Linux Development group. Contact each other, write to start-up
> project leaders, ask what their goals are, see whether we aren't
> re-inventing the wheel. For instance, just how many audio and audiofile
> libraries are out there now, but how many do we really need ? I should
> think that one or two could provide all necessary services, provided its
> design considers everything needed by common (or even uncommon) audio
> applications.
> 
> 
>   I have a pet project that I would like to see come to pass. I want to
> make the NoTAM applications capable of handling large files, and I want
> their feature sets to be completely working (especially in Mix). I would
> have a pretty slick composition/processing environment with Csound,
> Ceres, and Mix, but only if the issues of file size and record/playback
> latency are resolved. Csound 3.57 is impressive enough already, but I'm
> not sure Cecilia will work with it. Ceres and Mix have well-known
> problems and they are being addressed, but I wonder whether they can be
> fit to modern needs.
> 
>   Okay, just kicking things around here. As always, comments and
> criticism are welcome...
> 
> == Dave Phillips
> 
>        http://www.bright.net/~dlphilp/index.html
>    http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html
> 

Rob Melby
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
Internet: rob@kaybee.org, gt4255a@prism.gatech.edu

From - Fri Aug 13 01:46:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA23876
	for <slinkp@ulster.net>; Thu, 12 Aug 1999 12:22:38 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA05559 for linux-audio-dev-list; Thu, 12 Aug 1999 11:46:22 -0400
Received: from kaybee.org (kaybee.resnet.gatech.edu [128.61.15.250]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA05556 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 12 Aug 1999 11:46:19 -0400
Received: from localhost (rob@localhost)
	by kaybee.org (8.8.7/8.8.7) with ESMTP id LAA02749;
	Thu, 12 Aug 1999 11:43:42 -0400
Date: Thu, 12 Aug 1999 11:43:41 -0400 (EDT)
From: rob <rob@kaybee.org>
To: eli+@cs.cmu.edu
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] can't get any dropouts?
In-Reply-To: <199908121503.LAA05438@ginette.musique.umontreal.ca>
Message-ID: <Pine.LNX.4.10.9908121137591.2541-100000@kaybee.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3be93a45a67a5f4eb1cb26d357d69bc3

On Thu, 12 Aug 1999, Eli Brandt wrote:

> Yeah, the IDE drivers are reported to be tools of the devil in this
> respect.
> > 	the rt problem on the other hand has already been solved by the
> > kids at the rtlinux project.
> 
> But RTLinux doesn't do anything for Linux itself -- it's an RT monitor
> that happens to run on the same machine as Linux.  As you say: no
> protection, no system calls, bare-bone synch primitives, and you talk
> to the Linux subprocess through the moral equivalent of a serial line.


	perhaps only the basic stuff need be implemented on that level,
like yelling at the kernel to schedule something right this moment, or
something similar.  hack hack hack hack.

> I bet the Linux-kernel community could muster up resources to match
> the efforts of Sun or SGI or IBM, but it _would_ be a grievous pain in
> the ass, and the idea would probably... not match Linus' aesthetic.

	i agree with the concern that rtlinux is somewhat half-assed.  the
normal concern i hear is that because linux is developed by a community it
would be very hard to keep track of all the fine-grained locks which would
be required.
	i also agree that perhaps we can get good enough performance so
that we can stay in linux land.  i'm only interested that the final
product should work, be available sooner rather than later, and allow me
to use linux normally with most other stuff. 
	i don't care how it gets done, i just want to be able to write
music and record on linux.

				rob


---
Rob Melby
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
Internet: rob@kaybee.org, gt4255a@prism.gatech.edu

From - Fri Aug 13 01:46:37 1999
Received: from exeter.ac.uk (hermes.ex.ac.uk [144.173.6.14])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id MAA21509
	for <slinkp@ulster.net>; Thu, 12 Aug 1999 12:06:06 -0400
Received: from noether [144.173.8.10] by hermes via SMTP (QAA15239); Thu, 12 Aug 1999 16:53:05 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 12 Aug 1999 16:52:35 +0100
Received: from sparticus.bright.net [205.212.123.5] by hermes via ESMTP (QAA11240); Thu, 12 Aug 1999 16:52:34 +0100 (BST)
Received: from bright.net (find-cas1-cs-35.dial.bright.net [209.143.26.138])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id LAA10390;
	Thu, 12 Aug 1999 11:52:16 -0400 (EDT)
Message-ID: <37B2F20F.1F051AE0@bright.net>
Date: Thu, 12 Aug 1999 12:10:55 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Adam Zygmunt <azygmun@bgnet.bgsu.edu>, nicb@axnet.it,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>,
        Csound Linux Development Mail <csound-unix-dev@ilogic.com.au>,
        Csound Mail <csound@maths.ex.ac.uk>
Subject: unofficial-csound-3.57.0.0.a-linux.src.tar.gz now available
References: <Pine.LNX.4.10.9908121026110.1941-100000@mustec.bgsu.edu> <37B2EC8D.51F98516@bright.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 38670b45bb0d07ed47008e93d88030a3

Greetings:

  I have placed a source package for Csound 3.57.0.0a (unofficial) on
the server at BGSU. It can be found here:

	ftp://mustec.bgsu.edu/pub/linux

This is a *very* unofficial package, made by downloading the sources
prepared by Nicola Bernardini (from Csound.zip provided by John Fitch)
and running 'make src-distrib'. It includes all recent opcodes, and
realtime audio & MIDI appear to be working fine.

It is a source-only package. I have applied Steve Kersten's patch for
support of full-duplex audio using the OSS/Free and OSS/Linux drivers,
and it will show as a configuration option (--enable-OSS-RTAUDIO).

Many thanks to the fine coders who have contributed bug fixes, new
opcodes, and documentation. Great thanks also to John Fitch for
maintaining and providing the canonical sources to us all, and thanks
also to Nicola Bernardini for maintaining the unofficial version's CVS.
And of course, greatest thanks to Barry Vercoe for creating Csound and
giving it to the world.

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Fri Aug 13 01:46:47 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA26068
	for <slinkp@ulster.net>; Thu, 12 Aug 1999 16:38:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA05945 for linux-audio-dev-list; Thu, 12 Aug 1999 15:54:47 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA05942 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 12 Aug 1999 15:54:43 -0400
From: est@hyperreal.org
Received: (qmail 29075 invoked by uid 162); 12 Aug 1999 19:52:07 -0000
Message-ID: <19990812195207.29074.qmail@hyperreal.org>
Subject: [linux-audio-dev] IDEvil?
In-Reply-To: <199908121503.LAA05438@ginette.musique.umontreal.ca> from Eli Brandt
 at "Aug 12, 1999 11:01:00 am"
To: eli+@cs.cmu.edu
Date: Thu, 12 Aug 1999 12:52:07 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: f1eae56e3ff78f9e099e1d891607c174

Eli Brandt discourseth:
> rob wrote:
> > 	the reason linux has crappy timing is because the kernel is
> > non-reenterant and can hold onto the processor for relatively long periods
> > of times servicing disk access, etc (iirc). 
> 
> Yeah, the IDE drivers are reported to be tools of the devil in this
> respect.

I used to think so, but lots of recent testing has convinced me that
this needn't be the case as long as DMA is supported for both your
drive and IDE chipset.

Eric

From - Fri Aug 13 01:46:54 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA24255
	for <slinkp@ulster.net>; Fri, 13 Aug 1999 01:22:49 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA06778 for linux-audio-dev-list; Fri, 13 Aug 1999 00:47:23 -0400
Received: from mustec.bgsu.edu (mustec.bgsu.edu [129.1.57.200]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA06775 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 13 Aug 1999 00:47:20 -0400
Received: from mustec.bgsu.edu (azygmun@mustec.bgsu.edu [129.1.57.200])
	by mustec.bgsu.edu (8.8.7/8.8.7) with ESMTP id AAA02529;
	Fri, 13 Aug 1999 00:45:10 -0400
Date: Fri, 13 Aug 1999 00:45:10 -0400 (EDT)
From: Adam Zygmunt <azygmun@bgnet.bgsu.edu>
X-Sender: azygmun@mustec.bgsu.edu
To: David Slomin <dgslomin@CS.Princeton.EDU>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MIDI question
In-Reply-To: <Pine.GSO.4.10.9908112017020.26468-100000@ux02.CS.Princeton.EDU>
Message-ID: <Pine.LNX.4.10.9908130009120.2515-100000@mustec.bgsu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ca2e22e44f3de0b4c06182309b047f6b



On Wed, 11 Aug 1999, David Slomin wrote:

> On Wed, 11 Aug 1999, Adam Zygmunt wrote:
> 
> What I'm referring to is that there are pairs of controller numbers for
> many of the defined types of controllers.  For instance, controller number
> 1 sets the most significant 7 bits for the mod wheel, and controller
> number 0x21 sets the least significant 7 bits for the mod wheel.  Older
> and cheaper synthesizers will only send the first, allowing only a course
> level of control, but the standard supports a full 14 bits of resolution,
> spread across two messages.  At least, that's what it really looks like
> from the spec; I wanted to make sure what limitations there were in terms
> of order and intervening messages.
> 
> 
> This seems to coincide with the scattered documentation I found, all
> except the 7 bit limit.  To send a value of 1234 (0x4D2) to RPN number
> 5678 (0x162E), I believe the sequence would be:

This is true. I was mistaken here. [N]RPNs ARE 14-bit, with controller 6
being MSB and 26 being LSB. In my keyboard, though (Yamaha CS1x), the only
RPN that actually uses all 14 bits is fine tuning, and none of its NRPNs
do. The fine-tuned mod wheel, though, is currently unofficial in all the
sources I checked (midi.org, harmony-central controller list, and my own
manual). Since all the 14-bit stuff works basically the same, though, it
should be okay to treat controller 21 as "optional" like [N]RPN data 26.

> 1.  Can you reverse the order of 1 and 2, likewise 3 and 4, and still have
> it be valid?  In other words, does MIDI really have an "endian"
> preference?  (Not the IFF based SMF files, which definitely do, but the
> wire messages themselves?)

I would think so (but I'm just guessing here). My keyboard's manual
doesn't seem to be very picky about the order for 1 and 2 (different
orders and different places). It doesn't specifically say about the data
values, which leads me to believe that it's not critical either.
Personally, I would send the MSB first for data, because the LSB is used
so rarely.

> 2.  Is a sequence like 1, 2, 3, 4, 3, 4 valid, where you don't repeat the
> RPN number?  This seems like it should be valid, because otherwise the
> data increment and decrement controllers (0x60 and 0x61 respectively)
> would be pretty inefficient, but then again I'm not sure.

No idea. I would see about MMA's official printed specs on this one for
the gospel truth, or at least try to find some really good examples
somewhere. Beta testers wouldn't hurt, either.

> 3.  Can you leave out 4 so that the RPN number has 14 bits of resolution,
> but the value to which it is set has only 7 bits, like with the "coarse"
> versions of regular controllers?

Yes. (something certain!) The examples in the brief MIDI tutorial at
midi.org don't even mention the LSB data value or controller in the text,
only in the controller list.

> This would be easy to test out if my synth actually sent or recognised
> RPNs and fine-grained regular controllers, but unfortunately it is too old
> for that.
>
> Thanks for your help,
> Div.
> 
No problem. Good luck!

Adam Zygmunt


From - Fri Aug 13 02:35:59 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id CAA29863
	for <slinkp@ulster.net>; Fri, 13 Aug 1999 02:39:33 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id CAA06890 for linux-audio-dev-list; Fri, 13 Aug 1999 02:05:26 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA06887 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 13 Aug 1999 02:05:23 -0400
Received: from ulster.net (port21.king.ulster.net [208.242.160.22])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id CAA28690;
	Fri, 13 Aug 1999 02:15:30 -0400
Message-ID: <37B3B688.817BC57A@ulster.net>
Date: Fri, 13 Aug 1999 02:09:12 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: rob <rob@kaybee.org>
CC: Dave Phillips <dlphilp@bright.net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] various nags
References: <Pine.LNX.4.10.9908121107590.2541-100000@kaybee.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 76ff496f3e0350174282c8ad7565a492

rob wrote:
> 
>         the ones you've mentioned cover pretty much all my major concerns.
> problem one is relatively easy to implement.  the easiest least intrusive
> way to do it i think would just be to allow editing via cut/play lists and
> then have the editor apply those to create the final saved file.

Sounds good. Another trick used by Cool Edit and probably others, to
speed up the time it takes to open a large file, is to store the data
for the display as a separate file, rather than always calculating it
on-the-fly. Of course, if the soundfile has a more recent modification
time than the display datafile, or if the display file doesn't exist, it
needs to be created anyway... so you don't gain all THAT much this way.

>         on a side note, i really want some usb interfaces to be supported
> so that one could use a laptop alone to control synths and record...thats
> what i really want.

Me too!

--PW

From - Sat Aug 14 12:54:54 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA09266
	for <slinkp@ulster.net>; Fri, 13 Aug 1999 07:19:13 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA07364 for linux-audio-dev-list; Fri, 13 Aug 1999 06:34:17 -0400
Received: from deimos.worldonline.nl (deimos.worldonline.nl [195.241.48.136]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA07361 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 13 Aug 1999 06:34:14 -0400
Received: from orion.worldonline.nl (orion.worldonline.nl [195.241.48.133])
	by deimos.worldonline.nl (8.8.5/8.8.5) with ESMTP id MAA14323;
	Fri, 13 Aug 1999 12:31:34 +0200 (MET DST)
Received: from shark (vp233-215.worldonline.nl [195.241.233.215])
	by orion.worldonline.nl (8.8.5/8.8.5) with SMTP id MAA02217;
	Fri, 13 Aug 1999 12:31:33 +0200 (MET DST)
Message-ID: <002a01bee577$11937d20$0200a8c0@shark>
From: "Henk Slager" <hslager@worldonline.nl>
To: <est@hyperreal.org>, <eli+@cs.cmu.edu>
Cc: <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] IDEvil?
Date: Fri, 13 Aug 1999 12:31:56 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3007.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3007.0
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 9256201ab889caefa91d71d768fa835c

>Eli Brandt discourseth:
>> rob wrote:
>> > the reason linux has crappy timing is because the kernel is
>> > non-reenterant and can hold onto the processor for relatively long
periods
>> > of times servicing disk access, etc (iirc).
>>
>> Yeah, the IDE drivers are reported to be tools of the devil in this
>> respect.
>
>I used to think so, but lots of recent testing has convinced me that
>this needn't be the case as long as DMA is supported for both your
>drive and IDE chipset.
>
>Eric


I experienced the opposite. If I use PIO for HD transfers, then no gaps are
in the sound stream. With DMA (DMA mode 2 or UDMA33 ?), all HD transfers
hold the sound sample stream. This is with SuSE 6.1, EPoX MB + AMDK6-2,
DiamondMAX HD, SB16 VE (Vibra16 chip) and OSS driver. Under W9x the same
happens. I think the VIA MVP3 chipset in combination with the 8-bit DMA only
transfers of the Vibra16 chip is the bottleneck.
An Intel Endeavor P133 (SB16 onboard, SuSE 6.1 ) does not have this
problems.


From - Sat Aug 14 12:54:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA26958
	for <slinkp@ulster.net>; Fri, 13 Aug 1999 10:11:28 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA07580 for linux-audio-dev-list; Fri, 13 Aug 1999 09:34:08 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id JAA07577 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 13 Aug 1999 09:34:04 -0400
From: est@hyperreal.org
Received: (qmail 13516 invoked by uid 162); 13 Aug 1999 13:31:28 -0000
Message-ID: <19990813133128.13515.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] IDEvil?
In-Reply-To: <002a01bee577$11937d20$0200a8c0@shark> from Henk Slager at "Aug
 13, 1999 12:31:56 pm"
To: Henk Slager <hslager@worldonline.nl>
Date: Fri, 13 Aug 1999 06:31:28 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 96081311a436d81e60152007d39bdefd

Henk Slager discourseth:
> >>
> >> Yeah, the IDE drivers are reported to be tools of the devil in this
> >> respect.
> >
> >I used to think so, but lots of recent testing has convinced me that
> >this needn't be the case as long as DMA is supported for both your
> >drive and IDE chipset.
> 
> I experienced the opposite. If I use PIO for HD transfers, then no gaps are
> in the sound stream. With DMA (DMA mode 2 or UDMA33 ?), all HD transfers
> hold the sound sample stream. This is with SuSE 6.1, EPoX MB + AMDK6-2,
> DiamondMAX HD, SB16 VE (Vibra16 chip) and OSS driver. Under W9x the same
> happens. I think the VIA MVP3 chipset in combination with the 8-bit DMA only
> transfers of the Vibra16 chip is the bottleneck.

Hmm, could you send more specs on your hd and/or the output of hdparm
-i on it?  It would be nice if we could come up with easy distinctions
for buyers.

E

From - Sat Aug 14 12:55:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id DAA10062
	for <slinkp@ulster.net>; Sat, 14 Aug 1999 03:28:15 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id CAA08987 for linux-audio-dev-list; Sat, 14 Aug 1999 02:40:20 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA08984 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 14 Aug 1999 02:40:16 -0400
Received: from debian (d212-151-250-88.swipnet.se [212.151.250.88]) 
          by mb05.swip.net (8.8.8/8.8.8) with ESMTP 
          id IAA18439; 
          Sat, 14 Aug 1999 08:37:31 +0200 (MET DST)
Received: from debian.mbox314.swipnet.se (really [127.0.0.1]) by debian
	via in.smtpd with esmtp (ident root using rfc1413)
	id <m11FMa7-0017qzC@debian> (Debian Smail3.2.0.101)
	for <dlphilp@bright.net>; Fri, 13 Aug 1999 21:01:35 +0200 (CEST) 
Message-Id: <m11FMa7-0017qzC@debian>
Date: Fri, 13 Aug 1999 21:01:28 +0200 (CEST)
From: reine@mbox314.swipnet.se
Reply-To: reine@mbox314.swipnet.se
Subject: [linux-audio-dev] Re: Mix update
To: geiger@epy.co.at
cc: dlphilp@bright.net, linux-audio-dev@ginette.musique.umontreal.ca
In-Reply-To: <23942.54164.238395.909191@gige>
MIME-Version: 1.0
Content-Type: TEXT/plain; CHARSET=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 453051328f7405e01e99a908d6c73b39

On 22 Sep, Guenter Geiger wrote:
> Dave Phillips writes:
>  > Greetings:
>  > 
>  >   I added Reine's code to my copy here of Guenter's sources, everything
>  > seems to work fine. Should it go in as a fixture ?
>  > 
>  >   A few more observations:
>  > 
>  > 	1. The mixed file (track 10) is drawn rather poorly on my machine, with
>  > no x axis visible. Reine, didn't you fix that once before ?
>  > 
Can't really remember what i did. As i don't know anything about motif
i guess not. I added a ",0);" an extra zero argument on two places
to make it compile (or was it not to "segment fault").

Reine

From - Sat Aug 14 12:55:03 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA21159
	for <slinkp@ulster.net>; Fri, 13 Aug 1999 17:18:47 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA08270 for linux-audio-dev-list; Fri, 13 Aug 1999 16:34:47 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA08267 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 13 Aug 1999 16:34:43 -0400
Received: from bright.net (find-cas2-cs-50.dial.bright.net [209.143.26.204])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id QAA07383;
	Fri, 13 Aug 1999 16:32:08 -0400 (EDT)
Message-ID: <37B48520.F585FCE3@bright.net>
Date: Fri, 13 Aug 1999 16:50:40 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Snd and file sizes
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: fef608693091fce28e02fc8d9c4261b8

Greetings:

  Just to correct my mistake, here's a response from Bill Schottstaedt
regarding Snd:

  "Snd can handle any size file already, and has from the beginning. It
also has elaborate support for edit lists."

  If I could get the Listener working with LessTif I'd be able to check
out the extensibility features too. Anyone have any experience with
Listener ? Any advice on getting it work here ?

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Sat Aug 14 12:55:11 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA32226
	for <slinkp@ulster.net>; Fri, 13 Aug 1999 18:50:03 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA08447 for linux-audio-dev-list; Fri, 13 Aug 1999 18:09:55 -0400
Received: from gate.fzi.de (gate.fzi.de [141.21.4.3]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id SAA08444 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 13 Aug 1999 18:09:52 -0400
Received: from prost1.fzi.de by gate.fzi.de with SMTP (PP);
          Sat, 14 Aug 1999 00:07:17 +0200
Received: from fzi.de by prost1.fzi.de id <02443-0@prost1.fzi.de>;
          Sat, 14 Aug 1999 00:07:11 +0200
Subject: Re: [linux-audio-dev] can't get any dropouts?
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Sat, 14 Aug 1999 00:07:10 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL2]
Content-Type: text
From: Stefan Nitschke <nitschke@fzi.de>
Message-ID: <"prost1.fzi.640:13.08.99.22.07.14"@fzi.de>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 818fcb41705b0ddf11911909238315e2


> Adam Zygmunt discourseth:
> > 
> > > If you want to generate dropouts in RTSynth, try running top at the
> > > same time.  You'll also find out RTSynth's processor load. :)  You can
> > > also try creating a 200M file (head -c 200000000 /dev/zero >tmpfile)
> > > while RTSynth is running.  Deleting the file is probably even more
> > > likely to cause dropouts.
> > 
> > Not to be snotty, but this reminds me of the old joke, "Doctor, it hurts
> > when I do this." "So don't do that!"
> 
> Well, the point of such experiments is to realize that even though you
> haven't heard any dropouts yet, it's because you've been lucky.  Do
> you want to count on continuing to be lucky (going into single-user
> mode helps), or do you want reliability and convenience?
> 
> Eric
> 
I was offline for some days... 
Seems that i am a lucky man. I have scsi drives and no agp graphic card
and can run a rt application together with wmmon,wmtime,... and some
other programs without any problems. I also tried running RTsynth
and several gcc's compiling some stuff. This results in a system load
of over 6 and still have no audio dropouts.
I have not yet tested large files, no space on my drives to do some
harddsic recording. Do profesionals use a PC for harddisk recording??
On the other hand: Linux is not a RT-multimedia system so I never
tried to run a software synth together with e.g. a video streamer
and did never expect that this will work... if Linux will become 
a real RT-system some day. ..

- Stefan

From - Sat Aug 14 12:55:12 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA04955
	for <slinkp@ulster.net>; Fri, 13 Aug 1999 19:39:53 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA08513 for linux-audio-dev-list; Fri, 13 Aug 1999 18:59:41 -0400
Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA08510 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 13 Aug 1999 18:59:37 -0400
Received: from hendrix (krusty85.zip.com.au [61.8.16.117])
	by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id IAA25220
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 14 Aug 1999 08:47:09 +1000 (EST)
Message-ID: <37B4A2B8.1F7AF433@zip.com.au>
Date: Sat, 14 Aug 1999 08:56:56 +1000
From: Erik de Castro Lopo <erikd@zip.com.au>
Organization: Eric Conspiracy Secret Labs
X-Mailer: Mozilla 3.04Gold (X11; I; Linux 2.2.11 i586)
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] can't get any dropouts?
References: <"prost1.fzi.640:13.08.99.22.07.14"@fzi.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4b2500a04fc0bdfa30b0f69deb3d312f

Stefan Nitschke wrote:
> I was offline for some days...
> Seems that i am a lucky man. I have scsi drives and no agp graphic card
> and can run a rt application together with wmmon,wmtime,... and some
> other programs without any problems. I also tried running RTsynth
> and several gcc's compiling some stuff. This results in a system load
> of over 6 and still have no audio dropouts.
> I have not yet tested large files, no space on my drives to do some
> harddsic recording. Do profesionals use a PC for harddisk recording??

There are a number of PC based harddisk recording systems. I think
most of them recommend the use of SCSI disks for audio data. IDE
drives are find for the OS and programs themselves but not the
data which requires low latency access.

> On the other hand: Linux is not a RT-multimedia system 

Neither is windows but it is being used as such. 

> so I never
> tried to run a software synth together with e.g. a video streamer
> and did never expect that this will work... if Linux will become
> a real RT-system some day. ..

I seem to remember hearing that improved RT response was one of
the things Linus was hoping for with version 3.0

Erik
-- 
+-------------------------------------------------+
     Erik de Castro Lopo     erikd@zip.com.au
+-------------------------------------------------+
Complex problems have simple easy to understand wrong answers.

From - Sun Aug 15 15:09:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA27243
	for <slinkp@ulster.net>; Sun, 15 Aug 1999 14:31:36 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA11622 for linux-audio-dev-list; Sun, 15 Aug 1999 13:49:28 -0400
Received: from ax-nicb.axnet.it (ax-nicb.axnet.it [194.184.60.149]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA11619 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 15 Aug 1999 13:49:11 -0400
Received: (from nicb@localhost)
	by ax-nicb.axnet.it (8.8.7/8.8.7) id KAA13306;
	Sun, 15 Aug 1999 10:34:36 +0200
Date: Sun, 15 Aug 1999 10:34:36 +0200 (CEST)
From: Nicola Bernardini <nicb@axnet.it>
To: rob <rob@kaybee.org>
cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] various nags
In-Reply-To: <Pine.LNX.4.10.9908121107590.2541-100000@kaybee.org>
Message-ID: <Pine.LNX.4.10.9908151032520.212-100000@ax-nicb.axnet.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: bc0670aae4c10812bbc0abc0386d63be

Thursday, rob mi scrisse cio` che segue:

[snip]
rob> 	on a side note, i really want some usb interfaces to be supported
rob> so that one could use a laptop alone to control synths and record...thats
rob> what i really want. 

speaking of which, does anybody know of multitrack/digital audio USB
interfaces other than the opcode ones? I'd be really interested in
getting one...

ciao

nicb

------------------------------------------------------------------------
Nicola Bernardini
E-mail: nicb@axnet.it
 
Re graphics: A picture is worth 10K words -- but only those to describe
the picture.  Hardly any sets of 10K words can be adequately described
with pictures.

From - Sun Aug 15 15:09:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA27546
	for <slinkp@ulster.net>; Sun, 15 Aug 1999 14:34:41 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA11626 for linux-audio-dev-list; Sun, 15 Aug 1999 13:49:49 -0400
Received: from ax-nicb.axnet.it (ax-nicb.axnet.it [194.184.60.149]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA11623 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 15 Aug 1999 13:49:38 -0400
Received: (from nicb@localhost)
	by ax-nicb.axnet.it (8.8.7/8.8.7) id LAA13599;
	Sun, 15 Aug 1999 11:25:55 +0200
Date: Sun, 15 Aug 1999 11:25:55 +0200 (CEST)
From: Nicola Bernardini <nicb@axnet.it>
To: Linux Audio Development Mailing list <linux-audio-dev@ginette.musique.umontreal.ca>
cc: Guenter Geiger <geiger@iem.mhsg.ac.at>, Dave Phillips <dlphilp@bright.net>
Subject: [linux-audio-dev] a late reply to the 'What do we need now' thread...
In-Reply-To: <37B48520.F585FCE3@bright.net>
Message-ID: <Pine.LNX.4.10.9908151100310.212-100000@ax-nicb.axnet.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 1355f489dd5abebdf2b79f111eedaeca

Dear all,

sorry to be so late on the 'What we need now' thread... I felt that
everything was being said so no need for further comments. I really
agree with everything and really appreciated the work Dave is doing
to try and keep all of us together - a really important job.

Just a couple of comments:

1) I tried Mix - though still growing and with a lot to do, it is *really*
   impressive; I urge all those that have'nt tried it yet to try it.
   I can see that something like this could quickly become very useful
   to many of us (sort of a linux pro-tools, if I may say so). Another
   great job of Dr.Hammer, with impressive add-ons from Guenter Geiger
   and Reine (?). I think that all of us who can collaborate on this
   project should try to. On my side, I can do the usual autoconf routine
   (which I did for unofficial csound - and maybe a little better since
   I learned how to do it :) and set up a cvs repository for it (towards
   the end of august, though) if it's deemed necessary. And by the
   end of september I should be a little freer to contribute more
   specific code... (please don't flame me for discovering mix *only* now...)

2) among all the difficult things we should do (like convincing hardware
   manufacturers that, like open source, open hardware *is* better),
   there's a fairly easy one we should try: converge on 'the' sound
   library for linux, retrofit all applications with it, and maintain
   it as a separate entity so that all application may enjoy free upgrades
   as we upgrade the library. Among the many excellent ones I've seen
   around, currently I feel that Bill Schottstaedt's is the one we should
   go with for several reasons: a) it's simple (or at least it *looks*
   simple, which is even better); b) it's documented; c) it covers pretty
   much basic 'pro' features already (unlimited file length, buffering,
   audio hardware independent handling, etc.). The library is lacking
   a proper Makefile and autoconf features, so again, if Bill agrees
   or does'nt want to do it himself I can offer my help to build these
   files and also a cvs repository for it (at the end of august).

More small comments.

Sep 2019!, Guenter Geiger mi scrisse cio` che segue:

[snip - using the csound feature in Mix]
>  >   So I wondered: Is it at all possible to make that work in Linux Mix ?
>  > I loaded the esound daemon, but playback froze and output no audio
>  > anyway. I'd like to be able to do this trick: any suggestions ?
> 
>  IMO It's not easy without changing csound sources.
>  I don't see the usefulness of this feature either, as the result of
>  the csound session won't be saved in the resulting mix.

I personally think that this could be *extremely* useful: use
csound as a plug-in effect to modify tracks in Mix! can you imagine?
I think we just need to think it over a little bit, and perhaps the
result could be *much* better that what we expect.

Friday, Dave Phillips mi scrisse cio` che segue:

[snip]
>   Just to correct my mistake, here's a response from Bill Schottstaedt
> regarding Snd:
> 
>   "Snd can handle any size file already, and has from the beginning. It
> also has elaborate support for edit lists."

Right. And Snd uses sndlib...

I apologize for the time taken...
ciao

nicb
------------------------------------------------------------------------
Nicola Bernardini
E-mail: nicb@axnet.it
 
Re graphics: A picture is worth 10K words -- but only those to describe
the picture.  Hardly any sets of 10K words can be adequately described
with pictures.


From - Mon Aug 16 01:19:36 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA14942
	for <slinkp@ulster.net>; Sun, 15 Aug 1999 18:03:37 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA11828 for linux-audio-dev-list; Sun, 15 Aug 1999 17:25:45 -0400
Received: from anime.net (anime.net [205.139.105.150]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA11825 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 15 Aug 1999 17:25:41 -0400
Received: from localhost (goemon@localhost)
	by anime.net (8.9.3/8.9.3) with ESMTP id OAA06300;
	Sun, 15 Aug 1999 14:22:42 -0700
Date: Sun, 15 Aug 1999 14:22:42 -0700 (PDT)
From: Dan Hollis <goemon@sasami.anime.net>
X-Sender: goemon@anime.net
To: Nicola Bernardini <nicb@axnet.it>
cc: rob <rob@kaybee.org>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] various nags
In-Reply-To: <Pine.LNX.4.10.9908151032520.212-100000@ax-nicb.axnet.it>
Message-ID: <Pine.LNX.4.10.9908151416250.6255-100000@anime.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3a40b534d649b174c036d75e15537090

On Sun, 15 Aug 1999, Nicola Bernardini wrote:
> speaking of which, does anybody know of multitrack/digital audio USB
> interfaces other than the opcode ones? I'd be really interested in
> getting one...

Here are a few very interesting ones:

http://www.edirol.com/music_equipment/usb_audio_products/ua100/ua100order.html
http://www.canopus.co.jp/english/catalog/daport/daport.htm

The DA-PORT is a *very* interesting device! Dual TOSlink in/out, minijack,
and can record/playback mp3 in realtime. It also has Yamaha XG midi
engine. Street price is about Y21500 = ~$185USD. Very cheap!

-Dan

From - Mon Aug 16 01:19:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA17951
	for <slinkp@ulster.net>; Sun, 15 Aug 1999 18:36:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA11876 for linux-audio-dev-list; Sun, 15 Aug 1999 17:57:09 -0400
Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA11873 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 15 Aug 1999 17:57:05 -0400
Received: from hendrix (scratchy17.zip.com.au [61.8.12.145])
	by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id HAA01756
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 16 Aug 1999 07:44:21 +1000 (EST)
Message-ID: <37B735A3.69D98761@zip.com.au>
Date: Mon, 16 Aug 1999 07:54:22 +1000
From: Erik de Castro Lopo <erikd@zip.com.au>
Organization: Eric Conspiracy Secret Labs
X-Mailer: Mozilla 3.04Gold (X11; I; Linux 2.2.11 i586)
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: Nicola Bernardini's sound file library comments
References: <Pine.LNX.4.10.9908151100310.212-100000@ax-nicb.axnet.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 15552c838eeb750ff1603530b28e4327

Nicola Bernardini wrote:

<snip>

> 2) among all the difficult things we should do (like convincing hardware
>    manufacturers that, like open source, open hardware *is* better),
>    there's a fairly easy one we should try: converge on 'the' sound
>    library for linux, retrofit all applications with it, and maintain
>    it as a separate entity so that all application may enjoy free upgrades
>    as we upgrade the library. Among the many excellent ones I've seen
>    around, currently I feel that Bill Schottstaedt's is the one we should
>    go with for several reasons: a) it's simple (or at least it *looks*
>    simple, which is even better); b) it's documented; c) it covers pretty
>    much basic 'pro' features already (unlimited file length, buffering,
>    audio hardware independent handling, etc.). The library is lacking
>    a proper Makefile and autoconf features, so again, if Bill agrees
>    or does'nt want to do it himself I can offer my help to build these
>    files and also a cvs repository for it (at the end of august).

I will first off state that I am the author an audio file reading/writing
library which competes with Bill Schottstaedt's sndlib. Have a look at

    http://www.zip.com.au/~erikd/libsndfile/

Like sndlib, libsndfile already has points a, b and c above covered. For
libsndfile documentation have a look at 

    http://www.zip.com.au/~erikd/libsndfile/api.html

In my personal opinion I think sndlib has some weaknesses in comparision
to my own library that can be enumerated as follows :

1) sndlib looks as if it hasn't been worked on for a number of years
   while libsndfile is still under active development
2) sndlib needs to have automake/autoconf support added while libsndfile
   already has it
3) libsndfile has more comprehensive error reporting
4) libsndfile has thorough regression tests (distributed with the library)
   of nearly all library functionality

Some of the features that make libsndfile attractive are :

1) An interface is designed to limit name space pollution. All libsndfile
   functions are named sf_* and all constants are named SF_*
2) The ability to read the audio data as shorts, ints and doubles. For
   instance, once a file has been opened the data may be read using any
   combination of sf_read_short (), sf_read_int () or sf_read_double 
   depending on what the user wishes to do with the data. At the moment 
   there are some small inconsistencies with scaling of audio data (ie 
   reading a 24-bit WAV file using sf_read_short()) but these will be fixed 
   in the very near future.

As I stated above libsndfile is currently under development. Some of the
things I am working on at the moment are :

1) improved (and configuable) control of scaling on read/write
2) ability to read from / write to a pipe
3) sample rate convert on read (ie open a file, see that it is not the 
   desired sample rate, call something like sf_set_samplerate (), then 
   read data at the correct sample rate using the normal read functions.
4) support for Ensoniq PARIS (digital audio workstation) 16 and 24 bit 
   file formats and Amiga 8SVX and 16SV file formats.
5) support for IMA ADPCM encoded AIFF files

This "currently under development" status I think is the libsndfile's
greatest strength. libsndfile was started in December last year and 
in my opinion has progressed at an amazing pace. Up until now, nobody
else has contibuted code (other than small bug fixes) but I am more 
than willing for this to happen.

Cheers,
Erik
-- 
+-------------------------------------------------+
     Erik de Castro Lopo     erikd@zip.com.au
+-------------------------------------------------+
"I think there is a world market for maybe five computers." 
 -- Thomas Watson, Chairman of IBM, 1943

From - Mon Aug 16 01:19:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA24324
	for <slinkp@ulster.net>; Sun, 15 Aug 1999 19:37:52 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA11957 for linux-audio-dev-list; Sun, 15 Aug 1999 19:04:47 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id TAA11954 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 15 Aug 1999 19:04:42 -0400
From: est@hyperreal.org
Received: (qmail 9729 invoked by uid 162); 15 Aug 1999 23:02:07 -0000
Message-ID: <19990815230207.9728.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] Re: Nicola Bernardini's sound file library comments
In-Reply-To: <37B735A3.69D98761@zip.com.au> from Erik de Castro Lopo at "Aug
 16, 1999 07:54:22 am"
To: Erik de Castro Lopo <erikd@zip.com.au>
Date: Sun, 15 Aug 1999 16:02:07 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Eric-Conspiracy: `e'-in-the-triangle
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 67f8e49db468d464d5331ed61c63e227

Erik de Castro Lopo discourseth:

OK, Bruce. :)

> 
> 3) libsndfile has more comprehensive error reporting

That may be an area where it's superior to libaudiofile as well.  Much
of the error checking of the latter seems to be burried in assert()
statements!

Is libsndfile reentrant?

What reasons are there for prefering it over libaudiofile given the
momentum behind the latter?

> 1) An interface is designed to limit name space pollution. All libsndfile
>    functions are named sf_* and all constants are named SF_*

You might want to have an option to build a C++ version which actually
uses its own C++ namespace.

> 3) sample rate convert on read (ie open a file, see that it is not the 
>    desired sample rate, call something like sf_set_samplerate (), then 
>    read data at the correct sample rate using the normal read functions.

Feel free to rip resampling out of oolaboola. :)

Eric

From - Mon Aug 16 01:19:44 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA24918
	for <slinkp@ulster.net>; Sun, 15 Aug 1999 19:43:51 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA11973 for linux-audio-dev-list; Sun, 15 Aug 1999 19:09:34 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id TAA11970 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 15 Aug 1999 19:09:32 -0400
From: est@hyperreal.org
Received: (qmail 10894 invoked by uid 162); 15 Aug 1999 23:06:57 -0000
Message-ID: <19990815230657.10893.qmail@hyperreal.org>
Subject: [linux-audio-dev] 3DNow! fun?
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Sun, 15 Aug 1999 16:06:57 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 7eb3bf975071459e9c21ac7a2185c1db

Hey, People,

Noticing how much it did for mpg123, I've just started playing with
3DNow! instructions.  Is anyone else doing work with these?  It seems
the K7 adds 5 more of these in addition to being SMP ready..so delish!

Eric

From - Mon Aug 16 01:19:44 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA24838
	for <slinkp@ulster.net>; Mon, 16 Aug 1999 00:58:46 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA12267 for linux-audio-dev-list; Mon, 16 Aug 1999 00:13:42 -0400
Received: from ax-nicb.axnet.it (ax-nicb.axnet.it [194.184.60.149]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA12263 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 16 Aug 1999 00:13:13 -0400
Received: (from nicb@localhost)
	by ax-nicb.axnet.it (8.8.7/8.8.7) id FAA16790;
	Mon, 16 Aug 1999 05:32:25 +0200
Date: Mon, 16 Aug 1999 05:32:25 +0200 (CEST)
From: Nicola Bernardini <nicb@axnet.it>
To: Guenter Geiger <geiger@iem.mhsg.ac.at>
cc: Linux Audio Development Mailing list <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] float math
Message-ID: <Pine.LNX.4.10.9908160519320.212-100000@ax-nicb.axnet.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 146f7dc0527ec943bd235bc7f5ef0d68


Dear Guenter, dear all,

I seem to be the only person in the world with this problem :)
When I tried to compile Mix I encountered the
same problems I had in compiling pd: the linking stage barks that
it cannot find the various 'sinf, logf, powf' etc. functions, which
I assume to be float copies of the sin, log, etc. functions from the
math library. Currently I compile with:

gcc version 2.7.2.3
/lib/libc.so.5.4.46

I have been looking quite hard around for libm libraries that have
these calls but could not find where to get them. Of course a solution
is to

#define sinf sin
etc. etc.

but I always wondered where you get these calls from :)

Thanks for your help

Nicola

------------------------------------------------------------------------
Nicola Bernardini
E-mail: nicb@axnet.it
 
Re graphics: A picture is worth 10K words -- but only those to describe
the picture.  Hardly any sets of 10K words can be adequately described
with pictures.

From - Tue Aug 17 23:42:20 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA05473
	for <slinkp@ulster.net>; Mon, 16 Aug 1999 06:00:59 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA12778 for linux-audio-dev-list; Mon, 16 Aug 1999 05:09:16 -0400
Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA12775 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 16 Aug 1999 05:09:11 -0400
Received: from hendrix (kyle91.zip.com.au [61.8.17.219])
	by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id SAA12778
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 16 Aug 1999 18:56:21 +1000 (EST)
Message-ID: <37B7D491.41DB6E2A@zip.com.au>
Date: Mon, 16 Aug 1999 19:06:25 +1000
From: Erik de Castro Lopo <erikd@zip.com.au>
Organization: Eric Conspiracy Secret Labs
X-Mailer: Mozilla 3.04Gold (X11; I; Linux 2.2.11 i586)
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Nicola Bernardini's sound file library comments
References: <19990815230207.9728.qmail@hyperreal.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 348f77d805db8c332183c922e6b2710c

est@hyperreal.org wrote:
> 
> Erik de Castro Lopo discourseth:
> 
> OK, Bruce. :)

Hullo Bruce. You seem to pop up everywhere.

> > 3) libsndfile has more comprehensive error reporting
> 
> That may be an area where it's superior to libaudiofile as well.  Much
> of the error checking of the latter seems to be burried in assert()
> statements!

I agree completely. assert () has no place in a library. libsndfile
doesn't
use assert () and on error conditions should at worst return an error
value
and set an internal error variable so that a meaningful error string can
be retrieved latter. Anything worse than returning an error value is a
bug and I want to fix it :-).

> Is libsndfile reentrant?

I actually haven't tested this but it was designed to be reentrant. The
ONLY static data should be read-only string variables.

> What reasons are there for prefering it over libaudiofile given the
> momentum behind the latter?

I haven't really kept up with libaudiofile (or sndlib for that matter)
so I may be way off in my comments. Anyway, last time I looked
libaudiofile
did not handle any file format with data width greater than 16 bits.
This
means no 24 or 32 bit PCM data in WAV or AIFF files and no 32 bit
floating
point WAV file support. These formats are heavily used in during the CD
mastering process.

In addition, development on libaudiofile seems to be moving a bit more
slowly than libsndfile. Finally I think the interface to libsndfile is
more flexible due to the implementation of functions to read/write the 
audio data as shorts, ints and doubles. Calls to these functions may
be intermixed with impunity.

At one stage I was talking to Richard Kent (author of DAP) about wruting
a wrapper around the libsndfile functions to emulate libaudiofile. 
Unfortunately nothing can of it. I may still be willing if I can find
some
good documentation on SGI's version of libaudiofile

> > 1) An interface is designed to limit name space pollution. All libsndfile
> >    functions are named sf_* and all constants are named SF_*
> 
> You might want to have an option to build a C++ version which actually
> uses its own C++ namespace.

I'm not a great fan of C++ (and a bit behind the times, still using
version 2 of the Stroustrup book which was just out when I bought it) 
but if you give me a bit of a rundown of what it is, how it works and 
the implications, I'm more than willing to consider it.

> > 3) sample rate convert on read (ie open a file, see that it is not the
> >    desired sample rate, call something like sf_set_samplerate (), then
> >    read data at the correct sample rate using the normal read functions.
> 
> Feel free to rip resampling out of oolaboola. :)

Thanks, I'll have a look. I'm very keen to get very high quality
resampling
going. I'm looking to get signal-to-noise ratios of 120dB to match
current
state of the art analog-to-digital and digital-to-analogue converter
technology. I'm not afraid to do some heavy maths and Octave is my
friend :-).

Cheers,
Erik
-- 
+-------------------------------------------------+
     Erik de Castro Lopo     erikd@zip.com.au
+-------------------------------------------------+
"There are two ways of constructing a software design. One way is
 to make it so simple that there are obviously no deficiencies
 and the other is to make it so complicated that there are no
 obvious deficiencies."  --  C A R Hoare

From - Tue Aug 17 23:42:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA21058
	for <slinkp@ulster.net>; Mon, 16 Aug 1999 09:21:52 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA13072 for linux-audio-dev-list; Mon, 16 Aug 1999 08:34:03 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id IAA13069 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 16 Aug 1999 08:33:55 -0400
From: est@hyperreal.org
Received: (qmail 23154 invoked by uid 162); 16 Aug 1999 12:31:17 -0000
Message-ID: <19990816123116.23153.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] Re: Nicola Bernardini's sound file library comments
In-Reply-To: <37B7D491.41DB6E2A@zip.com.au> from Erik de Castro Lopo at "Aug
 16, 1999 07:06:25 pm"
To: Erik de Castro Lopo <erikd@zip.com.au>
Date: Mon, 16 Aug 1999 05:31:16 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4a805392ea4603fc09ccc4eb45aed0aa

Erik de Castro Lopo discourseth:
> 
> > > 3) libsndfile has more comprehensive error reporting
> > 
> > That may be an area where it's superior to libaudiofile as well.  Much
> > of the error checking of the latter seems to be burried in assert()
> > statements!
> 
> I agree completely. assert () has no place in a library.

Well, the assertions are compiled out during a normal library build,
but they include some tests that don't add appreciably to run-time and
that look important.

> > Is libsndfile reentrant?
> 
> I actually haven't tested this but it was designed to be reentrant. The
> ONLY static data should be read-only string variables.

Clear design is a lot more important than test in this area.

> > What reasons are there for prefering it over libaudiofile given the
> > momentum behind the latter?
> 
> I haven't really kept up with libaudiofile (or sndlib for that matter)
> so I may be way off in my comments. Anyway, last time I looked
> libaudiofile
> did not handle any file format with data width greater than 16 bits.
> This
> means no 24 or 32 bit PCM data in WAV or AIFF files and no 32 bit
> floating
> point WAV file support. These formats are heavily used in during the CD
> mastering process.

A quick look at the code suggests that this remains partially true (it
looks like 32-bit integral has been added).

> At one stage I was talking to Richard Kent (author of DAP) about wruting
> a wrapper around the libsndfile functions to emulate libaudiofile. 
> Unfortunately nothing can of it. I may still be willing if I can find
> some
> good documentation on SGI's version of libaudiofile

It may be both more important and easier to target the interface
provided by the one distributed with gnome.

> > You might want to have an option to build a C++ version which actually
> > uses its own C++ namespace.
> 
> I'm not a great fan of C++ (and a bit behind the times, still using
> version 2 of the Stroustrup book which was just out when I bought it) 

Oh, *do* get the 3rd edition.  I wasn't that interested in C++ until
the 3rd edition came out (I got the 2nd the same time you did :), the
standard matured, and egcs made it widely deliverable.

> but if you give me a bit of a rundown of what it is, how it works and 
> the implications, I'm more than willing to consider it.

Eh..on second thought it's probably a silly idea if you're not using
other C++ features. :) Basically, you'd be able to throw libsndfile in
a namespace of that name..no abbreviations needed because clients can
say `using namespace libsndfile;' or `using libsndfile::foo' if they
only wanted function foo.

> > Feel free to rip resampling out of oolaboola. :)
> 
> Thanks, I'll have a look. I'm very keen to get very high quality
> resampling
> going. I'm looking to get signal-to-noise ratios of 120dB to match
> current
> state of the art analog-to-digital and digital-to-analogue converter
> technology. I'm not afraid to do some heavy maths and Octave is my
> friend :-).

Hmm..maybe I'll need to rip resampling out of libsndfile!  I'm working
as a total primitive here.  First I did linear resampling.  Then I did
quadratic, deriving it from first principles because I didn't have a
reference at hand.  Are there better alternatives?  Some kind of
spline thing perhaps?

Eric

From - Tue Aug 17 23:42:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA27052
	for <slinkp@ulster.net>; Mon, 16 Aug 1999 10:02:36 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA13106 for linux-audio-dev-list; Mon, 16 Aug 1999 09:05:04 -0400
Received: from cmn14.stanford.edu (cmn14.Stanford.EDU [36.49.0.93]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA13103 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 16 Aug 1999 09:05:01 -0400
Received: (from bil@localhost)
	by cmn14.stanford.edu (8.8.8/8.8.8) id GAA14629
	for linux-audio-dev@ginette.musique.umontreal.ca; Mon, 16 Aug 1999 06:02:23 -0700 (PDT)
Message-Id: <199908161302.GAA14629@cmn14.stanford.edu>
Content-Type: text/plain
MIME-Version: 1.0 (NeXT Mail 3.3 v148.2.1)
In-Reply-To: <Pine.LNX.4.10.9908151100310.212-100000@ax-nicb.axnet.it>
X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3)
Received: by NeXT.Mailer (1.148.2.1)
From: Bill Schottstaedt <bil@ccrma.Stanford.EDU>
Date: Mon, 16 Aug 1999 06:02:21 -0700
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a late reply to the 'What do we need now'
	thread... (sndlib)
References: <Pine.LNX.4.10.9908151100310.212-100000@ax-nicb.axnet.it>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e8e51c61fcad6a25966f33ea5e29bcdd

>  The library is lacking
>   a proper Makefile and autoconf features, so again, if Bill agrees
>   or does'nt want to do it himself I can offer my help to build these
>   files and also a cvs repository for it (at the end of august).

Gee, I'd love help!!  No one had previously asked for it, but now
that it's an issue, I'll see if I can conjure something up -- the
Snd configure stuff should work; just delete all the Motif references.
I looked at libtool, but didn't get very far with it.

> b) it's documented;

Now I'm embarassed -- the sndlib documentation needs about a year
of work!


On the libsndfile vs sndlib business, I am uncomfortable with this
entire situation; I don't want to get into a long debate, but (groan),
at least I'll respond briefly:

> 1) sndlib looks as if it hasn't been worked on for a number of years
>    while libsndfile is still under active development

It's being worked on coninuously -- look at sndlib.h for some details.

> 2) sndlib needs to have automake/autoconf support added while libsndfile
>    already has it

no problem...

> 3) libsndfile has more comprehensive error reporting

maybe so -- I should check what you've done; I've received
no complaints on this score.

> 4) libsndfile has thorough regression tests (distributed with the library)
>   of nearly all library functionality

I guess the difference here is that sndlib's "thorough regression tests"
are distributed with CLM and Snd.

> 1) An interface is designed to limit name space pollution. All libsndfile
>   functions are named sf_* and all constants are named SF_*

Most sndlib names now start with "SNDLIB" or "mus" -- a few holdovers still
use "audio" or "sound".  I doubt it pollutes anyone's name space.


I could list sndlib's high points and start a flame war, but, geez you guys,
I'm doing this because I love messing around with sounds, not to "compete"
with anyone.  I'd even be willing to discuss a merger of libraries, or,
if Mr Castro Lopo wants, he can use any of my code he likes -- for example,
there's a high quality sample rate converter.

From - Tue Aug 17 23:42:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA12005
	for <slinkp@ulster.net>; Mon, 16 Aug 1999 11:58:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA13390 for linux-audio-dev-list; Mon, 16 Aug 1999 10:15:54 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id KAA13387 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 16 Aug 1999 10:15:51 -0400
From: est@hyperreal.org
Received: (qmail 3784 invoked by uid 162); 16 Aug 1999 14:13:12 -0000
Message-ID: <19990816141312.3783.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] a late reply to the 'What do we need now' thread...
 (sndlib)
In-Reply-To: <199908161302.GAA14629@cmn14.stanford.edu> from Bill Schottstaedt
 at "Aug 16, 1999 06:02:21 am"
To: Bill Schottstaedt <bil@ccrma.Stanford.EDU>
Date: Mon, 16 Aug 1999 07:13:12 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 43b8a061f4b65ab5c17b3164d6f9461d

Bill Schottstaedt discourseth:
>
> I looked at libtool, but didn't get very far with it.

It's scary.

> On the libsndfile vs sndlib business, I am uncomfortable with this
> entire situation; I don't want to get into a long debate, but (groan),
> at least I'll respond briefly:

You know, these self-descriptions are valuable as a first-pass for
people who are trying to evaluate packages for their own use..so much
code out there.

> Most sndlib names now start with "SNDLIB" or "mus" -- a few holdovers still
> use "audio" or "sound".  I doubt it pollutes anyone's name space.

..but it could.  One prefix per library frees up more of my brain. :)

> I could list sndlib's high points and start a flame war, but, geez you guys,
> I'm doing this because I love messing around with sounds, not to "compete"
> with anyone.  I'd even be willing to discuss a merger of libraries, or,
> if Mr Castro Lopo wants, he can use any of my code he likes -- for example,
> there's a high quality sample rate converter.

src?  Could you provide just a little documentation on it?

Thanks,

Eric

From - Tue Aug 17 23:42:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA11669
	for <slinkp@ulster.net>; Mon, 16 Aug 1999 11:56:04 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA13406 for linux-audio-dev-list; Mon, 16 Aug 1999 10:23:43 -0400
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id KAA13403 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 16 Aug 1999 10:23:41 -0400
Message-Id: <199908161423.KAA13403@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Nicola Bernardini's sound file library comments
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Mon, 16 Aug 1999 10:20:58 -0400 (EDT)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
In-Reply-To: <19990816123116.23153.qmail@hyperreal.org> from "est@hyperreal.org" at Aug 16, 99 05:31:16 am
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3e24a4764b472bbaca195c6f57a5e343

est@hyperreal.org wrote:
> Erik de Castro Lopo discourseth:
> > I'm looking to get signal-to-noise ratios of 120dB to match current
> > state of the art analog-to-digital and digital-to-analogue converter
> > technology. I'm not afraid to do some heavy maths and Octave is my
> > friend :-).
> 
> Hmm..maybe I'll need to rip resampling out of libsndfile!  I'm working
> as a total primitive here.  First I did linear resampling.  Then I did
> quadratic, deriving it from first principles because I didn't have a
> reference at hand.  Are there better alternatives?  Some kind of
> spline thing perhaps?

The ideal, and 120 dB S/N is aiming pretty close, is interpolation
with a sinc function, appropriately dilated in the subsampling case.
You can think of it as an analog reconstruction followed by resampling.
Julius Smith has theory and GPL'ed C code at
        http://www-ccrma.stanford.edu/~jos/resample/index.html

Spline and Lagrange-polynomial interpolation are impractical for
resampling of that quality.  For less difficult jobs they're probably
faster, and certainly require less memory, than windowed-sinc -- 
I'd be curious to see a comparison.  Note that any interpolant that
passes through all the original sample points, as they do, is
incorrect for subsampling (rate-lowering).

For particular ratios one ought to win by predesigning a multirate
(`polyphase') filter bank, but this will be awkward in general.  
I don't know how to do this.

An interesting comparison of sox's implementation of linear, sinc, and
polyphase resampling:
        http://eakaw2.et.tu-dresden.de/~andreas/resample/resample.html


By the way, I think resampling could warrant a library of its own, or
at least support for memory-to-memory operations within a soundfile
library.  Julius Smith's code is good to have out there, but it's not
packaged and polished for library use.  It would be particularly nice
to be able to specify passband width and stopband attenuation, and
have it generate the necessary filter.

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Tue Aug 17 23:42:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA09907
	for <slinkp@ulster.net>; Mon, 16 Aug 1999 11:43:45 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA13432 for linux-audio-dev-list; Mon, 16 Aug 1999 10:53:16 -0400
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id KAA13429 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 16 Aug 1999 10:53:14 -0400
Message-Id: <199908161453.KAA13429@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] can't get any dropouts?
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Mon, 16 Aug 1999 10:50:21 -0400 (EDT)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
In-Reply-To: <37B4A2B8.1F7AF433@zip.com.au> from "Erik de Castro Lopo" at Aug 14, 99 08:56:56 am
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 41e32abbb296a7194e58dcf21f3ddd90

Erik de Castro Lopo wrote:
> There are a number of PC based harddisk recording systems. I think
> most of them recommend the use of SCSI disks for audio data. IDE
> drives are find for the OS and programs themselves but not the
> data which requires low latency access.

I don't have one myself, but I lurk on the PC-DAW mailing list
(http://www.missionrec.com/pcdaw.html) gathering information for when
I break down and buy a post-486 computer.  

Many people there use IDE for their audio drives.  It means more CPU
involvement, and people do seem to spend a lot of time fiddling with
their IDE drivers, but it can be made to work.

> I seem to remember hearing that improved RT response was one of
> the things Linus was hoping for with version 3.0

Is there a web page that summarizes the Linux RT situation?  I could
put together the information I've seen, but right now somebody else
would have to be the one to keep it up to date.

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Tue Aug 17 23:42:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA20170
	for <slinkp@ulster.net>; Mon, 16 Aug 1999 12:55:58 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA13572 for linux-audio-dev-list; Mon, 16 Aug 1999 12:17:46 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id MAA13569 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 16 Aug 1999 12:17:43 -0400
From: est@hyperreal.org
Received: (qmail 11226 invoked by uid 162); 16 Aug 1999 16:15:06 -0000
Message-ID: <19990816161506.11225.qmail@hyperreal.org>
Subject: [linux-audio-dev] resampling
In-Reply-To: <199908161423.KAA13403@ginette.musique.umontreal.ca> from Eli Brandt
 at "Aug 16, 1999 10:20:58 am"
To: eli+@cs.cmu.edu
Date: Mon, 16 Aug 1999 09:15:05 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8003
X-Mozilla-Status2: 00000000
X-UIDL: 0de0654915dc44612e40cb57513497b0

Eli Brandt discourseth:
> est@hyperreal.org wrote:
> > Erik de Castro Lopo discourseth:
> > > I'm looking to get signal-to-noise ratios of 120dB to match current
> > > state of the art analog-to-digital and digital-to-analogue converter
> > > technology. I'm not afraid to do some heavy maths and Octave is my
> > > friend :-).
> > 
> > Hmm..maybe I'll need to rip resampling out of libsndfile!  I'm working
> > as a total primitive here.  First I did linear resampling.  Then I did
> > quadratic, deriving it from first principles because I didn't have a
> > reference at hand.  Are there better alternatives?  Some kind of
> > spline thing perhaps?
> 
> The ideal, and 120 dB S/N is aiming pretty close, is interpolation
> with a sinc function, appropriately dilated in the subsampling case.
> You can think of it as an analog reconstruction followed by resampling.
> Julius Smith has theory and GPL'ed C code at
>         http://www-ccrma.stanford.edu/~jos/resample/index.html

Yes..I'd checked that out..too slow for my purposes. :|

Note also, my application requires variable-factor resampling of
unpredictable pieces of the input. :)

> Spline and Lagrange-polynomial interpolation are impractical for
> resampling of that quality.  For less difficult jobs they're probably
> faster, and certainly require less memory, than windowed-sinc -- 
> I'd be curious to see a comparison.

Me too!  I haven't even tested what quadratic (I assume that comes
under `Lagrange-polynomial'?) gets me over linear.

> An interesting comparison of sox's implementation of linear, sinc, and
> polyphase resampling:
>         http://eakaw2.et.tu-dresden.de/~andreas/resample/resample.html

Thanks for pointing this out.

Eric

From - Tue Aug 17 23:42:40 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA23702
	for <slinkp@ulster.net>; Mon, 16 Aug 1999 13:16:52 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA13590 for linux-audio-dev-list; Mon, 16 Aug 1999 12:25:34 -0400
Received: from cygnus.com (runyon.cygnus.com [205.180.230.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA13587 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 16 Aug 1999 12:25:31 -0400
Received: from cygnus.com (thudson1.cygnus.com [205.226.144.45])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id JAA02600;
	Mon, 16 Aug 1999 09:22:48 -0700 (PDT)
Message-ID: <37B83AD7.3863989D@cygnus.com>
Date: Mon, 16 Aug 1999 12:22:47 -0400
From: Thomas Hudson <thudson@cygnus.com>
Organization: Cygnus Solutions
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>,
        alsa <alsa-devel@alsa.jcu.cz>
Subject: [linux-audio-dev] Portal mailing list.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 740f019387eea18439b70d7b8c9c5802


Thanks to MCI Worldcom I don't believe this made it through
on the first attempt.

I've set a up a mailing list for developers working on the
Portable Real Time Audio I/O (http://www.audiomulch.com/portaudio/).
This is a cross platform framework, with volunteers working on ports
for many different platforms.

To subscribe send email to portal-request@tomy.net with "subscribe" 
as the subject. To post to the list send email to portal@tomy.net.

Thomas

From - Tue Aug 17 23:42:36 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA18719
	for <slinkp@ulster.net>; Mon, 16 Aug 1999 12:44:58 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA13531 for linux-audio-dev-list; Mon, 16 Aug 1999 12:02:45 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA13528 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 16 Aug 1999 12:02:43 -0400
Received: from bright.net (find-cas2-cs-35.dial.bright.net [209.143.26.189])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id MAA11443;
	Mon, 16 Aug 1999 12:00:06 -0400 (EDT)
Message-ID: <37B83BD8.E6DE94A6@bright.net>
Date: Mon, 16 Aug 1999 12:27:04 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Re: Mix
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: d3e01588d94aa93dc0713900b9e2a491

Greetings:

  I received some further communication from Dr. Hammer regarding Mix
and some of its capabilities. I will incorporate some of his
elucidations into the documentation, which I have been revising and
bringing up to date. 

  A few things to mention now:

	1. The Regions code is unusable and Dr. Hammer suggests we eliminate it
entirely. However, support for regions is very desirable: could that be
a project for someone ?

	2. The Csound variable does indeed work on SGI machines, which are
apparently able to allow multiple simultaneous access to a single
device. The problem with getting that to work under Linux is that the
device is owned by a single app. I agree with Nicola that the feature
could be useful, but I don't think it's going to work with the OSS/Free
or OSS/Linux drivers. Perhaps with ALSA ? Can someone clarify that for
me ?

	3. As already announced, we can place Mix under the GPL. Dr. Hammer has
asked though that we indicate that the decision to allow this was due
not only to himself but also to his colleagues at NoTAM. We should
therefore give proper credit to NoTAM as well to Dr. Hammer. Ultimately
(IMO, of course) we should offer NoTAM any Linux versions we create.
They already have a Linux directory for ftp of some of the early ports,
but it is out of date now.

  Finally, can anyone suggest to me how I could test Mix's network
connecivity with a standalone machine ?

  I will check the MIDI functions later today.

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Tue Aug 17 23:42:48 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA23465
	for <slinkp@ulster.net>; Mon, 16 Aug 1999 17:14:49 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA13960 for linux-audio-dev-list; Mon, 16 Aug 1999 16:23:11 -0400
Received: from ax-nicb.axnet.it (ax-nicb.axnet.it [194.184.60.149]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA13957 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 16 Aug 1999 16:22:51 -0400
Received: (from nicb@localhost)
	by ax-nicb.axnet.it (8.8.7/8.8.7) id UAA04800;
	Mon, 16 Aug 1999 20:01:19 +0200
Date: Mon, 16 Aug 1999 20:01:18 +0200 (CEST)
From: Nicola Bernardini <nicb@axnet.it>
To: Erik de Castro Lopo <erikd@zip.com.au>, est@hyperreal.org
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Nicola Bernardini's sound file library
 comments
In-Reply-To: <19990815230207.9728.qmail@hyperreal.org>
Message-ID: <Pine.LNX.4.10.9908161941590.212-100000@ax-nicb.axnet.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 9382a3a0b31465eb71c7f93bbf0179c9

Dear Erik, dear all,

I absolutely did not mean to start a *competition* over which is the
best sound library available, and even less than that state some
'rules' on how to develop audio software on linux. Rather,
I was personally thinking that writing
an audio library is enough of a humble and boring task that nobody would
want to do that anyway and I was amazed that several people had already
written some. I am all the more amazed (and delighted) that you defend
(rightly so) the work you've done: that's very good. Now the important
part is that we converge on your library, since you are eager to continue
developing it and maintaining it: as far as I'm concerned I have no
objections even if I have'nt seen your library yet (the nice part of
open-source is that there's no point in lying on features :), and
on the other hand I'm sure that Bill Schottstaedt won't
mind at all. And let me add immediately that I certainly don't mean
that *all* audio applications *should* use this library - what I'm
saying is that they *could*, and it would make life easier for them.
The point here is that there are many applications (adsyn, mix,
mxv, DAP, ein, etc.) which use libraries with less features and we
should decide an easy path to retrofitting them with yours.

Today, Erik de Castro Lopo mi scrisse cio` che segue:

[snip]
> This "currently under development" status I think is the libsndfile's
> greatest strength. libsndfile was started in December last year and 
> in my opinion has progressed at an amazing pace. Up until now, nobody
> else has contibuted code (other than small bug fixes) but I am more 
> than willing for this to happen.

This is just what we need, I think. Thanks Erik.

Yesterday, est@hyperreal.org mi scrisse cio` che segue:

[snip]
> Is libsndfile reentrant?

I think this is a pretty important feature. Another feature that could
make it win over other libraries is some kind of compatibility with
the audiofile library to make easy portings between SGI and linux.
I reckon that this would throw the name space pollution attentions
out the window, but it could be selected optionally in the configure process
(adding just a header for equivalences, or at worst a file of
function conversions).

[snip]
> Feel free to rip resampling out of oolaboola. :)

Yees! this is what needs to happen...

ciao

Nicola
------------------------------------------------------------------------
Nicola Bernardini
E-mail: nicb@axnet.it
 
Re graphics: A picture is worth 10K words -- but only those to describe
the picture.  Hardly any sets of 10K words can be adequately described
with pictures.

From - Tue Aug 17 23:42:43 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA04517
	for <slinkp@ulster.net>; Mon, 16 Aug 1999 14:57:09 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA13748 for linux-audio-dev-list; Mon, 16 Aug 1999 14:12:51 -0400
Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA13745 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 16 Aug 1999 14:12:46 -0400
Received: from hendrix (scratchy76.zip.com.au [61.8.12.204])
	by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id DAA00747;
	Tue, 17 Aug 1999 03:59:50 +1000 (EST)
Message-ID: <37B853F4.59C2F901@zip.com.au>
Date: Tue, 17 Aug 1999 04:09:56 +1000
From: Erik de Castro Lopo <erikd@zip.com.au>
Organization: Eric Conspiracy Secret Labs
X-Mailer: Mozilla 3.04Gold (X11; I; Linux 2.2.11 i586)
MIME-Version: 1.0
To: Bill Schottstaedt <bil@ccrma.Stanford.EDU>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a late reply to the 'What do we need now' 	thread... (sndlib)
References: <Pine.LNX.4.10.9908151100310.212-100000@ax-nicb.axnet.it> <199908161302.GAA14629@cmn14.stanford.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5e66b55f4cf407c5c687ff42109560f9

Bill Schottstaedt wrote:
> 

<snip>

> I could list sndlib's high points and start a flame war, but, geez you guys,
> I'm doing this because I love messing around with sounds, not to "compete"
> with anyone.  I'd even be willing to discuss a merger of libraries, or,
> if Mr Castro Lopo wants, he can use any of my code he likes -- for example,
> there's a high quality sample rate converter.

I'm sorry Bill, I should have shown some more respect. You've been around
this game a lot longer than I have and contributed a lot more. I remember
seeing your name in connection with computer music when I first started 
getting interested in computer music 15 years ago.

And of course, under the GPL, your code is my code and my code is your 
code. :-). I'll definitely have a look at your SRC.

Erik
-- 
+-------------------------------------------------+
     Erik de Castro Lopo     erikd@zip.com.au
+-------------------------------------------------+
"If dolphins are so smart, why do they live in igloos?" -Eric Cartman

From - Tue Aug 17 23:42:44 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA05362
	for <slinkp@ulster.net>; Mon, 16 Aug 1999 15:04:25 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA13770 for linux-audio-dev-list; Mon, 16 Aug 1999 14:21:42 -0400
Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA13767 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 16 Aug 1999 14:21:38 -0400
Received: from hendrix (scratchy76.zip.com.au [61.8.12.204])
	by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id EAA01040;
	Tue, 17 Aug 1999 04:08:39 +1000 (EST)
Message-ID: <37B85606.58C299BA@zip.com.au>
Date: Tue, 17 Aug 1999 04:18:46 +1000
From: Erik de Castro Lopo <erikd@zip.com.au>
Organization: Eric Conspiracy Secret Labs
X-Mailer: Mozilla 3.04Gold (X11; I; Linux 2.2.11 i586)
MIME-Version: 1.0
To: est@hyperreal.org
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a late reply to the 'What do we need now' thread...  (sndlib)
References: <19990816141312.3783.qmail@hyperreal.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: cd0c5a5cfdc4c4dca798a47f2a4e9358

est@hyperreal.org wrote:
> 
> Bill Schottstaedt discourseth:
> >
> > I looked at libtool, but didn't get very far with it.
> 
> It's scary.

When I was getting the autoconf/automake thing going I didn't
even look at libtool. Its taken care or by autoconf. For a 
reasonably good tutorial on the whole configure thing have a 
look at : 

    http://www.amath.washington.edu/~lf/tutorials/autoconf/

It gives a couple of minimalist examples that are very easy to 
build on. Also grab the autotools package that is listed.

Erik
-- 
+-------------------------------------------------+
     Erik de Castro Lopo     erikd@zip.com.au
+-------------------------------------------------+
"The whole principle is wrong; it's like demanding that grown men live
on 
skim milk because the baby can't eat steak."
- author Robert A. Heinlein on censorship.

From - Tue Aug 17 23:42:46 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA09904
	for <slinkp@ulster.net>; Mon, 16 Aug 1999 15:38:03 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA13811 for linux-audio-dev-list; Mon, 16 Aug 1999 14:46:15 -0400
Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA13808 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 16 Aug 1999 14:46:11 -0400
Received: from hendrix (scratchy76.zip.com.au [61.8.12.204])
	by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id EAA01440;
	Tue, 17 Aug 1999 04:33:07 +1000 (EST)
Message-ID: <37B85BC2.3D1420AB@zip.com.au>
Date: Tue, 17 Aug 1999 04:43:14 +1000
From: Erik de Castro Lopo <erikd@zip.com.au>
Organization: Eric Conspiracy Secret Labs
X-Mailer: Mozilla 3.04Gold (X11; I; Linux 2.2.11 i586)
MIME-Version: 1.0
To: eli+@cs.cmu.edu
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Nicola Bernardini's sound file library comments
References: <199908161423.KAA13403@ginette.musique.umontreal.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f4091bab673aa4b5f38c55d20f5f5482

Eli Brandt wrote:

<snip>

> The ideal, and 120 dB S/N is aiming pretty close, is interpolation
> with a sinc function, appropriately dilated in the subsampling case.
> You can think of it as an analog reconstruction followed by resampling.
> Julius Smith has theory and GPL'ed C code at
>         http://www-ccrma.stanford.edu/~jos/resample/index.html
> 
> Spline and Lagrange-polynomial interpolation are impractical for
> resampling of that quality.  

Yep, I've got a basic windowed sinc interpolator prototype going in 
Octave which upsamples by 2 and has about 70dB SNR. I just found an error 
in the scaling of the filter coefficients which probably accounts for
some of extra resampling image in what should be the stop band.

> For less difficult jobs they're probably
> faster, and certainly require less memory, than windowed-sinc --
> I'd be curious to see a comparison.  Note that any interpolant that
> passes through all the original sample points, as they do, is
> incorrect for subsampling (rate-lowering).
>
> For particular ratios one ought to win by predesigning a multirate
> (`polyphase') filter bank, but this will be awkward in general.
> I don't know how to do this.

The Julius O. Smith paper suggests linear interpolation between points
generated by two windowed sinc filters. I'm going to be doing something
like this but I'll also be looking at fitting a polynomial to four
points obtained from windowed sinc filters.

> An interesting comparison of sox's implementation of linear, sinc, and
> polyphase resampling:
>         http://eakaw2.et.tu-dresden.de/~andreas/resample/resample.html
> 
> By the way, I think resampling could warrant a library of its own, or
> at least support for memory-to-memory operations within a soundfile
> library.  Julius Smith's code is good to have out there, but it's not
> packaged and polished for library use.  It would be particularly nice
> to be able to specify passband width and stopband attenuation, and
> have it generate the necessary filter.

As a first pass, I'll be writing my SRC in Octave (much like Matlab
but GPL) and contributing it to the Ocatve project. I also planned
to write a web page discussing how I got to where I did. Hopefully
my paper will offer a more introductory explanation of SRC.

Anyway, once the Octave code is going I was going to re-write it in
C and hook it up into libsndfile. I had thought of making it a
separate library but it seemed strange to have such a obscure piece
of technology in its own library. 

Erik
-- 
+-------------------------------------------------+
     Erik de Castro Lopo     erikd@zip.com.au
+-------------------------------------------------+
"Reality is just a crutch for people that can't handle CyberSpace!!"
- Hank Duderstadt

From - Tue Aug 17 23:42:50 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA28026
	for <slinkp@ulster.net>; Mon, 16 Aug 1999 17:47:32 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA14009 for linux-audio-dev-list; Mon, 16 Aug 1999 17:02:56 -0400
Received: from ax-nicb.axnet.it (ax-nicb.axnet.it [194.184.60.149]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA14006 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 16 Aug 1999 17:02:45 -0400
Received: (from nicb@localhost)
	by ax-nicb.axnet.it (8.8.7/8.8.7) id WAA05521;
	Mon, 16 Aug 1999 22:53:31 +0200
Date: Mon, 16 Aug 1999 22:53:31 +0200 (CEST)
From: Nicola Bernardini <nicb@axnet.it>
To: Dave Phillips <dlphilp@bright.net>
cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Mix
In-Reply-To: <37B83BD8.E6DE94A6@bright.net>
Message-ID: <Pine.LNX.4.10.9908162247590.5300-100000@ax-nicb.axnet.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d598594e35b49d015fa27eaf43768c5a

Today, Dave Phillips mi scrisse cio` che segue:

[snip]
> 	2. The Csound variable does indeed work on SGI machines, which are
> apparently able to allow multiple simultaneous access to a single
> device. The problem with getting that to work under Linux is that the
> device is owned by a single app. I agree with Nicola that the feature
> could be useful, but I don't think it's going to work with the OSS/Free
> or OSS/Linux drivers. Perhaps with ALSA ? Can someone clarify that for
> me ?

maybe I'm not understanding much of Mix yet, but the way I see it
is that csound could be a nice way to process an audio file that
has been added into the Mix board, regulating its input with the
AUX bus. In this case, we would just need to work out a way to communicate
between Mix and csound - and I don't think that would be very complicated:
don't forget I already added IPC communication to unofficial csound
to implement sliders (I did it some months ago and had to stop because
I was too busy - I still plan to add sliders) and the code is still
buried there. To add communication for samples would not be too difficult,
and this may not even be the simpler solution.

[snip]
>   Finally, can anyone suggest to me how I could test Mix's network
> connecivity with a standalone machine ?

I'm not sure what you mean... I guess I'll have to study some more.

ciao

Nicola

------------------------------------------------------------------------
Nicola Bernardini
E-mail: nicb@axnet.it
 
Re graphics: A picture is worth 10K words -- but only those to describe
the picture.  Hardly any sets of 10K words can be adequately described
with pictures.

From - Tue Aug 17 23:42:53 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA22840
	for <slinkp@ulster.net>; Mon, 16 Aug 1999 21:14:27 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA14336 for linux-audio-dev-list; Mon, 16 Aug 1999 20:36:14 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA14333 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 16 Aug 1999 20:36:11 -0400
Received: from bright.net (find-cas2-cs-29.dial.bright.net [209.143.26.183])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id UAA00046;
	Mon, 16 Aug 1999 20:33:29 -0400 (EDT)
Message-ID: <37B8B431.F636420D@bright.net>
Date: Mon, 16 Aug 1999 21:00:33 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Nicola Bernardini <nicb@axnet.it>
CC: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Mix
References: <Pine.LNX.4.10.9908162247590.5300-100000@ax-nicb.axnet.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0053ba6b9f68e60775a40f90d378c0c1

Nicola Bernardini wrote:

> maybe I'm not understanding much of Mix yet, but the way I see it
> is that csound could be a nice way to process an audio file that
> has been added into the Mix board, regulating its input with the
> AUX bus. In this case, we would just need to work out a way to communicate
> between Mix and csound - and I don't think that would be very complicated:
> don't forget I already added IPC communication to unofficial csound
> to implement sliders (I did it some months ago and had to stop because
> I was too busy - I still plan to add sliders) and the code is still
> buried there. To add communication for samples would not be too difficult,
> and this may not even be the simpler solution.

As it stands now Mix merely calls Csound in this manner (in mix.c):

       if (catchup==0) {
         sprintf(streng, "csound -o devaudio %s.orc %s.sco &", value,
value);
         system(streng);
       }
       break;

Crude, yes. But it is dependent on multiple processes being able to
access the same device, something apparently easy for SGI iron but not
so simple under Linux. I understand that EsounD (esd) does it, but I
think that Csound would have to become esd-aware, and I don't know how
that's done.
 
> >   Finally, can anyone suggest to me how I could test Mix's network
> > connecivity with a standalone machine ?
> 
> I'm not sure what you mean... I guess I'll have to study some more.

Under the Settings menu there is an item called Internet Slaves. Opening
this item calls a window with entry boxes for host names and check boxes
for activating and accepting connections to the hosts. I just want to
test whatever it is that this feature does.

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Tue Aug 17 23:42:57 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id DAA27644
	for <slinkp@ulster.net>; Tue, 17 Aug 1999 03:55:21 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id CAA14735 for linux-audio-dev-list; Tue, 17 Aug 1999 02:58:47 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA14732 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 17 Aug 1999 02:58:39 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m11GdBr-000dxrC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Tue, 17 Aug 1999 08:57:47 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Tue, 17 Aug 1999 08:57:47 +0200 (CEST)
To: Nicola Bernardini <nicb@axnet.it>
Cc: Guenter Geiger <geiger@iem.mhsg.ac.at>,
        Linux Audio Development Mailing list <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] float math
In-Reply-To: <Pine.LNX.4.10.9908160519320.212-100000@ax-nicb.axnet.it>
References: <Pine.LNX.4.10.9908160519320.212-100000@ax-nicb.axnet.it>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14265.1495.6448.713714@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: a937b476e354bac5c4d7411308c0309a



Hi, 


Yes you are probably right, being the only person left in this world
with this problem .. :) 
No, but seriously, these functions are not implemented in the libc5,
but only in libc6. There's where "we" have them from.
This is a bug and mix and I will include the mentioned
"defines" for libc5 systems.

Thanks,

Guenter



Nicola Bernardini writes:
 > 
 > Dear Guenter, dear all,
 > 
 > I seem to be the only person in the world with this problem :)
 > When I tried to compile Mix I encountered the
 > same problems I had in compiling pd: the linking stage barks that
 > it cannot find the various 'sinf, logf, powf' etc. functions, which
 > I assume to be float copies of the sin, log, etc. functions from the
 > math library. Currently I compile with:
 > 
 > gcc version 2.7.2.3
 > /lib/libc.so.5.4.46
 > 
 > I have been looking quite hard around for libm libraries that have
 > these calls but could not find where to get them. Of course a solution
 > is to
 > 
 > #define sinf sin
 > etc. etc.
 > 
 > but I always wondered where you get these calls from :)
 > 
 > Thanks for your help
 > 
 > Nicola
 > 
 > ------------------------------------------------------------------------
 > Nicola Bernardini
 > E-mail: nicb@axnet.it
 >  
 > Re graphics: A picture is worth 10K words -- but only those to describe
 > the picture.  Hardly any sets of 10K words can be adequately described
 > with pictures.
 > 
 > 

From - Tue Aug 17 23:42:59 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA06180
	for <slinkp@ulster.net>; Tue, 17 Aug 1999 07:50:08 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA15137 for linux-audio-dev-list; Tue, 17 Aug 1999 06:17:14 -0400
Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA15134 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 17 Aug 1999 06:17:09 -0400
Received: from hendrix (wendy80.zip.com.au [61.8.18.80])
	by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id UAA31509;
	Tue, 17 Aug 1999 20:04:02 +1000 (EST)
Message-ID: <37B935F4.641DEA7B@zip.com.au>
Date: Tue, 17 Aug 1999 20:14:12 +1000
From: Erik de Castro Lopo <erikd@zip.com.au>
Organization: Eric Conspiracy Secret Labs
X-Mailer: Mozilla 3.04Gold (X11; I; Linux 2.2.11 i586)
MIME-Version: 1.0
To: Nicola Bernardini <nicb@axnet.it>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Nicola Bernardini's sound file library  comments
References: <Pine.LNX.4.10.9908161941590.212-100000@ax-nicb.axnet.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: bf9ac823faec0eff87b5e113597c03e9

Nicola Bernardini wrote:
> 
> Dear Erik, dear all,
> 
> I absolutely did not mean to start a *competition* over which is the
> best sound library available, and even less than that state some
> 'rules' on how to develop audio software on linux.  Rather, 
> I was personally thinking that writing
> an audio library is enough of a humble and boring task that nobody would
> want to do that anyway and I was amazed that several people had already
> written some. 

Its not as boring as you might think. Getting both Microsoft and IMA 
ADPCM encoded WAV files working was quite an interesting challenge.

> I am all the more amazed (and delighted) that you defend
> (rightly so) the work you've done: that's very good. Now the important
> part is that we converge on your library, since you are eager to continue
> developing it and maintaining it: as far as I'm concerned I have no
> objections even if I have'nt seen your library yet (the nice part of
> open-source is that there's no point in lying on features :), and
> on the other hand I'm sure that Bill Schottstaedt won't
> mind at all. And let me add immediately that I certainly don't mean
> that *all* audio applications *should* use this library - what I'm
> saying is that they *could*, and it would make life easier for them.

Yes, I'm afraid I over-reacted. I have put a lot of work into 
libsndfile and wouldn't want it to be overlooked. I'm sure other
software authors have similar feelings.

I started work on libsndfile when I couldn't find a library that 
allowed me to read samples as double precision floating point numbers. 
On modern processors, FP arithmetic is as fast or faster than integer 
arithmetic so it makes sense to do audio processing using FP.

<snip>

> Another feature that could
> make it win over other libraries is some kind of compatibility with
> the audiofile library to make easy portings between SGI and linux.
> I reckon that this would throw the name space pollution attentions
> out the window, but it could be selected optionally in the configure process
> (adding just a header for equivalences, or at worst a file of
> function conversions).

Is there documentation on SGI's implementation somewhere?

Erik
-- 
+-------------------------------------------------+
     Erik de Castro Lopo     erikd@zip.com.au
+-------------------------------------------------+
The government everybody loves to abuse sues the company everybody loves 
to hate. Throw in a bunch of faceless lawyers cross-examining techies 
[with] all the charisma of a video driver and you've got a spectacle of 
thoroughly miniscule proportions.

From - Tue Aug 17 23:43:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA01966
	for <slinkp@ulster.net>; Tue, 17 Aug 1999 11:16:50 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA15389 for linux-audio-dev-list; Tue, 17 Aug 1999 10:16:24 -0400
Received: from mustec.bgsu.edu (mustec.bgsu.edu [129.1.57.200]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA15386 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 17 Aug 1999 10:16:21 -0400
Received: from mustec.bgsu.edu (azygmun@mustec.bgsu.edu [129.1.57.200])
	by mustec.bgsu.edu (8.8.7/8.8.7) with ESMTP id KAA09210;
	Tue, 17 Aug 1999 10:14:29 -0400
Date: Tue, 17 Aug 1999 10:14:28 -0400 (EDT)
From: Adam Zygmunt <azygmun@bgnet.bgsu.edu>
X-Sender: azygmun@mustec.bgsu.edu
To: Dave Phillips <dlphilp@bright.net>
cc: Nicola Bernardini <nicb@axnet.it>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Mix
In-Reply-To: <37B8B431.F636420D@bright.net>
Message-ID: <Pine.LNX.4.10.9908170938480.9194-100000@mustec.bgsu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2562ccaf127c6cfc06c48c5a2da55566



On Mon, 16 Aug 1999, Dave Phillips wrote:

I realize this was discussed a little while back, but what version of
lesstif is best for Mix? I've tried .87 so far, and although it compiles
fine, the display was kind of screwed. Everything was crammed on the left
side, with lots of blank on the right. Not to mention the lesstif file
browser was as tricky as always (i.e. not quite resizing itself properly,
needs REALLY FAST double-clicks, and so on). I wasn't able to play back
anything, either, but then I probably just didn't have something checked.
By the way, how does mix handle stereo files? The bussing for that on
loading isn't especially clear.
    Speaking of lesstif, any ambitious person out there up for ditching it
from the mix code? Anything I've run with it (any version) seems clunky at
best, and there are so many more better API's to choose from now. Rumor
has it that even Mozilla is ditching Motif in favor of GTK for the next
Unix Netscape release. One of these days I'm really going to dig into it
to write an application to scratch a particular itch of mine, namely a
MIDI patch librarian. I used to be able to just do this with cat
/dev/midi00 > patchfile and hit the send button on my keyboard, but the
default blocking/buffering behavior is different for my new soundcard
(Ensoniq 1371-based) in both the OSS and ALSA drivers.

> Crude, yes. But it is dependent on multiple processes being able to
> access the same device, something apparently easy for SGI iron but not
> so simple under Linux. I understand that EsounD (esd) does it, but I
> think that Csound would have to become esd-aware, and I don't know how
> that's done.
>  

I haven't looked at its library, but I can't imagine esound support would
be too tricky to add. It might be nice, too. The situation I see with
esound though, is that's it's an all or nothing deal, as it steals the
card all the time, that being its job. I personally vote for making as 
many applications esound-aware as possible (at least non-realtime
dependent ones), unless its performance really isn't up to snuff, if only
because it seems like the most efficient way to allow multiple
applications to access the soundcard at this point. It might help out the
OSS/ALSA question, too, as only esd would need to handle the low-level
stuff for both.
    By the way, does mix allow one to cue up the various audio files at
different times, or do they all start at once? Sorry if this is a stupid
question, but I haven't had much luck getting it to run properly. Looks
quite a bit more useful than it did a few months ago, though.

Thanks for any help,
Adam Zygmunt


From - Tue Aug 17 23:43:03 1999
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id KAA30169
	for <slinkp@ulster.net>; Tue, 17 Aug 1999 10:50:12 -0400
Received: from bright.net (find-cas4-cs-29.dial.bright.net [209.143.49.159])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id KAA13841;
	Tue, 17 Aug 1999 10:36:09 -0400 (EDT)
Sender: root@sparticus.bright.net
Message-ID: <37B979A9.BD1BA3FA@bright.net>
Date: Tue, 17 Aug 1999 11:03:05 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>,
        Ben Okuly <lucyfan@bright.net>, Bill Phillips <lockserv@bright.net>,
        Bob Baratta <BOBBARATTA@aol.com>,
        Burton Beerman <bbeerma@bgnet.bgsu.edu>,
        Dan Britsch <dbritsch@bright.net>, Dave Topper <topper@virginia.edu>,
        Denny Wyss <dwyss@toledolink.com>, Fred Kwis <nukwisii@bright.net>,
        Joe Phillips <joegordy@bright.net>, Josh Flechtner <jafgon@bright.net>,
        Kevin Lyle <KLyle2006@aol.com>, Nicola Bernardini <nicb@axnet.it>,
        Paul Lansky <paullansky@home.com>, Paul Winkler <slinkp@ulster.net>,
        Phil Sugden <psugden@bright.net>,
        Rusty Campbell <rustyc@emailtools.com>,
        Tony Rosselet <car224@bright.net>
Subject: [OT] MP3 page
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 66558237e2d77b90849cb359bafc04da

Greetings:

  I have placed on-line a page of original music in the MP3 format. The
page is located here:

       http://www.bright.net/~dlphilp/dp_mp3.html

  The compositions are rather old, and the only reason I'm announcing it
on LAD is because the rendering was done using available Linux audio
tools.

  I hope you find at least some small amusement with these pieces. Feel
free to send comments, criticism, or cash...

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Tue Aug 17 23:43:06 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA04543
	for <slinkp@ulster.net>; Tue, 17 Aug 1999 11:34:55 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA15418 for linux-audio-dev-list; Tue, 17 Aug 1999 10:38:59 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA15415 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 17 Aug 1999 10:38:53 -0400
Received: from bright.net (find-cas4-cs-29.dial.bright.net [209.143.49.159])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id KAA13841;
	Tue, 17 Aug 1999 10:36:09 -0400 (EDT)
Message-ID: <37B979A9.BD1BA3FA@bright.net>
Date: Tue, 17 Aug 1999 11:03:05 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>,
        Ben Okuly <lucyfan@bright.net>, Bill Phillips <lockserv@bright.net>,
        Bob Baratta <BOBBARATTA@aol.com>,
        Burton Beerman <bbeerma@bgnet.bgsu.edu>,
        Dan Britsch <dbritsch@bright.net>, Dave Topper <topper@virginia.edu>,
        Denny Wyss <dwyss@toledolink.com>, Fred Kwis <nukwisii@bright.net>,
        Joe Phillips <joegordy@bright.net>, Josh Flechtner <jafgon@bright.net>,
        Kevin Lyle <KLyle2006@aol.com>, Nicola Bernardini <nicb@axnet.it>,
        Paul Lansky <paullansky@home.com>, Paul Winkler <slinkp@ulster.net>,
        Phil Sugden <psugden@bright.net>,
        Rusty Campbell <rustyc@emailtools.com>,
        Tony Rosselet <car224@bright.net>
Subject: [linux-audio-dev] [OT] MP3 page
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 356372eb1981c7c76ed73ef51111d2bd

Greetings:

  I have placed on-line a page of original music in the MP3 format. The
page is located here:

       http://www.bright.net/~dlphilp/dp_mp3.html

  The compositions are rather old, and the only reason I'm announcing it
on LAD is because the rendering was done using available Linux audio
tools.

  I hope you find at least some small amusement with these pieces. Feel
free to send comments, criticism, or cash...

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Tue Aug 17 23:43:07 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA10772
	for <slinkp@ulster.net>; Tue, 17 Aug 1999 12:18:40 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA15489 for linux-audio-dev-list; Tue, 17 Aug 1999 11:24:26 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id LAA15486 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 17 Aug 1999 11:24:23 -0400
From: est@hyperreal.org
Received: (qmail 23091 invoked by uid 162); 17 Aug 1999 15:21:41 -0000
Message-ID: <19990817152141.23090.qmail@hyperreal.org>
Subject: [linux-audio-dev] reading /dev/midi & esd
In-Reply-To: <Pine.LNX.4.10.9908170938480.9194-100000@mustec.bgsu.edu> from Adam
 Zygmunt at "Aug 17, 1999 10:14:28 am"
To: Adam Zygmunt <azygmun@bgnet.bgsu.edu>
Date: Tue, 17 Aug 1999 08:21:41 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 3e35824e5f43d4978e87bd04fb0d4139

Adam Zygmunt discourseth:
>
> One of these days I'm really going to dig into it
> to write an application to scratch a particular itch of mine, namely a
> MIDI patch librarian. I used to be able to just do this with cat
> /dev/midi00 > patchfile and hit the send button on my keyboard, but the
> default blocking/buffering behavior is different for my new soundcard
> (Ensoniq 1371-based) in both the OSS and ALSA drivers.

Have you tried playing with dd?  `dd if=/dev/midi00 bs=1 of=patchfile'
might do the trick.  Mmm..advanced sound apps. :9

> I haven't looked at its library, but I can't imagine esound support would
> be too tricky to add. It might be nice, too. The situation I see with
> esound though, is that's it's an all or nothing deal, as it steals the
> card all the time, that being its job. I personally vote for making as 
> many applications esound-aware as possible (at least non-realtime
> dependent ones), unless its performance really isn't up to snuff, if only
> because it seems like the most efficient way to allow multiple
> applications to access the soundcard at this point. It might help out the
> OSS/ALSA question, too, as only esd would need to handle the low-level
> stuff for both.

I've seen repeated statments that esd is real-time hostile.  I don't
know if this is true.  I like the *general* concept and I think it
could be made real-time and network friendly.

Eric

From - Tue Aug 17 23:43:10 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA22013
	for <slinkp@ulster.net>; Tue, 17 Aug 1999 13:36:03 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA15593 for linux-audio-dev-list; Tue, 17 Aug 1999 12:43:03 -0400
Received: from fep09-svc.tin.it (mta09-acc.tin.it [212.216.176.40]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA15590 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 17 Aug 1999 12:43:00 -0400
Received: from tin.it ([212.216.160.188]) by fep09-svc.tin.it
          (InterMail v4.01.01.02 201-229-111-106) with ESMTP
          id <19990817164017.MKEM435.fep09-svc@tin.it>
          for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Tue, 17 Aug 1999 18:40:17 +0200
Message-ID: <37B98EB4.929A6F66@tin.it>
Date: Tue, 17 Aug 1999 18:32:52 +0200
From: Maurizio Umberto Puxeddu <umbpux@tin.it>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: "linux-audio-dev@ginette.musique.umontreal.ca" 
 <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Nicola Bernardini's sound file library  
 comments
References: <Pine.LNX.4.10.9908161941590.212-100000@ax-nicb.axnet.it> <37B935F4.641DEA7B@zip.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 9eeec6d5f431291e8d942fe8b824bdb0

Hello Erik. Hello all.

I'd like only to express my modest opinion, hoping you don't take
it as void critics.

Like resampling, there are other services that you probably included or
will include in your library (various sample type conversions, channel
mixing/splitting), that could be used outside the sound file I/O
context. It would be nice if the API permitted, say, to convert an audio
buffer that the application just received from the audiocard's DAC and
so on.
Abstract Audio was growing this way.
Maybe I'm boring but: your work has some points of contact with other
kind of audio libraries (thinking of ESD, sox, networked audio and the
library developed by the music-dsp people), why duplicate the code
(=time spent, bugs, etc.)?

Such kind of modular approach could have nice side-effects. For example:
I almost always use C++ and would like a real object oriented API for an
audio file library, so I could think of writing it on top of your one (I
really don't like to abort my projects...).

Erik de Castro Lopo wrote:
> [...snip...]  
> Is there documentation on SGI's implementation somewhere?
When I was working to Abstract Audio, Michael Pruett kindly sent me a
copy of the SGI IRIX audio file library man pages. Recently I saw that
he put a link to a downloadable copy of the same docs in the AFL home
page:

http://www.68k.org/~michael/audiofile

Hope this helps. Good work.

Maurizio Umberto Puxeddu

From - Tue Aug 17 23:43:14 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA12433
	for <slinkp@ulster.net>; Tue, 17 Aug 1999 16:21:40 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA15815 for linux-audio-dev-list; Tue, 17 Aug 1999 15:23:29 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA15812 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 17 Aug 1999 15:23:26 -0400
Received: from debian (d212-151-33-187.swipnet.se [212.151.33.187]) 
          by mb05.swip.net (8.8.8/8.8.8) with ESMTP 
          id VAA25146; 
          Tue, 17 Aug 1999 21:20:43 +0200 (MET DST)
Received: from debian.mbox314.swipnet.se (really [127.0.0.1]) by debian
	via in.smtpd with esmtp (ident root using rfc1413)
	id <m11Gokh-0017r0C@debian> (Debian Smail3.2.0.101)
	for <azygmun@bgnet.bgsu.edu>; Tue, 17 Aug 1999 21:18:31 +0200 (CEST) 
Message-Id: <m11Gokh-0017r0C@debian>
Date: Tue, 17 Aug 1999 21:18:24 +0200 (CEST)
From: reine@mbox314.swipnet.se
Reply-To: reine@mbox314.swipnet.se
Subject: Re: [linux-audio-dev] Re: Mix
To: azygmun@bgnet.bgsu.edu
cc: linux-audio-dev@ginette.musique.umontreal.ca
In-Reply-To: <Pine.LNX.4.10.9908170938480.9194-100000@mustec.bgsu.edu>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id VAA25146
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id QAA12433
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 50aedacd01558dcae13dec5d0f99adde

On 17 Aug, Adam Zygmunt wrote:
 
> I realize this was discussed a little while back, but what version of
> lesstif is best for Mix? I've tried .87 so far, and although it compiles
> fine, the display was kind of screwed. Everything was crammed on the left
> side, with lots of blank on the right. Not to mention the lesstif file
> browser was as tricky as always (i.e. not quite resizing itself properly,
> needs REALLY FAST double-clicks, and so on). I wasn't able to play back
> anything, either, but then I probably just didn't have something checked.
> By the way, how does mix handle stereo files? The bussing for that on
> loading isn't especially clear.

I'm using lesstif-0.88.9, the latest a week or two ago.
Mix starts up with a size of 1169x100.

I have a halv slider on the top that I guess was placed between
the rec-button an the magnifying-glass-button.

I also have the extra silder by each channel.
The line that follows the sound while playing goes backwards.

Just a two res thought:
Has anybody suceeded in breaking up the code in smaller 
pieces (easier to understan etc...)
If not. Would it be a place to start to chop it up in
a gang of include files?
 
I guess moving to gtk whold be as laborsome as to write it
all new?

Reine

  
> 
> Thanks for any help,
> Adam Zygmunt
> 
> 
> 


From - Tue Aug 17 23:43:16 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA16427
	for <slinkp@ulster.net>; Tue, 17 Aug 1999 16:48:50 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA15874 for linux-audio-dev-list; Tue, 17 Aug 1999 16:06:26 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA15871 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 17 Aug 1999 16:06:23 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id QAA28713
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 17 Aug 1999 16:02:04 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id QAA28292; Tue, 17 Aug 1999 16:02:03 -0400 (EDT)
Date: Tue, 17 Aug 1999 16:01:56 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Nicola Bernardini's sound file library 
 comments
In-Reply-To: <37B935F4.641DEA7B@zip.com.au>
Message-ID: <Pine.GSO.4.10.9908171555510.27768-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 583da69803f3fd8cfbb8a9369d7d14f1

On Tue, 17 Aug 1999, Erik de Castro Lopo wrote:

> Is there documentation on SGI's implementation somewhere?

All of SGI's documentation, including libaf, is available at
"http://techpubs.sgi.com".

Div.


From - Tue Aug 17 23:43:17 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA19399
	for <slinkp@ulster.net>; Tue, 17 Aug 1999 17:07:38 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA15905 for linux-audio-dev-list; Tue, 17 Aug 1999 16:22:25 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id QAA15902 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 17 Aug 1999 16:22:21 -0400
From: est@hyperreal.org
Received: (qmail 20138 invoked by uid 162); 17 Aug 1999 20:19:43 -0000
Message-ID: <19990817201943.20137.qmail@hyperreal.org>
Subject: [linux-audio-dev] mp3, oolaboola & audio app architectures (fwd)
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Tue, 17 Aug 1999 13:19:43 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 8771e6064811bbbef1f678bb1baffcbd

Here's a posting of mine to freeamp-dev that might entertain some
people on this list too. :)

Eric

>From est Tue Aug 17 13:16:10 1999
Subject: mp3, oolaboola & audio app architectures
To: freeamp-dev@freeamp.org
Date: Tue, 17 Aug 1999 13:16:10 -0700 (PDT)

robert@moon.eorbit.net discourseth:
> 
> Thanks. Yes, a ui/pmo pair will do the trick. I'm currently downloading
> your program -- it sure looks sweet. 

Great..and thanks!  I'm always looking for ideas for improvements,
btw..and mp3 is the number one request.

Re the ui/pmo idea: Since I posted it I've run into a nasty technical
problem/realization: mp3 files aren't really seekable (that reservoir
of bits).  This is not good for loops, etc.  I think what I may end up
doing is decoding the mp3 into a temporary pcm file, showing how much
has been decoded in a meter and announcing `seeking' when the user
tries to go to a part that isn't decoded yet.  It's ugly, and I'd like
to be told there's a better way.

> Hmmm. After a new glib, gtk, pyhton devel I also need a new gcc. Dang.
> I thought my pet project Obsequieum was demanding... :-)

Yes, my edge bleedeth.  I was shocked when Redhat 6.0 came out
completely oola-ready. :)

> Anyway, I'd like to turn this around and have a programmatical
> interface to your program. I'd like to be able to write a plug-in for
> oolaboola, that automatically mixes two tracks together. The plugin
> could do some random mixing, maybe something fractal, and just general
> playback distortions. Sorta like Gimp for DJs?

This shouldn't be too hard.  The dsp and the gui are completely
separate programs that communicate over a pair of pipes using Scheme
symbolic expressions.  There's even a little sequencer program
included that can take time-stamped symbolic expressions (which oola
automatically logs) and drive the dsp.  The commands used are going to
change a bit, but the lexics will remain the same.  I've got a broader
vision for this Symbolic Control Protocol as something to use..well,
instead of midi. :)

> There is one problem with the xing decoder that FreeAmp uses: its not
> reentrant.

Precisely why I went for the process-per-file approach. :)

> This means that one program can only have one copy of the
> decoder running. This can be circumvented with we did this using the
> following approach:
> 
>    1) oolaboola opens freeamp with the oolaboola interface ui and the
>       oolaboola pmo. 
>    2) The oolaboola ui would not actually present any kind of UI to the
>       user. Instead it would communicate with oolabools via IPC/shared
>       memory, so that oolaboola is fully in charge of freeamp
>    3) The pmo uses shared memory base circular buffer that both freeamp
>       and oolaboola have access to.
>    4) One instance of freeamp is opened for each mp3 decode stream you
>       need.
> 
> Using freeamp instead of some mp3 decode library would also allow you to
> mix real-time MP3 streams from the web. I could envision a multi-user
> virtual jam session. Hmmmm. DJ's of the world, unite!

All this is completely consonant with some of my long-term
architectual aims.  They involve resources identified by URLs that you
can open and talk to via Symbolic Control Protocol.  Streaming
connections can then be negotiated to use either tcp and network-order
data or (if on the same machine) shared memory.  Applications could
figure out where to send output by looking at the SOUNDOUT environment
variable, etc.

> > * How come freeamp-1.3.0 doesn't have a -pmo option..is there one in
> >   2?  In any case, it looks easy to add.
> 
> There is -- check out .freeamp_prefs in your home dir. We could easily
> add a command line option for that.

Actually, I knew I could always lie about HOME..but it looked like an
option would be easy.

On another note, have you considered 3dnow! optimizations for freeamp?
I've been playing with 3dnow! recently and it's incredibly effective
(like 3-fold speed-ups).

Best,

Eric

From - Tue Aug 17 23:43:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA28193
	for <slinkp@ulster.net>; Tue, 17 Aug 1999 18:09:28 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA16024 for linux-audio-dev-list; Tue, 17 Aug 1999 17:32:12 -0400
Received: from ax-nicb.axnet.it (ax-nicb.axnet.it [194.184.60.149]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA16020 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 17 Aug 1999 17:32:00 -0400
Received: (from nicb@localhost)
	by ax-nicb.axnet.it (8.8.7/8.8.7) id XAA03455;
	Tue, 17 Aug 1999 23:15:03 +0200
Date: Tue, 17 Aug 1999 23:15:03 +0200 (CEST)
From: Nicola Bernardini <nicb@axnet.it>
To: Guenter Geiger <geiger@epy.co.at>
cc: Linux Audio Development Mailing list <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Mix
In-Reply-To: <14265.2952.202206.74616@gige>
Message-ID: <Pine.LNX.4.10.9908172313130.2702-100000@ax-nicb.axnet.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1d5e9c6bbe87b44a96163262e3c603d2

Dear Guenter,

Today, Guenter Geiger mi scrisse cio` che segue:
	
[snip - replying on mix and csound in another post]
GG> 3) MIX and CVS
GG>    Someone willing to setup anonymous CVS for Mix, so that more than
GG>    one person can hack on the same source ?

as I said, I can setup an anonymous CVS for Mix around the 26th
of August. I will do that unless anybody is seriously against it.

ciao

Nicola

------------------------------------------------------------------------
Nicola Bernardini
E-mail: nicb@axnet.it
 
Re graphics: A picture is worth 10K words -- but only those to describe
the picture.  Hardly any sets of 10K words can be adequately described
with pictures.

From - Tue Aug 17 23:43:22 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA29436
	for <slinkp@ulster.net>; Tue, 17 Aug 1999 18:19:51 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA16047 for linux-audio-dev-list; Tue, 17 Aug 1999 17:38:37 -0400
Received: from ax-nicb.axnet.it (ax-nicb.axnet.it [194.184.60.149]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA16044 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 17 Aug 1999 17:38:26 -0400
Received: (from nicb@localhost)
	by ax-nicb.axnet.it (8.8.7/8.8.7) id XAA03484;
	Tue, 17 Aug 1999 23:20:33 +0200
Date: Tue, 17 Aug 1999 23:20:32 +0200 (CEST)
From: Nicola Bernardini <nicb@axnet.it>
To: Dave Phillips <dlphilp@bright.net>
cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Mix
In-Reply-To: <37B8B431.F636420D@bright.net>
Message-ID: <Pine.LNX.4.10.9908172315570.2702-100000@ax-nicb.axnet.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0d0396bad5847dc6fa90c672261c52f2

Dear Dave, dear all,

Yesterday, Dave Phillips mi scrisse cio` che segue:

[snip]
DP> As it stands now Mix merely calls Csound in this manner (in mix.c):
DP> 
DP>        if (catchup==0) {
DP>          sprintf(streng, "csound -o devaudio %s.orc %s.sco &", value,
DP> value);
DP>          system(streng);
DP>        }
DP>        break;
DP> 
DP> Crude, yes. But it is dependent on multiple processes being able to
DP> access the same device, something apparently easy for SGI iron but not
DP> so simple under Linux. I understand that EsounD (esd) does it, but I
DP> think that Csound would have to become esd-aware, and I don't know how
DP> that's done.

well: my idea is that we should first try to do what Mix was meant to
do, and if I understand correctely that was to mix (offline and non in
real-time), a number of audio track. I was thinking maybe we should offer
some form of 'previewing' the mix, without guaranteeing glitches etc.
Then, csound could come in as an effect for a given track, working in
non real time, saving to a temporary file and reloading the track
with the result of it. This should be easy to implement. Then, when
Guenter is done defining the plug-in architecture, we could speculate
some more on it. How about that as a development path? (there are zillion
of other things to do, of course...)

ciao

Nicola

------------------------------------------------------------------------
Nicola Bernardini
E-mail: nicb@axnet.it
 
Re graphics: A picture is worth 10K words -- but only those to describe
the picture.  Hardly any sets of 10K words can be adequately described
with pictures.

From - Tue Aug 17 23:43:23 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA29476
	for <slinkp@ulster.net>; Tue, 17 Aug 1999 18:20:17 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA16051 for linux-audio-dev-list; Tue, 17 Aug 1999 17:39:17 -0400
Received: from ax-nicb.axnet.it (ax-nicb.axnet.it [194.184.60.149]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA16048 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 17 Aug 1999 17:39:05 -0400
Received: (from nicb@localhost)
	by ax-nicb.axnet.it (8.8.7/8.8.7) id XAA03510;
	Tue, 17 Aug 1999 23:25:06 +0200
Date: Tue, 17 Aug 1999 23:25:06 +0200 (CEST)
From: Nicola Bernardini <nicb@axnet.it>
To: Adam Zygmunt <azygmun@bgnet.bgsu.edu>
cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Mix
In-Reply-To: <Pine.LNX.4.10.9908170938480.9194-100000@mustec.bgsu.edu>
Message-ID: <Pine.LNX.4.10.9908172321180.2702-100000@ax-nicb.axnet.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 6131332aa06581fca26c4226b700cad5

Today, Adam Zygmunt mi scrisse cio` che segue:

> 
> 
> On Mon, 16 Aug 1999, Dave Phillips wrote:
> 
> I realize this was discussed a little while back, but what version of
> lesstif is best for Mix? I've tried .87 so far, and although it compiles
> fine, the display was kind of screwed. Everything was crammed on the left
> side, with lots of blank on the right. Not to mention the lesstif file
> browser was as tricky as always (i.e. not quite resizing itself properly,
> needs REALLY FAST double-clicks, and so on). I wasn't able to play back
> anything, either, but then I probably just didn't have something checked.
> By the way, how does mix handle stereo files? The bussing for that on
> loading isn't especially clear.

Did you put the Mix app-defaults file in the /usr/X11/lib/X11/app-defaults
directory? I tried first without it and it gave exactly the same behaviour
that you describe. After putting it there behaviour was much better.
Another question I have is: is Mix supposed to work in real time or,
as far as I could see, it mixes offline (which is fine with me)?

[snip]
>     By the way, does mix allow one to cue up the various audio files at
> different times, or do they all start at once? Sorry if this is a stupid
> question, but I haven't had much luck getting it to run properly. Looks
> quite a bit more useful than it did a few months ago, though.

no. If you click on the track a dialog box comes up and you can select
the starting time.

ciao

Nicola

------------------------------------------------------------------------
Nicola Bernardini
E-mail: nicb@axnet.it
 
Re graphics: A picture is worth 10K words -- but only those to describe
the picture.  Hardly any sets of 10K words can be adequately described
with pictures.

From - Tue Aug 17 23:43:21 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA28356
	for <slinkp@ulster.net>; Tue, 17 Aug 1999 18:10:38 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA16028 for linux-audio-dev-list; Tue, 17 Aug 1999 17:32:40 -0400
Received: from ax-nicb.axnet.it (ax-nicb.axnet.it [194.184.60.149]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA16025 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 17 Aug 1999 17:32:31 -0400
Received: (from nicb@localhost)
	by ax-nicb.axnet.it (8.8.7/8.8.7) id XAA03526;
	Tue, 17 Aug 1999 23:28:09 +0200
Date: Tue, 17 Aug 1999 23:28:09 +0200 (CEST)
From: Nicola Bernardini <nicb@axnet.it>
To: Maurizio Umberto Puxeddu <umbpux@tin.it>
cc: "linux-audio-dev@ginette.musique.umontreal.ca" <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Nicola Bernardini's sound file library  
 comments
In-Reply-To: <37B98EB4.929A6F66@tin.it>
Message-ID: <Pine.LNX.4.10.9908172325250.2702-100000@ax-nicb.axnet.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: bdd19dcebe60d69bdeccb4e59cd4fe84

Dear Maurizio, dear all,

Today, Maurizio Umberto Puxeddu mi scrisse cio` che segue:

[snip]
MUP> Such kind of modular approach could have nice side-effects. For example:
MUP> I almost always use C++ and would like a real object oriented API for an
MUP> audio file library, so I could think of writing it on top of your one (I
MUP> really don't like to abort my projects...).

Well, Erik just said he never used C++ and does'nt particularly want to.
So *here* is a nice collaborative project: *you* do libsndfile++,
a C++ wrapper around Erik's library. How about it? I think *this* is
the way of cooperating to get a really nice product: each one of us
puts in whatever she/he likes best...

ciao

Nicola
------------------------------------------------------------------------
Nicola Bernardini
E-mail: nicb@axnet.it
 
Re graphics: A picture is worth 10K words -- but only those to describe
the picture.  Hardly any sets of 10K words can be adequately described
with pictures.

From - Wed Aug 18 01:21:10 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA15410
	for <slinkp@ulster.net>; Wed, 18 Aug 1999 01:24:52 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA16690 for linux-audio-dev-list; Wed, 18 Aug 1999 00:51:47 -0400
Received: from ax-nicb.axnet.it (ax-nicb.axnet.it [194.184.60.149]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA16687 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 18 Aug 1999 00:51:34 -0400
Received: (from nicb@localhost)
	by ax-nicb.axnet.it (8.8.7/8.8.7) id XAA03547;
	Tue, 17 Aug 1999 23:31:43 +0200
Date: Tue, 17 Aug 1999 23:31:43 +0200 (CEST)
From: Nicola Bernardini <nicb@axnet.it>
To: reine@mbox314.swipnet.se
cc: Linux Audio Development Mailing list <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Mix
In-Reply-To: <m11Gokh-0017r0C@debian>
Message-ID: <Pine.LNX.4.10.9908172328260.2702-100000@ax-nicb.axnet.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by nerf.ulster.net id BAA15410
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: bb0314b0711a99549b1a55a617622430

Today, reine@mbox314.swipnet.se mi scrisse cio` che segue:

[snip]
> Just a two res thought:
> Has anybody suceeded in breaking up the code in smaller 
> pieces (easier to understan etc...)
> If not. Would it be a place to start to chop it up in
> a gang of include files?

I saw the files: > 200k c files is really big and it would be
nice to break it up. It is a fairly delicate matter, however,
and I'm always of the long-lived opinion: 'if it's not broken,
don't fix it'...

> I guess moving to gtk whold be as laborsome as to write it
> all new?

I must confess I thought of that too. Working on Mix on a 800x600
laptop is quite a task, and maybe we should have more sophisticated
set of widgets. And, also because of GPL, gtk seems the choice.

ciao

Nicola

------------------------------------------------------------------------
Nicola Bernardini
E-mail: nicb@axnet.it
 
Re graphics: A picture is worth 10K words -- but only those to describe
the picture.  Hardly any sets of 10K words can be adequately described
with pictures.

From - Tue Aug 17 23:43:25 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA32730
	for <slinkp@ulster.net>; Tue, 17 Aug 1999 18:48:32 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA16138 for linux-audio-dev-list; Tue, 17 Aug 1999 18:11:13 -0400
Received: from gate.suse.cz (perex.cb.cesnet.cz [194.212.165.105]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA16135 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 17 Aug 1999 18:11:10 -0400
Received: from localhost (perex@localhost)
	by gate.suse.cz (8.8.8/8.8.8) with ESMTP id AAA13217;
	Wed, 18 Aug 1999 00:06:36 +0200
Date: Wed, 18 Aug 1999 00:06:35 +0200 (MEST)
From: Jaroslav Kysela <perex@suse.cz>
To: alsa-devel@alsa-project.org
cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] ALSA PCM v2 API proposal
Message-ID: <Pine.LNX.4.05.9908172354030.9977-100000@gate.suse.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 0fa57e53279ee25f7aa16bdbe7e44439

Hello,

	I just put a first revision of the proposal for ALSA PCM version 2
API to the ALSA WWW site. This proposal tries to solve all things
collected in the previous time with the current PCM interface. Please,
it's probably last time to do some big conceptual changes on this
interface, thus I'm asking for a big attention for this issue. Thank you.

	The API should be described in more details. I'll put an
explanation for a specific thing, when someone requests. The proposal is
not still closed, if someone has a better idea, I'd probably accept it.

URL:	http://www.alsa-project.org/proposals/pcm.txt

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA project  http://www.alsa-project.org

From - Tue Aug 17 23:43:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA02634
	for <slinkp@ulster.net>; Tue, 17 Aug 1999 19:09:42 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA16168 for linux-audio-dev-list; Tue, 17 Aug 1999 18:33:00 -0400
Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA16165 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 17 Aug 1999 18:32:56 -0400
Received: from hendrix (krusty49.zip.com.au [61.8.16.81])
	by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id IAA25232;
	Wed, 18 Aug 1999 08:19:44 +1000 (EST)
Message-ID: <37B9E266.1AE1FB18@zip.com.au>
Date: Wed, 18 Aug 1999 08:29:58 +1000
From: Erik de Castro Lopo <erikd@zip.com.au>
Organization: Eric Conspiracy Secret Labs
X-Mailer: Mozilla 3.04Gold (X11; I; Linux 2.2.11 i586)
MIME-Version: 1.0
To: Nicola Bernardini <nicb@axnet.it>
CC: umbpux@tin.it, linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Nicola Bernardini's sound file library    comments
References: <Pine.LNX.4.10.9908172325250.2702-100000@ax-nicb.axnet.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: cd05ed61a287302b418323c19117b6d3

Nicola Bernardini wrote:
> 
> Well, Erik just said he never used C++ and does'nt particularly want to.
> So *here* is a nice collaborative project: *you* do libsndfile++,
> a C++ wrapper around Erik's library. How about it? I think *this* is
> the way of cooperating to get a really nice product: each one of us
> puts in whatever she/he likes best...

I agree completely. A C++ wrapper around libsndfile would be a good
idea and I think it should be written by someone who is a more staunch 
advocate of C++ than me. Once done, it would mean that nobody ever bugs 
me about a C++ interface to libsndfile :-). 

I do however use C++ where C++ has definite, undeniable advantages over C 
(like when I need templates or operator overloading), but for most of my 
own projects I usually don't need the extra features and find C easier to 
work with. Hopefully this won't start some HTTNSTE (huge thread that never 
seems to end (tm)) like it did in some of the Linux newsgroups recently.

Maurizio's ideas for features like channel splitting are also worth
pursuing after the rest of the functionality is tied down. I remember
some past correspondance with Maurizio where I stated I wasn't too
keen on adding sample rate convert to libsndfile. I am now actively
working on it, so I think just about anything is possible.

Ciao,
Erik
-- 
+-------------------------------------------------+
     Erik de Castro Lopo     erikd@zip.com.au
+-------------------------------------------------+
"Remember that the P in Perl stands for Practical.  The
P in Python doesn't seem to stand for anything."
 --Randal Schwartz in <8cemsabtef.fsf@gadget.cscaper.com>

From - Tue Aug 17 23:52:15 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA07377
	for <slinkp@ulster.net>; Tue, 17 Aug 1999 23:55:02 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA16566 for linux-audio-dev-list; Tue, 17 Aug 1999 23:16:19 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA16563 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 17 Aug 1999 23:16:16 -0400
Received: from bright.net (find-cas2-cs-14.dial.bright.net [209.143.26.168])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id XAA26408;
	Tue, 17 Aug 1999 23:13:34 -0400 (EDT)
Message-ID: <37BA2B36.AFC0CA63@bright.net>
Date: Tue, 17 Aug 1999 23:40:38 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Adam Zygmunt <azygmun@bgnet.bgsu.edu>
CC: Nicola Bernardini <nicb@axnet.it>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Mix
References: <Pine.LNX.4.10.9908170938480.9194-100000@mustec.bgsu.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: a53e5617a3ef54f58a1adf3a7b26b0e5

Adam Zygmunt wrote:

> I realize this was discussed a little while back, but what version of
> lesstif is best for Mix? I've tried .87 so far, and although it compiles
> fine, the display was kind of screwed.

As Nicola already wrote, the resource file might make a great
difference. However, you may have to play with its location a bit. If
it's not recognized in the usual spot, try dropping into /root.

> Speaking of lesstif, any ambitious person out there up for ditching it
> from the mix code?

Good idea, probably a bitch to do. Reine Jonsson would like to see the
Mix code modularized, it's almost as sprawling as Csound. ;)   Well, not
quite...

> I haven't looked at its library, but I can't imagine esound support would
> be too tricky to add. It might be nice...

I agree. Its operation is transparent: 'esd &' does it here. I haven't
really stressed it, and I'd like to try its limits. Any suggestions ?

> By the way, does mix allow one to cue up the various audio files at
> different times, or do they all start at once? Sorry if this is a stupid
> question, but I haven't had much luck getting it to run properly. Looks
> quite a bit more useful than it did a few months ago, though.

Not sure I understand, Adam. I can place soundfiles all over the screen,
and they start when they're supposed to, but I suspect you're asking
about something else, yes ?

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Wed Aug 18 00:28:07 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA10179
	for <slinkp@ulster.net>; Wed, 18 Aug 1999 00:22:21 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA16606 for linux-audio-dev-list; Tue, 17 Aug 1999 23:45:54 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA16603 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 17 Aug 1999 23:45:51 -0400
Received: from bright.net (find-cas2-cs-14.dial.bright.net [209.143.26.168])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id XAA07025;
	Tue, 17 Aug 1999 23:43:10 -0400 (EDT)
Message-ID: <37BA3226.DC998F57@bright.net>
Date: Wed, 18 Aug 1999 00:10:14 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Nicola Bernardini <nicb@axnet.it>
CC: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Mix
References: <Pine.LNX.4.10.9908172315570.2702-100000@ax-nicb.axnet.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 08c7b9854e8cf6e1c461f4ec8ef5f9ca

Nicola Bernardini wrote:

> well: my idea is that we should first try to do what Mix was meant to
> do, and if I understand correctely that was to mix (offline and non in
> real-time), a number of audio track(s).

Agreed, definitely.

We need to enable flawless recording, and I think support for edit by
regions is important. I would consider these to be basic operations.

> I was thinking maybe we should offer
> some form of 'previewing' the mix, without guaranteeing glitches etc.
> Then, csound could come in as an effect for a given track, working in
> non real time, saving to a temporary file and reloading the track
> with the result of it. This should be easy to implement. Then, when
> Guenter is done defining the plug-in architecture, we could speculate
> some more on it. How about that as a development path? (there are zillion
> of other things to do, of course...)

This is certainly going further than the original implementation of the
Csound variable. I'm still pondering the possibilities of simply being
able to trigger a realtime Csound performance in the context of a mix.
As Gunter suggested, at first look it's hard to see the utility of such
a device: the play will not be in sync, it will not be recorded into the
mix, and its action will not be visible. Yet the experimentalist in me
has to wonder what could be done with it. A random-MIDI orc/sco output ?
Some other random process ? Spoken instructions on using Mix ? Given
Csound's flexibility there must be *some* good purpose to its use as a
Mix variable.

And I do like the fact that other NoTAM software is Csound-aware...

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Wed Aug 18 01:21:08 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA15217
	for <slinkp@ulster.net>; Wed, 18 Aug 1999 01:22:33 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA16671 for linux-audio-dev-list; Wed, 18 Aug 1999 00:44:49 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA16668 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 18 Aug 1999 00:44:47 -0400
Received: from ulster.net (port55.king.ulster.net [208.242.160.56])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id AAA12953;
	Wed, 18 Aug 1999 00:55:27 -0400
Message-ID: <37BA3B24.815E42D4@ulster.net>
Date: Wed, 18 Aug 1999 00:48:36 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Nicola Bernardini <nicb@axnet.it>
CC: Adam Zygmunt <azygmun@bgnet.bgsu.edu>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Mix
References: <Pine.LNX.4.10.9908172321180.2702-100000@ax-nicb.axnet.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 65214ea89c27c6c2c948cc2e6fae61be

Nicola Bernardini wrote:
> 
> Today, Adam Zygmunt mi scrisse cio` che segue:
> > By the way, how does mix handle stereo files? The bussing for that on
> > loading isn't especially clear.

I never really understood it either. It seems to me that there are two
different behaviors for stereo files; ideally, mix should support both:
1) Treat file basically as two mono files with a linked start time.
Panning is totally independent for the two channels. Maybe files should
even go in separate Mix channels onscreen?
2) Treat file as one file, where the pan graph pans between the two
channels of the soundfile.

> [snip]
> >     By the way, does mix allow one to cue up the various audio files at
> > different times, or do they all start at once? Sorry if this is a stupid
> > question, but I haven't had much luck getting it to run properly. Looks
> > quite a bit more useful than it did a few months ago, though.
> 
> no. If you click on the track a dialog box comes up and you can select
> the starting time.

And don't forget, you can also click and drag on the sounds to change
start time after you've loaded them.
 

----------------    paul winkler    ------------------

From - Wed Aug 18 01:41:07 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA16479
	for <slinkp@ulster.net>; Wed, 18 Aug 1999 01:41:06 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA16703 for linux-audio-dev-list; Wed, 18 Aug 1999 00:58:18 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA16700 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 18 Aug 1999 00:58:15 -0400
Received: from ulster.net (port55.king.ulster.net [208.242.160.56])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id BAA14122;
	Wed, 18 Aug 1999 01:09:06 -0400
Message-ID: <37BA3E57.DC9D4AE0@ulster.net>
Date: Wed, 18 Aug 1999 01:02:15 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: est@hyperreal.org
CC: eli+@cs.cmu.edu, linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] resampling
References: <19990816161506.11225.qmail@hyperreal.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0cd072a98d14eddc44ff593287cdc247

est@hyperreal.org wrote:
> 
(snip)
> Me too!  I haven't even tested what quadratic (I assume that comes
> under `Lagrange-polynomial'?) gets me over linear.

I'm too ignorant to know the difference between all these algorithms by
name. But a while ago, out of curiosity, I did some testing of Csound's
interpolation routines. I just compared the output quality of a really
small function table (like, 8 points) sampled by oscil (no
interpolation), oscili (linear), and oscil3 ("a cubic interpolation
algorithm" -- is that related to "quadratic"? I stopped taking math
after 10th grade... too lazy, I guess... jazz band was more fun at the
time).

oscil3 sounded by far the best of the three. I used snd to see what the
output waveforms looked like. Visual inspection of the waveforms showed
that oscil was faithfully making great big stair-steps; oscili was
drawing straight line segments just like you would expect; and oscil3's
output sure looked a lot like a perfect sine wave. The difference in
audible noise level between oscili and oscil3 was pretty dramatic (but
then, I started with garbage).

> Eli Brandt discourseth:
> > An interesting comparison of sox's implementation of linear, sinc, and
> > polyphase resampling:
> >         http://eakaw2.et.tu-dresden.de/~andreas/resample/resample.html
> 
> Thanks for pointing this out.

Yeah! This is a great link for the audio-quality-HOWTO. Looks like Sox
can finally do decent-quality resampling!

-- 

----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Thu Aug 19 01:03:36 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA08713
	for <slinkp@ulster.net>; Thu, 19 Aug 1999 01:09:17 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA18702 for linux-audio-dev-list; Thu, 19 Aug 1999 00:23:25 -0400
Received: from ax-nicb.axnet.it (ax-nicb.axnet.it [194.184.60.149]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA18699 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 19 Aug 1999 00:17:11 -0400
Received: (from nicb@localhost)
	by ax-nicb.axnet.it (8.8.7/8.8.7) id HAA04536;
	Wed, 18 Aug 1999 07:29:04 +0200
Date: Wed, 18 Aug 1999 07:29:04 +0200 (CEST)
From: Nicola Bernardini <nicb@axnet.it>
To: Dave Phillips <dlphilp@bright.net>
cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Mix
In-Reply-To: <37BA3226.DC998F57@bright.net>
Message-ID: <Pine.LNX.4.10.9908180703420.2702-100000@ax-nicb.axnet.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: a1b59b1fafe45e8a64d6a2ca96f2ee09

Today, Dave Phillips mi scrisse cio` che segue:

[snip]
DP> We need to enable flawless recording, and I think support for edit by
DP> regions is important. I would consider these to be basic operations.

You see, Dave: I think we should not fall into the 'integrated solution'
trap. If we decide that Mix is a multi-track editor that basically
handles files, I'd leave the recording/playback functions to some
other processes, possibly callable from Mix and running in background 
while you do other things. Other platforms (Mac, Win) cannot do this well
and are constrained into monolicithy. I think that to be flawless we
must be as simple as possible, and thanks god linux allows us to do so.
I can see a *fairly* easy task: build a separate previewer which accepts
a text file prepared by Mix, reads it and runs all operations requested
while playing (again - no guarantees on no glitches). It is easy to
do all the volume and panning job, a little more difficult to run
the effects - but if Mix is modularized and a library is built out
of it, here comes the previewer with effects et al. There are some
good reasons, I think, to keep Mix out of real time - the first one
I could really use is to have infinite tracks, or infinite stack
of effects, etc. (up to memory limits of course). These are things
no CoolEdit nor ProTools nor whatever
can do because they always think in terms of real-time (while most
of the time work is done offline - just previewing is done in real-time).
Speaking of which, and on the other thread of IDE drives, linux drivers
etc. (sorry for mixing threads), while we should of course push the
issue on kernel developers (especially considering the UDMA/66
interface etc.), we should not ignore the fact that software like
ProTools is extremely bitchy about what kind of disk drive you have
(generally they want UW SCSI 10000 RPMs: fairly expensive stuff,
and certainly nothing less than UW 7200 RPMs). The moral of the story
is: if you want real-time, your hardware (not the software) is going
to be the limit. The plus I feel linux has (and one of the main reasons
why I'm a linux-only stalinist) is that with linux you may live
your life more relaxed if you wish to.

Now, regions are another story. I'd really like to see some serious
region editing a` la ProTools in Mix. I've worked with ProTools quite
a lot and if nobody has done anything about it by the end of september
I might give it a try (god knows I should not promise anything...).

[snip]
DP> This is certainly going further than the original implementation of the
DP> Csound variable. I'm still pondering the possibilities of simply being
DP> able to trigger a realtime Csound performance in the context of a mix.

But I think that this is *easier* and actually more powerful than what
the original implementation was trying to do.

DP> As Gunter suggested, at first look it's hard to see the utility of such
DP> a device: the play will not be in sync, it will not be recorded into the
DP> mix, and its action will not be visible. Yet the experimentalist in me
DP> has to wonder what could be done with it. A random-MIDI orc/sco output ?
DP> Some other random process ? Spoken instructions on using Mix ? Given
DP> Csound's flexibility there must be *some* good purpose to its use as a
DP> Mix variable.

There's a number of things we should ask Dr.Hammer... The csound variable,
the networking stuff: what were they meant to do? (hoping that he
remembers - if it was me, after two months I'd already forgotten...)

DP> And I do like the fact that other NoTAM software is Csound-aware...

oh, I do too... :)

ciao

Nicola
------------------------------------------------------------------------
Nicola Bernardini
E-mail: nicb@axnet.it
 
Re graphics: A picture is worth 10K words -- but only those to describe
the picture.  Hardly any sets of 10K words can be adequately described
with pictures.

From - Wed Aug 18 06:35:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA29795
	for <slinkp@ulster.net>; Wed, 18 Aug 1999 06:33:15 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA17235 for linux-audio-dev-list; Wed, 18 Aug 1999 05:43:34 -0400
Received: from fep04-svc.tin.it (mta04-acc.tin.it [212.216.176.35]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA17232 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 18 Aug 1999 05:43:31 -0400
Received: from tin.it ([212.216.160.16]) by fep04-svc.tin.it
          (InterMail v4.01.01.02 201-229-111-106) with ESMTP
          id <19990818094049.LGGY11717.fep04-svc@tin.it>;
          Wed, 18 Aug 1999 11:40:49 +0200
Message-ID: <37BA7DE2.10051D75@tin.it>
Date: Wed, 18 Aug 1999 11:33:22 +0200
From: Maurizio Umberto Puxeddu <umbpux@tin.it>
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Erik de Castro Lopo <erikd@zip.com.au>
CC: Nicola Bernardini <nicb@axnet.it>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Nicola Bernardini's sound file library 
 comments
References: <Pine.LNX.4.10.9908172325250.2702-100000@ax-nicb.axnet.it> <37B9E266.1AE1FB18@zip.com.au>
Content-Type: text/plain; charset=x-user-defined
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1f0cf938b40822e1255f41c0335cf9d0

Hello Erik and Nicola. Hello all.

I think my messange has been partially misunderstood (due to my poor
english! :).

I was not (not only) asking Erik to insert one or two features. I meant:
you have the code for doing this operation while reading/writing a file
but an application may have to do the same with audio data resident in
memory. Why
don't include in your API functions like

swap_word_endianess(word_t *, size_t);
...

convert_double_to_ulaw8(double *, size_t, byte_t *);
...

word_t *resample(word_t *, size_t, double, double);

so that an application needn't to link two libraries for doing the same
operation in different contexts? Depending on your implementation this
may require little or no modifications.

I donwloaded last version of libsndfile.

Is the documentation of your API up to date?
If yes I'd like to point some things that, as far as I understand, are
important:

1) There is no format-independent way to know the file length (/duration
in seconds) other than waiting for EOF.
2) Some applications (see Csound) may need to update the file header
each time you perform a write operation (so that B can read while A is
writing).
3) Some functions in audio editors are easy to implement in "direct
mode" if the file is accessible in read/write mode.
3bis) It is possible to append data to a file with your API?
4) Why don't you make the I/O operations frame-based instead of
requiring that
"items" to be an integer times the channels number? (you did it for seek
but not for read and write)

I think you should decide about 4) now that libsndfile is still no so
popular... :)

This is just one of the two way I'd like to help libsndfile. The other
will be WRITING THE C++ API. Not now, because I have to finish some
other stuff but I'll first start discussing details with Erik. 

About channel mixing/splitting:
I could adapt and send some code from Abstract Audio.
It works this way: the library stores a mixer pointer, defined as a NxM
matrix where N is the virtual channel number and M is the real channel
number.

mixer[i][j] is the contribute from the source channel j to the virtual
channel i

vchannel[i] = mixer[i][j] * rchannel[j]      (using Einstein notation)

During a read or write operation the library calls the mixing routine if
the channel numbers don't match. If at open time the application don't
indicate a mixer (that is, the mixer pointer in the handle structure is
NULL), the library creates a default mixer that mixes channels in equal
parts.
I should have code for mixing and for default mixer generation. The
mixing routine has code to handle efficiently common cases like 2x1 or
1x2 mixers and general code for the remaining cases.
Of course, I'd add a general mix_buffer() call too.
Yes, it is straightforward but it is done once for all and having a
"standard" way to mix, someone out there could think of, say, writing a
Gtk/Gtk-- widget that handles mixers matrix elements visually.

A presto,
Maurizio Umberto Puxeddu

From - Wed Aug 18 13:38:40 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA00319
	for <slinkp@ulster.net>; Wed, 18 Aug 1999 07:23:56 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA17321 for linux-audio-dev-list; Wed, 18 Aug 1999 06:30:10 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA17313 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 18 Aug 1999 06:30:03 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m11H2xt-000dxrC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Wed, 18 Aug 1999 12:29:05 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Wed, 18 Aug 1999 12:29:05 +0200 (CEST)
To: reine@mbox314.swipnet.se
Cc: azygmun@bgnet.bgsu.edu, linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Mix
In-Reply-To: <m11Gokh-0017r0C@debian>
References: <Pine.LNX.4.10.9908170938480.9194-100000@mustec.bgsu.edu>
	<m11Gokh-0017r0C@debian>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14266.35201.333928.252789@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id HAA00319
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f657a93c92f1eaeeb96651a18c6ba0f3

reine@mbox314.swipnet.se writes:
 > I'm using lesstif-0.88.9, the latest a week or two ago.
 > Mix starts up with a size of 1169x100.
 > 
 > I have a halv slider on the top that I guess was placed between
 > the rec-button an the magnifying-glass-button.
 > 
 > I also have the extra silder by each channel.
 > The line that follows the sound while playing goes backwards.
 > 

 Huh ? Funny 

 I'm using 0.88.9 too. Have you loaded the resources ?
 To be sure you have the correct resources do 

 > xrdb -merge Mix.linux
 
 We should hardcode a default resource set to get rid of these oddities. 

 > Just a two res thought:
 > Has anybody suceeded in breaking up the code in smaller 
 > pieces (easier to understan etc...)
 > If not. Would it be a place to start to chop it up in
 > a gang of include files?

 I already started at some places where I thought it is necessary.
 I will get rid of the effects, when the plugin API and implementation
 are ready.

 There's still a lot of duplicated code in there.

 >  
 > I guess moving to gtk whold be as laborsome as to write it
 > all new?
 > 

 Definitely ! I'm only planning to work on mix until the remaining
 bugs are fixed and the plugins are working ... then on to a project 
 from scratch.

 Guenter

From - Wed Aug 18 13:38:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA02937
	for <slinkp@ulster.net>; Wed, 18 Aug 1999 07:55:34 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id HAA17369 for linux-audio-dev-list; Wed, 18 Aug 1999 07:05:33 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA17366 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 18 Aug 1999 07:05:28 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m11H3W2-000dyrC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Wed, 18 Aug 1999 13:04:22 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Wed, 18 Aug 1999 13:04:21 +0200 (CEST)
To: Nicola Bernardini <nicb@axnet.it>
Cc: Dave Phillips <dlphilp@bright.net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Mix
In-Reply-To: <Pine.LNX.4.10.9908172315570.2702-100000@ax-nicb.axnet.it>
References: <37B8B431.F636420D@bright.net>
	<Pine.LNX.4.10.9908172315570.2702-100000@ax-nicb.axnet.it>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14266.37084.148554.493818@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 760c9493a73d292868a3f19d97c160fd

Nicola Bernardini writes:
 > well: my idea is that we should first try to do what Mix was meant to
 > do, and if I understand correctely that was to mix (offline and non in
 > real-time), a number of audio track. I was thinking maybe we should offer
 > some form of 'previewing' the mix, without guaranteeing glitches etc.
 > Then, csound could come in as an effect for a given track, working in
 > non real time, saving to a temporary file and reloading the track
 > with the result of it. This should be easy to implement. Then, when
 > Guenter is done defining the plug-in architecture, we could speculate
 > some more on it. How about that as a development path? (there are zillion
 > of other things to do, of course...)

 Nicola, 

 The "play" button is a preview. The actual mixdown is done with 
 "File->Mix to Soundfile". We should add a mixdown button somewhere to 
 make it more visible. Otherwise your suggested solution makes pretty
 much sense to me, we should do it as a first implementation.

 Guenter

From - Wed Aug 18 13:38:44 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA14732
	for <slinkp@ulster.net>; Wed, 18 Aug 1999 09:38:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA17476 for linux-audio-dev-list; Wed, 18 Aug 1999 08:55:56 -0400
Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA17473 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 18 Aug 1999 08:55:52 -0400
Received: from hendrix (stan101.zip.com.au [61.8.17.101])
	by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id WAA18747;
	Wed, 18 Aug 1999 22:42:39 +1000 (EST)
Message-ID: <37BAACA8.6FCC6ED9@zip.com.au>
Date: Wed, 18 Aug 1999 22:52:56 +1000
From: Erik de Castro Lopo <erikd@zip.com.au>
Organization: Eric Conspiracy Secret Labs
X-Mailer: Mozilla 3.04Gold (X11; I; Linux 2.2.11 i586)
MIME-Version: 1.0
To: Maurizio Umberto Puxeddu <umbpux@tin.it>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Nicola Bernardini's sound file library comments
References: <Pine.LNX.4.10.9908172325250.2702-100000@ax-nicb.axnet.it> <37B9E266.1AE1FB18@zip.com.au> <37BA7DE2.10051D75@tin.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d902f2a5529b51b65ba5db972aabe217

Maurizio Umberto Puxeddu wrote:
> 
> Hello Erik and Nicola. Hello all.
> 
> I think my messange has been partially misunderstood (due to my poor
> english! :).

I maintain that your english is very much better than my Italian. You 
have nothing to apologise for.

> I was not (not only) asking Erik to insert one or two features. I meant:
> you have the code for doing this operation while reading/writing a file
> but an application may have to do the same with audio data resident in
> memory. Why
> don't include in your API functions like
> 
> swap_word_endianess(word_t *, size_t);
> ...
> 
> convert_double_to_ulaw8(double *, size_t, byte_t *);

I will consider it if other people think it is a good idea. At the moment
I cannot see why anybody would want to do either endian swapping or ulaw
encoding/decoding in any place other than reading from or writing to a
file. Under what circumstances would you want to perform either of these
two operations resident in memory?

> word_t *resample(word_t *, size_t, double, double);

I am almost certain I will add a buffer to buffer resample function
as it is both difficult and generally useful.

> so that an application needn't to link two libraries for doing the same
> operation in different contexts? Depending on your implementation this
> may require little or no modifications.
> 
> I donwloaded last version of libsndfile.

I hope that was version 0.0.15 or 0.0.16. Version 0.0.15 had a very minor
MacOS bug that was fixed in 0.0.16. On Linux they are identical.

> Is the documentation of your API up to date?

I just checked and it does seem to be.

> If yes I'd like to point some things that, as far as I understand, are
> important:
> 
> 1) There is no format-independent way to know the file length (/duration
> in seconds) other than waiting for EOF.

Opening a file works like this :

    SNDFILE *sndfile ;
    SF_INFO sfinfo ;

    sndfile = sf_open_read ("/path/to/file.wav", &sfinfo) ;

On successful file open the sndfile pointer will be a non-NULL
pointer and the value of sfinfo.samples will tell your how many
samples are in the file. A sample in this case is what I think
you are calling a sample frame (one value per sample for mono,
two values for stereo etc).

> 2) Some applications (see Csound) may need to update the file header
> each time you perform a write operation (so that B can read while A is
> writing).

At the moment libsndfile only works with regular files. That is, it does 
not work with pipes. When a file is opened for write and is closed using
sf_close, the library fseeks() to the start of the file and fills in the
header information correctly.

One of the things I have on my TODO list is to make libsndfile work
so it can read and write pipes. Unfortunately, once one has started
writing a large amount of data to a pipe it is not possible to fseek ()
back to the beginning of the file and correct the header like one can 
with regular files. I see no way around this problem.

> 3) Some functions in audio editors are easy to implement in "direct
> mode" if the file is accessible in read/write mode.
> 3bis) It is possible to append data to a file with your API?

Neither of these two things are currently possible. I have just had a 
look at SGI's libaudiofile documentation and it has similar restrictions.
That does not mean it will never be possible with libsndfile, just that
I did not think it was important yet. Give me a real example where these
operations are really necessary and I'll look into it.

I should mention that I had originally thought that operation on
pipes was not necessary. I then received email from the LAME
(http://www.sulaco.org/mp3/) mpeg 3 encoder project. They were 
using libsndfile when encoding files from disk and different code
when reading a pipe. It turns out LAME can accept data piped out
of a CD ripper. Working with pipes is now high on my list of 
priorities. When I get that working the LAME people will probably
drop their own header parsing code.

> 4) Why don't you make the I/O operations frame-based instead of
> requiring that
> "items" to be an integer times the channels number? (you did it for seek
> but not for read and write)

I did have my reasons for this but maybe you have found something that
needs correcting. The reason I use items for sf_read_XXX and 
sf_write_XXX is so that there is no chance of over-running the end of
array pointer to by the pointer that has been passed into the library. 

At the time of writing the early versions of libsndfile it seemed 
sensible that sf_seek () move by number of multichannel samples
but I can see now that there is an inconsistency. 

> I think you should decide about 4) now that libsndfile is still no so
> popular... :)

What do other people think? Is this inconsistency a problem? The
documentation does spell it out fully and correctly. To a certain
extent I took my lead from the interface of the fread/fwrite/fseek
functions which work in a similar way. 

> This is just one of the two way I'd like to help libsndfile. The other
> will be WRITING THE C++ API. Not now, because I have to finish some
> other stuff but I'll first start discussing details with Erik.

Good, I look forward to it.

> About channel mixing/splitting:

I'm not really sure that something like this belongs in a library
for reading and writing sound files. Being able to split a multichannel 
file and read samples from one channel at a time might be useful, 
but at the moment it is not high on my list of priorities. Being
able to mix a number of channels down to mono or a stereo pair
was not something I even envisioned. I think it would be difficult
to make it general enough for even a large majority of the cases where
mixing is done.

Maybe your C++ wrapper (which may be named something like 
libAbstractAudio) could have a broader interface than the C library 
it wraps. Your library could use libsndfile for for file I/O but
provide many features that libsndfile does not. This would not be 
inconsistent with the differences in the ways that C and C++ coders 
work. Latter, if features which are available in the C++ version of 
the library are attractive to users of the C library, code could 
(with a little work) migrate from the C++ wrapper to the C library, 
lightening the code size of the C++ wrapper.

> I could adapt and send some code from Abstract Audio.
> It works this way: the library stores a mixer pointer, defined as a NxM
> matrix where N is the virtual channel number and M is the real channel
> number.
> 
> mixer[i][j] is the contribute from the source channel j to the virtual
> channel i
> 
> vchannel[i] = mixer[i][j] * rchannel[j]      (using Einstein notation)
> 
> During a read or write operation the library calls the mixing routine if
> the channel numbers don't match. If at open time the application don't
> indicate a mixer (that is, the mixer pointer in the handle structure is
> NULL), the library creates a default mixer that mixes channels in equal
> parts.
> I should have code for mixing and for default mixer generation. The
> mixing routine has code to handle efficiently common cases like 2x1 or
> 1x2 mixers and general code for the remaining cases.
> Of course, I'd add a general mix_buffer() call too.

I'd prefer not to rush into this. I am by nature a rather conservative 
coder and I think there are a number of issues in libsndfile that need 
to be resolved before features like you have proposed. As I have 
suggested, this does not mean that you cannot work your ideas into
a library that wraps libsndfile. Your work can bypass completely the
complexities of file header parsing and other file I/O issues while
providing feedback and ideas for the development of libsndfile.

Cheers,
Erik
-- 
+-------------------------------------------------+
     Erik de Castro Lopo     erikd@zip.com.au
+-------------------------------------------------+
Windows 95/98 - 32 bit extensions and a graphical shell for a 16 bit 
patch to an 8 bit operating system originally coded for a 4 bit
microprocessor, written by a 2 bit company that can't stand 1 bit 
of competition.

From - Wed Aug 18 15:08:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA27129
	for <slinkp@ulster.net>; Wed, 18 Aug 1999 15:01:50 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA17904 for linux-audio-dev-list; Wed, 18 Aug 1999 14:12:17 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA17901 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 18 Aug 1999 14:12:14 -0400
Received: from debian (dialup149-2-14.swipnet.se [130.244.149.78]) 
          by mb06.swip.net (8.8.8/8.8.8) with ESMTP 
          id UAA20693 for <linux-audio-dev@ginette.musique.umontreal.ca>; 
          Wed, 18 Aug 1999 20:09:33 +0200 (MET DST)
Received: from debian.mbox314.swipnet.se (really [127.0.0.1]) by debian
	via in.smtpd with esmtp (ident root using rfc1413)
	id <m11H6uT-0017r0C@debian> (Debian Smail3.2.0.101)
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 18 Aug 1999 16:41:49 +0200 (CEST) 
Message-Id: <m11H6uT-0017r0C@debian>
Date: Wed, 18 Aug 1999 16:41:44 +0200 (CEST)
From: reine@mbox314.swipnet.se
Reply-To: reine@mbox314.swipnet.se
Subject: Re: [linux-audio-dev] Re: Mix
To: linux-audio-dev@ginette.musique.umontreal.ca
In-Reply-To: <14266.35201.333928.252789@gige>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id UAA20693
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id PAA27129
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 57772c94334775eb110043e4bce6c727

On 18 Aug, Guenter Geiger wrote:
> reine@mbox314.swipnet.se writes:
>  > I'm using lesstif-0.88.9, the latest a week or two ago.
>  > Mix starts up with a size of 1169x100.
>  > 
>  > I have a halv slider on the top that I guess was placed between
>  > the rec-button an the magnifying-glass-button.
>  > 
>  > I also have the extra silder by each channel.
>  > The line that follows the sound while playing goes backwards.
>  > 
> 
>  Huh ? Funny 
> 
>  I'm using 0.88.9 too. Have you loaded the resources ?
>  To be sure you have the correct resources do 
> 
>  > xrdb -merge Mix.linux
>  
>  We should hardcode a default resource set to get rid of these oddities. 

I'm sorry. This was to obvious. Now it looks fine.
(dubbla solglasgon, jag gmmer mej)
(embarrassed comment, cant translate)

Reine  


 


From - Wed Aug 18 13:38:59 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA07262
	for <slinkp@ulster.net>; Wed, 18 Aug 1999 12:30:56 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA17684 for linux-audio-dev-list; Wed, 18 Aug 1999 11:36:41 -0400
Received: from fep03-svc.tin.it (mta03-acc.tin.it [212.216.176.34]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA17681 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 18 Aug 1999 11:36:37 -0400
Received: from tin.it ([212.216.171.187]) by fep03-svc.tin.it
          (InterMail v4.01.01.02 201-229-111-106) with ESMTP
          id <19990818153357.CHPT11176.fep03-svc@tin.it>;
          Wed, 18 Aug 1999 17:33:57 +0200
Message-ID: <37BAD0A2.13FA97AB@tin.it>
Date: Wed, 18 Aug 1999 17:26:26 +0200
From: Maurizio Umberto Puxeddu <umbpux@tin.it>
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Erik de Castro Lopo <erikd@zip.com.au>, Nicola Bernardini <nicb@axnet.it>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Nicola Bernardini's sound file library 
 comments
References: <Pine.LNX.4.10.9908172325250.2702-100000@ax-nicb.axnet.it> <37B9E266.1AE1FB18@zip.com.au> <37BA7DE2.10051D75@tin.it>
Content-Type: text/plain; charset=x-user-defined
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: bc03e570244956ec007dc5513b1c1c2f

Maurizio Umberto Puxeddu wrote:
[...snip...]
[In the libsndfile library]
> 1) There is no format-independent way to know the file length (/duration
> in seconds) other than waiting for EOF.

Obviously, this statement is FALSE.

Maurizio Umberto Puxeddu

From - Wed Aug 18 13:39:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA07305
	for <slinkp@ulster.net>; Wed, 18 Aug 1999 12:31:19 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA17695 for linux-audio-dev-list; Wed, 18 Aug 1999 11:40:05 -0400
Received: from kaybee.org (kaybee.resnet.gatech.edu [128.61.15.250]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA17692 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 18 Aug 1999 11:40:03 -0400
Received: from localhost (rob@localhost)
	by kaybee.org (8.8.7/8.8.7) with ESMTP id LAA21956;
	Wed, 18 Aug 1999 11:37:08 -0400
Date: Wed, 18 Aug 1999 11:37:08 -0400 (EDT)
From: rob <rob@kaybee.org>
To: Erik de Castro Lopo <erikd@zip.com.au>
cc: Maurizio Umberto Puxeddu <umbpux@tin.it>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Nicola Bernardini's sound file library
 comments
In-Reply-To: <37BAACA8.6FCC6ED9@zip.com.au>
Message-ID: <Pine.LNX.4.10.9908181129150.17730-100000@kaybee.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 4063bb85c97ab0ca9205e7971005fe95

On Wed, 18 Aug 1999, Erik de Castro Lopo wrote:

> One of the things I have on my TODO list is to make libsndfile work
> so it can read and write pipes. Unfortunately, once one has started
> writing a large amount of data to a pipe it is not possible to fseek ()
> back to the beginning of the file and correct the header like one can 
> with regular files. I see no way around this problem.

	use a temp file ? <eww, but hey> 


> > 3) Some functions in audio editors are easy to implement in "direct
> > mode" if the file is accessible in read/write mode.
> > 3bis) It is possible to append data to a file with your API?
> 
	what about letting it play virtual files so to speak.  create
arbitrary regions in multiple (or the same) files and a play list
assembled from the region id's. you can simulate direct access, huge-file
handling, speedy deletes (delete first 2megs of a 100 meg file, etc), and
large undo buffers with this.  all operations would be done upon a flush
or close.
				rob
				
-----
Rob Melby
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
Internet: rob@kaybee.org, gt4255a@prism.gatech.edu

From - Wed Aug 18 14:48:52 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA25783
	for <slinkp@ulster.net>; Wed, 18 Aug 1999 14:51:29 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA17862 for linux-audio-dev-list; Wed, 18 Aug 1999 13:57:57 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA17859 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 18 Aug 1999 13:57:54 -0400
Received: from ulster.net (port132.king.ulster.net [208.242.160.133])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id OAA20148;
	Wed, 18 Aug 1999 14:08:51 -0400
Message-ID: <37BAF513.D11210FB@ulster.net>
Date: Wed, 18 Aug 1999 14:01:55 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
CC: rob <rob@kaybee.org>, Erik de Castro Lopo <erikd@zip.com.au>
Subject: Re: [linux-audio-dev] Re: Nicola Bernardini's sound file librarycomments
References: <Pine.LNX.4.10.9908181129150.17730-100000@kaybee.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: fdcc718d2bd174286c0b9cac88a1b987

rob wrote:
>         what about letting it play virtual files so to speak.  create
> arbitrary regions in multiple (or the same) files and a play list
> assembled from the region id's. you can simulate direct access, huge-file
> handling, speedy deletes (delete first 2megs of a 100 meg file, etc), and
> large undo buffers with this.  all operations would be done upon a flush
> or close.

Yes, please!!! I don't know enough to know if this approach will work
technically, but anything that lets me delete or modify just a bit of a
huge file without waiting for ages and ages... that would be a godsend.

- 

----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Wed Aug 18 15:08:41 1999
Received: from fep02-svc.tin.it (mta02-acc.tin.it [212.216.176.33])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id PAA27352
	for <slinkp@ulster.net>; Wed, 18 Aug 1999 15:03:20 -0400
Received: from tin.it ([212.216.180.186]) by fep02-svc.tin.it
          (InterMail v4.01.01.02 201-229-111-106) with ESMTP
          id <19990818184931.SOWV16170.fep02-svc@tin.it>;
          Wed, 18 Aug 1999 20:49:31 +0200
Sender: umberto
Message-ID: <37BAFE78.5BDCA407@tin.it>
Date: Wed, 18 Aug 1999 20:42:00 +0200
From: Maurizio Umberto Puxeddu <umbpux@tin.it>
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Winkler <slinkp@ulster.net>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Nicola Bernardini's sound file librarycomments
References: <Pine.LNX.4.10.9908181129150.17730-100000@kaybee.org> <37BAF513.D11210FB@ulster.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d9a035eb31047c218bd8d1b87c54f7aa

Paul Winkler wrote:
> 
> rob wrote:
> >         what about letting it play virtual files so to speak.  create
> > arbitrary regions in multiple (or the same) files and a play list
> > assembled from the region id's. you can simulate direct access, huge-file
> > handling, speedy deletes (delete first 2megs of a 100 meg file, etc), and
> > large undo buffers with this.  all operations would be done upon a flush
> > or close.
> 
> Yes, please!!! I don't know enough to know if this approach will work
> technically, but anything that lets me delete or modify just a bit of a
> huge file without waiting for ages and ages... that would be a godsend.

I don't know if there are linux sound editors that work this way but
it's a "standard"
technique called "non-destructive editing".

You open the rob's 100 Mbyte audio file but when you, say, delete a
fragment it is not physically deleted. The editor just remember to skip
that block when playing the file. Same thing for adding a block: the
editor plays up to the block start then opens another file, plays a
block from that, then continue with the first. Mixing is done on the fly
and so on. From time to time you have to freeze changes and make them
physically but in the meantime you can try deleting 1.2 seconds,
playing, undoing, deleting 1.15, playing seconds...
I wrote an audio file player with region handling based on
AbstractAudio.

Umberto

From - Wed Aug 18 15:38:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA32003
	for <slinkp@ulster.net>; Wed, 18 Aug 1999 15:41:02 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA17951 for linux-audio-dev-list; Wed, 18 Aug 1999 14:52:18 -0400
Received: from fep02-svc.tin.it (mta02-acc.tin.it [212.216.176.33]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA17948 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 18 Aug 1999 14:52:15 -0400
Received: from tin.it ([212.216.180.186]) by fep02-svc.tin.it
          (InterMail v4.01.01.02 201-229-111-106) with ESMTP
          id <19990818184931.SOWV16170.fep02-svc@tin.it>;
          Wed, 18 Aug 1999 20:49:31 +0200
Message-ID: <37BAFE78.5BDCA407@tin.it>
Date: Wed, 18 Aug 1999 20:42:00 +0200
From: Maurizio Umberto Puxeddu <umbpux@tin.it>
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Winkler <slinkp@ulster.net>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Nicola Bernardini's sound file librarycomments
References: <Pine.LNX.4.10.9908181129150.17730-100000@kaybee.org> <37BAF513.D11210FB@ulster.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 220f481c326025d8169237839a0ac820

Paul Winkler wrote:
> 
> rob wrote:
> >         what about letting it play virtual files so to speak.  create
> > arbitrary regions in multiple (or the same) files and a play list
> > assembled from the region id's. you can simulate direct access, huge-file
> > handling, speedy deletes (delete first 2megs of a 100 meg file, etc), and
> > large undo buffers with this.  all operations would be done upon a flush
> > or close.
> 
> Yes, please!!! I don't know enough to know if this approach will work
> technically, but anything that lets me delete or modify just a bit of a
> huge file without waiting for ages and ages... that would be a godsend.

I don't know if there are linux sound editors that work this way but
it's a "standard"
technique called "non-destructive editing".

You open the rob's 100 Mbyte audio file but when you, say, delete a
fragment it is not physically deleted. The editor just remember to skip
that block when playing the file. Same thing for adding a block: the
editor plays up to the block start then opens another file, plays a
block from that, then continue with the first. Mixing is done on the fly
and so on. From time to time you have to freeze changes and make them
physically but in the meantime you can try deleting 1.2 seconds,
playing, undoing, deleting 1.15, playing seconds...
I wrote an audio file player with region handling based on
AbstractAudio.

Umberto

From - Thu Aug 19 00:33:37 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA04387
	for <slinkp@ulster.net>; Wed, 18 Aug 1999 16:16:49 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA18013 for linux-audio-dev-list; Wed, 18 Aug 1999 15:27:20 -0400
Received: from fep02-svc.tin.it (mta02-acc.tin.it [212.216.176.33]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA18009 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 18 Aug 1999 15:27:17 -0400
Received: from tin.it ([212.216.180.186]) by fep02-svc.tin.it
          (InterMail v4.01.01.02 201-229-111-106) with ESMTP
          id <19990818192428.STPC16170.fep02-svc@tin.it>
          for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Wed, 18 Aug 1999 21:24:28 +0200
Message-ID: <37BB06AB.62DB973B@tin.it>
Date: Wed, 18 Aug 1999 21:16:59 +0200
From: Maurizio Umberto Puxeddu <umbpux@tin.it>
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: "linux-audio-dev@ginette.musique.umontreal.ca" 
 <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Nicola Bernardini's sound file library 
 comments
Content-Type: text/plain; charset=x-user-defined
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 8cc993a83d4de20bed287a01fd4a86ee

Erik de Castro Lopo wrote:
> 
> Maurizio Umberto Puxeddu wrote:
>  [...snip...]
> > I was not (not only) asking Erik to insert one or two features. I meant:
> > you have the code for doing this operation while reading/writing a file
> > but an application may have to do the same with audio data resident in
> > memory. Why
> > don't include in your API functions like
> >
> > swap_word_endianess(word_t *, size_t);
> > ...
> >
> > convert_double_to_ulaw8(double *, size_t, byte_t *);
> 
> I will consider it if other people think it is a good idea. At the moment
> I cannot see why anybody would want to do either endian swapping or ulaw
> encoding/decoding in any place other than reading from or writing to a
> file. Under what circumstances would you want to perform either of these
> two operations resident in memory?
endianess:  in a networking audio application
sample format:   connecting code that uses different sample format, such
as in a cut and past between different applications in a Windows-like
fashion. (ulaw encoding is probably a bad example, because it's the less
common sample format conversion, but please take the idea and throw away
me!)
 
> > 2) Some applications (see Csound) may need to update the file header
> > each time you perform a write operation (so that B can read while A is
> > writing).
> 
> At the moment libsndfile only works with regular files. That is, it does
> not work with pipes. When a file is opened for write and is closed using
> sf_close, the library fseeks() to the start of the file and fills in the
> header information correctly.
> 
> One of the things I have on my TODO list is to make libsndfile work
> so it can read and write pipes. Unfortunately, once one has started
> writing a large amount of data to a pipe it is not possible to fseek ()
> back to the beginning of the file and correct the header like one can
> with regular files. I see no way around this problem.
But I *was* speaking of regular files. Csound can rewrite continuously
the header while writing a sound file (-R switch), so that you can use
an audioplayer to move through the file while during the synthesis. (You
probably sets the file length to the maximum value before the close
operation, but this is a bit dangerous.)

> > 3) Some functions in audio editors are easy to implement in "direct
> > mode" if the file is accessible in read/write mode.
> > 3bis) It is possible to append data to a file with your API?
> Neither of these two things are currently possible. I have just had a
> look at SGI's libaudiofile documentation and it has similar restrictions.
> That does not mean it will never be possible with libsndfile, just that
> I did not think it was important yet. Give me a real example where these
> operations are really necessary and I'll look into it.
Say, I want to apply a filter to a segment of audio file without
creating a new copy of it ("direct mode"). With your API I

1) create a buffer 
2) open the file in read mode
3) fill the buffer
4) close the file
5) filter the buffer
6) open the file in write mode
7) write the buffer to file
8) close the file 
9) reopen the file
10) seek and again from 3)

With read/write access and separate file locators I

1)create the buffer
2)open the file
3)seek write locator and read locator
4)fill buffer
5)filter buffer
6)write buffer and again from 4)

 
> > 4) Why don't you make the I/O operations frame-based instead of
> > requiring that
> > "items" to be an integer times the channels number? (you did it for seek
> > but not for read and write)
> 
> I did have my reasons for this but maybe you have found something that
> needs correcting. The reason I use items for sf_read_XXX and
> sf_write_XXX is so that there is no chance of over-running the end of
> array pointer to by the pointer that has been passed into the library.
Excuse me but I don't understand!

> > About channel mixing/splitting:
> [...snip...]
> I'd prefer not to rush into this. I am by nature a rather conservative
> coder and I think there are a number of issues in libsndfile that need
> to be resolved before features like you have proposed. As I have
> suggested, this does not mean that you cannot work your ideas into
> a library that wraps libsndfile. Your work can bypass completely the
> complexities of file header parsing and other file I/O issues while
> providing feedback and ideas for the development of libsndfile.

Ok, this seems to be the better way to work. I agree.
And I agree with you also when you say that you would like to hear
opinions from audio application developers.

Maurizio Umberto Puxeddu

From - Thu Aug 19 00:33:40 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA05298
	for <slinkp@ulster.net>; Wed, 18 Aug 1999 16:23:24 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA18041 for linux-audio-dev-list; Wed, 18 Aug 1999 15:37:56 -0400
Received: from fep02-svc.tin.it (mta02-acc.tin.it [212.216.176.33]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA18038 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 18 Aug 1999 15:37:53 -0400
Received: from tin.it ([212.216.180.186]) by fep02-svc.tin.it
          (InterMail v4.01.01.02 201-229-111-106) with ESMTP
          id <19990818193509.SUWM16170.fep02-svc@tin.it>
          for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Wed, 18 Aug 1999 21:35:09 +0200
Message-ID: <37BB092C.D2825207@tin.it>
Date: Wed, 18 Aug 1999 21:27:40 +0200
From: Maurizio Umberto Puxeddu <umbpux@tin.it>
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Nicola Bernardini's sound file librarycomments
References: <Pine.LNX.4.10.9908181129150.17730-100000@kaybee.org>
Content-Type: text/plain; charset=x-user-defined
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e1848c5444328cf53b6c6364c127cd01

rob wrote:
> 
> On Wed, 18 Aug 1999, Erik de Castro Lopo wrote:
> 
> > One of the things I have on my TODO list is to make libsndfile work
> > so it can read and write pipes. Unfortunately, once one has started
> > writing a large amount of data to a pipe it is not possible to fseek ()
> > back to the beginning of the file and correct the header like one can
> > with regular files. I see no way around this problem.
> 
>         use a temp file ? <eww, but hey>
> 
> > > 3) Some functions in audio editors are easy to implement in "direct
> > > mode" if the file is accessible in read/write mode.
> > > 3bis) It is possible to append data to a file with your API?
> >
>         what about letting it play virtual files so to speak.  create
> arbitrary regions in multiple (or the same) files and a play list
> assembled from the region id's. you can simulate direct access, huge-file
> handling, speedy deletes (delete first 2megs of a 100 meg file, etc), and
> large undo buffers with this.  all operations would be done upon a flush
> or close.

Yes, an application can do non-destructive editing but it should be a
free choice of the application programmer. "Non-destructive editing" and
"direct editing" have each they pros and cons and good editors may work
in both ways (see Sonic Foundry's Sound Forge for Windows).

Umberto

From - Thu Aug 19 00:33:36 1999
Received: from wpdnt.webpage.com.au (wpdnt.webpage.com.au [203.36.219.100])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id PAA02064
	for <slinkp@ulster.net>; Wed, 18 Aug 1999 15:59:24 -0400
Received: from rossbenc (unverified [203.152.254.154]) by wpdnt.webpage.com.au
 (Rockliffe SMTPRA 3.3.1) with SMTP id <B0000023237@wpdnt.webpage.com.au> for <slinkp@ulster.net>;
 Thu, 19 Aug 1999 05:44:15 +1000
Message-ID: <007001bee9b2$132cb4a0$9afe98cb@rossbenc>
From: "Ross Bencina" <rossb@audiomulch.com>
To: "Paul Winkler" <slinkp@ulster.net>
Subject: Pscore / Python
Date: Thu, 19 Aug 1999 05:14:23 +0930
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Status: U
X-Mozilla-Status: 8003
X-Mozilla-Status2: 00000000
X-UIDL: 6d3b2da58804589671f42319bd75f828

Hi Paul,

Just saw your post to the csound list, and I have my Python radar out....

>Personally, anything I do in this direction in the future
>is more likely to by in Python.


I'm working on a Python based sound processing environment loosely based on
my MacCmix port. It's primarily directed at off line processing (phase
vocoder, convolution, etc.) but should be quite flexible.

I was just wondering what music related stuff you are [intending] to do with
Python, as it's a really interesting language and I havn't seen much serious
computer music use of it.

Best Regards,

Ross
http://www.audiomulch.com/~rossb/


From - Thu Aug 19 00:33:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA09938
	for <slinkp@ulster.net>; Wed, 18 Aug 1999 16:54:58 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA18102 for linux-audio-dev-list; Wed, 18 Aug 1999 16:10:32 -0400
Received: from kaybee.org (kaybee.resnet.gatech.edu [128.61.15.250]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA18099 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 18 Aug 1999 16:10:29 -0400
Received: from localhost (rob@localhost)
	by kaybee.org (8.8.7/8.8.7) with ESMTP id QAA24163;
	Wed, 18 Aug 1999 16:07:47 -0400
Date: Wed, 18 Aug 1999 16:07:47 -0400 (EDT)
From: rob <rob@kaybee.org>
To: Maurizio Umberto Puxeddu <umbpux@tin.it>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Nicola Bernardini's sound file librarycomments
In-Reply-To: <37BB092C.D2825207@tin.it>
Message-ID: <Pine.LNX.4.10.9908181558580.24076-100000@kaybee.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 775b7d8c4a20acceb17188e30df36bab

On Wed, 18 Aug 1999, Maurizio Umberto Puxeddu wrote:

> Yes, an application can do non-destructive editing but it should be a
> free choice of the application programmer. "Non-destructive editing" and
> "direct editing" have each they pros and cons and good editors may work
> in both ways (see Sonic Foundry's Sound Forge for Windows).

	well my suggestion isn't meant to exclude one way or another.  i
think it is a good candidate for a sound library because it can be done in
a general way, is non trivial (if done right), and lots of differnt audio
editing apps could take advantage of this easily to make every users life
easier.  it would be a completely seperate mechanism which would allow the
use of a single read/write method simplifying app design for a powerful
feature.
	i think it might end up being important to make as many of the
basic, useful services exist in common, so that one needn't be tied to,
for example, the authors choice of gui toolkit, platform.  this way the
concentration can be towards providing a coherent, easy, and pretty
interface to the user, instead of reproducing basic features. 
				rob

---
Rob Melby
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
Internet: rob@kaybee.org, gt4255a@prism.gatech.edu

From - Thu Aug 19 04:03:43 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id EAA17910
	for <slinkp@ulster.net>; Thu, 19 Aug 1999 04:02:33 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id DAA18984 for linux-audio-dev-list; Thu, 19 Aug 1999 03:13:46 -0400
Received: from fep03-svc.tin.it (mta03-acc.tin.it [212.216.176.34]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA18981 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 19 Aug 1999 03:13:42 -0400
Received: from tin.it ([212.216.160.56]) by fep03-svc.tin.it
          (InterMail v4.01.01.02 201-229-111-106) with ESMTP
          id <19990819071101.FNWX11176.fep03-svc@tin.it>
          for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Thu, 19 Aug 1999 09:11:01 +0200
Message-ID: <37BBAC42.94EB56BA@tin.it>
Date: Thu, 19 Aug 1999 09:03:30 +0200
From: Maurizio Umberto Puxeddu <umbpux@tin.it>
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Nicola Bernardini's sound file librarycomments
References: <Pine.LNX.4.10.9908181558580.24076-100000@kaybee.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0d5c99fc3429f7d9dbe8c3bf95ce6490

rob wrote:
> 
> On Wed, 18 Aug 1999, Maurizio Umberto Puxeddu wrote:
> 
> > Yes, an application can do non-destructive editing but it should be a
> > free choice of the application programmer. "Non-destructive editing" and
> > "direct editing" have each they pros and cons and good editors may work
> > in both ways (see Sonic Foundry's Sound Forge for Windows).
> 
>         well my suggestion isn't meant to exclude one way or another.  i
> think it is a good candidate for a sound library because it can be done in
> a general way, is non trivial (if done right), and lots of differnt audio
> editing apps could take advantage of this easily to make every users life
> easier.  it would be a completely seperate mechanism which would allow the
> use of a single read/write method simplifying app design for a powerful
> feature.
I took your words has as suggestion for a workaround. 
Including this mechanism in an audio library is very interesting and
I'll think of it seriously. If you or anybody has more precise ideas for
the API, I'd like to read them.

>         i think it might end up being important to make as many of the
> basic, useful services exist in common, so that one needn't be tied to,
> for example, the authors choice of gui toolkit, platform.  this way the
> concentration can be towards providing a coherent, easy, and pretty
> interface to the user, instead of reproducing basic features.
This is the AbstractAudio spirit!

Thanks,
Maurizio Umberto Puxeddu

From - Thu Aug 19 13:55:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id EAA20253
	for <slinkp@ulster.net>; Thu, 19 Aug 1999 04:54:55 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id EAA19240 for linux-audio-dev-list; Thu, 19 Aug 1999 04:06:47 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA19237 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 19 Aug 1999 04:06:44 -0400
Received: from ulster.net (port86.king.ulster.net [208.242.160.87])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id EAA18457;
	Thu, 19 Aug 1999 04:17:44 -0400
Message-ID: <37BBBC06.ADC57096@ulster.net>
Date: Thu, 19 Aug 1999 04:10:46 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Nicola Bernardini <nicb@axnet.it>
CC: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Mix
References: <Pine.LNX.4.10.9908180703420.2702-100000@ax-nicb.axnet.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7f5eeceb6509925d1c3d7f3fdc3ac78d

Nicola Bernardini wrote:

> Now, regions are another story. I'd really like to see some serious
> region editing a` la ProTools in Mix. I've worked with ProTools quite
> a lot and if nobody has done anything about it by the end of september
> I might give it a try (god knows I should not promise anything...).

Oh, Nicola, why do you tease me so? It's sheer torture!

-- 

----------------    paul winkler    ------------------

From - Thu Aug 19 13:55:48 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA07104
	for <slinkp@ulster.net>; Thu, 19 Aug 1999 09:25:41 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA19505 for linux-audio-dev-list; Thu, 19 Aug 1999 08:22:30 -0400
Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA19502 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 19 Aug 1999 08:22:25 -0400
Received: from hendrix (stan73.zip.com.au [61.8.17.73])
	by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id WAA24936
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 19 Aug 1999 22:09:14 +1000 (EST)
Message-ID: <37BBF65B.7B1C8959@zip.com.au>
Date: Thu, 19 Aug 1999 22:19:39 +1000
From: Erik de Castro Lopo <erikd@zip.com.au>
Organization: Eric Conspiracy Secret Labs
X-Mailer: Mozilla 3.04Gold (X11; I; Linux 2.2.11 i586)
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] The future of libsndfile
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: b631c783516f605ad6243e972c48a9f9

Hi all,

I've been a little overwhelmed with the recent discussion about what 
features people would like. Rather than trying to answer each email
separately I will try to respond to all the issues in one go. If
I have missed anything please point it out.

Maurizio Umberto Puxeddu had the following suggestion:
> > > 2) Some applications (see Csound) may need to update the file header
> > > each time you perform a write operation (so that B can read while A is
> > > writing).
<snip>
> Csound can rewrite continuously
> the header while writing a sound file (-R switch), so that you can use
> an audioplayer to move through the file while during the synthesis. (You
> probably sets the file length to the maximum value before the close
> operation, but this is a bit dangerous.)

Yes I think this is a good idea. I have been thinking about cleaning up
the 
header writing code and when I do this I will add an interface something 
like sf_update_header () which will rewrite the header with the number
of
samples written at the time it is called.

Another of Maurizio's suggestions was:
> I was not (not only) asking Erik to insert one or two features. I meant:
> you have the code for doing this operation while reading/writing a file
> but an application may have to do the same with audio data resident in
> memory. Why
> don't include in your API functions like
> 
> swap_word_endianess(word_t *, size_t);
> 
> convert_double_to_ulaw8(double *, size_t, byte_t *);

These functions in libsndfile are slightly different but I will expose
whatever may be useful. The exposed functions will all be named sf_* (). 
In order to minimise the size of the libsndfile headers, I will use two 
header files sndfile.h which will be similar to the current one and 
sndfileex.h which contains the extra utility functions and includes
the first header.

Maurizio was rather busy and also brought up the issue of a possible 
inconsistency between the behaviour of sf_read_XXX / sf_write_XXXX
and the behaviour of sf_seek.

I (Erik de Castro Lopo) wrote :
> > I did have my reasons for this but maybe you have found something that
> > needs correcting. The reason I use items for sf_read_XXX and 
> > sf_write_XXX is so that there is no chance of over-running the end of
> > array pointer to by the pointer that has been passed into the library. 

to which Bruce (est@hyperreal.org) replied :
> Hmm..you still have that risk if the user is confused about the sample
> format.  I'll throw in a strong vote for frame counts in read and
> write.

Maurizio asked for an explanation of my comment. Here it is :

Typically, someone using my library would have allocated a buffer to 
read the samples into after opening the file ie:

    int items, readcount ;
    double array [BUFFER_LEN] ;

    sndfile = sf_open_read ("/path/to/file.wav", &sfinfo) ;

    items = BUFFER_LEN - (BUFFER_LEN % sfinfo.channels) ;

    while (readcount = sf_read_double (sndfile, array, items, 0))
    {
        /* Process the samples */
    }

With the read function operating in items, the worst that can happen
is that items will not be an integer multiple of channels and an
error condition will be gernerated. 

If on the other hand the sf_read_XXXX functions worked on sample
frames the naive user may have done this :

    int samples, readcount ;
    double array [BUFFER_LEN] ;

    sndfile = sf_open_read ("/path/to/file.wav", &sfinfo) ;

    while (readcount = sf_read_double (sndfile, array, samples, 0))
    {
        /* Process the samples */
    }

which would be fine for mono, would have over-run the end of the buffer
with a multichannel file. Having done silly things like myself, I
know that these kinds of errors can be particularly hard to find in some
instances.

Anyway, now I have explained it I am less convinced than I was. With a 
little encouragement I'll probably make a decision to change the read
and write operations from items to frames. From a coding point of
view its a trivial change but I'm going to try and come up with a 
way of making the change without breaking any existing apps.

Finally, there was much discussion about more dynamic operations on
files
than simple reads or writes. One of the first things I'll be
implementing
in this area is the ability to open a file in read/write mode. This is 
not too difficult and was mainly left out originally to simplify the
implementation when I was still working out a spec for the library. As
Maurizio pointed out, there is an advantage to having separate read
and write file pointers.

I have also been having some thoughts along the lines of non-destructive
editing with edit lists etc. My conclucion was that none of the formats
libsndfile currently supports is all that well suited to this problem.
My idea was to make a new (or yet another) file format which would 
specifically be designed to be cross platform and allow non-destructive
editing. It would also be possible to write a rendering routine which
takes a file in this new format as input and mixes/renders it into one 
of the standard playback formats like WAV or AIFF. The only questions is
whether this should be part of the library or a separte application.

So, it looks like I've got lots of things to do. I had planned to get a 
new version out in the next couple of weeks contained PAF and SVX/IFF
file support and reading/writing pipes. Once that is out I'll start
picking of these suggestions one by one. 

Cheers and thanks,
Erik
-- 
+-------------------------------------------------+
     Erik de Castro Lopo     erikd@zip.com.au
+-------------------------------------------------+
The National Multiple Sclerosis Society of America recently started an
advertising campaign with the slogan "MS: It's not a software company".

Seasoned IT professionals will have no trouble telling the two MS's
apart.  
One is a debilitating and surprisingly widespread affliction that
renders
the sufferer barely able to perform the simplest task. The other is a
disease.

From - Thu Aug 19 13:55:47 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA06551
	for <slinkp@ulster.net>; Thu, 19 Aug 1999 09:21:29 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA19522 for linux-audio-dev-list; Thu, 19 Aug 1999 08:32:50 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA19519 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 19 Aug 1999 08:32:48 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S42808AbPHSM3y>; Thu, 19 Aug 1999 15:29:54 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <37B48520.F585FCE3@bright.net> (message from Dave Phillips on
	Fri, 13 Aug 1999 16:50:40 -0400)
Subject: Re: [linux-audio-dev] Snd and file sizes
Message-Id: <19990819123004Z42808-549+1142@nic.funet.fi>
Date:   Thu, 19 Aug 1999 15:29:54 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 24f2756b94dbeaddf6e3e6cc930a3b05

>From:   Dave Phillips <dlphilp@bright.net>
>  "Snd can handle any size file already, and has from the beginning. It
>also has elaborate support for edit lists."

Just wanted to say that KWave and XWave can handle large files but
those programs might be otherwise limited. At least XWave cannot do
effects on very large files -- it applies effects only in memory.

KWave uses my mmapalloc()/mmapfree() routines the same way as malloc()
and free(). This means that audiofiles are copied to new files during
audiofile loading. All audio memory segments are kept in temporary files
by mmapalloc() routine. That was only a quick solution to the problem.

Yours,

Juhana

From - Thu Aug 19 13:55:51 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA09151
	for <slinkp@ulster.net>; Thu, 19 Aug 1999 09:38:49 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA19545 for linux-audio-dev-list; Thu, 19 Aug 1999 08:50:26 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA19542 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 19 Aug 1999 08:50:22 -0400
Received: from bright.net (find-cas1-cs-22.dial.bright.net [209.143.26.125])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id IAA10437;
	Thu, 19 Aug 1999 08:47:39 -0400 (EDT)
Message-ID: <37BC0332.4E1C68E4@bright.net>
Date: Thu, 19 Aug 1999 09:14:26 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Juhana Sadeharju <kouhia@nic.funet.fi>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Snd and file sizes
References: <19990819123004Z42808-549+1142@nic.funet.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: a65ffbdf0336139986725c20f86475a9

Juhana Sadeharju wrote:

> Just wanted to say that KWave and XWave can handle large files but
> those programs might be otherwise limited. At least XWave cannot do
> effects on very large files -- it applies effects only in memory.

I've just finished profiling KWave for my book. I've used it before, but
looking at again (and learning that it will handle large files) I must
say it's a nicely impressive work. The use of Qt graphics is excellent.
Filter design and synthesis generation both include displays which are
updated as the parameter controls are manipulated. Although only at
version 0.29.7 it has a decent complement of effects processors and some
other rather interesting features.

Unfortunately it's been a while since the author (Martin Wilz) has taken
KWave any further. I intend to contact him and find whether he plans to
continue development.

But of course what I'm *really* waiting for is Juhana's editor... ;)

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Thu Aug 19 13:55:52 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA12290
	for <slinkp@ulster.net>; Thu, 19 Aug 1999 09:58:40 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA19602 for linux-audio-dev-list; Thu, 19 Aug 1999 09:10:16 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA19599 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 19 Aug 1999 09:10:13 -0400
Received: from bright.net (find-cas1-cs-22.dial.bright.net [209.143.26.125])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id JAA06575;
	Thu, 19 Aug 1999 09:07:28 -0400 (EDT)
Message-ID: <37BC07D8.D1D5FA83@bright.net>
Date: Thu, 19 Aug 1999 09:34:16 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Nicola Bernardini <nicb@axnet.it>
CC: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Mix
References: <Pine.LNX.4.10.9908180703420.2702-100000@ax-nicb.axnet.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3caadf13a47aaf7700615d866defe209

Nicola Bernardini wrote:

> ...I think we should not fall into the 'integrated solution'
> trap. If we decide that Mix is a multi-track editor that basically
> handles files, I'd leave the recording/playback functions to some
> other processes, possibly callable from Mix and running in background
> while you do other things.

Hmm...Well, Mix is already designed to record/playback, and I certainly
enjoy being able to pinpoint problems visually during playback. However,
it is true that the record function is unstable. Guenter may be working
on that.

I understand your concern though, and your thoughts have got me
re-thinking plans for revising and updating Mix. Guenter stated that
he'd like to jettison the fx stuff in favor of a plug-in mode: if it can
be done and done well, I'm all for it. Actually, I'm in favor of about
anything that will lighten up mix.c !

> I can see a *fairly* easy task: build a separate previewer which accepts
> a text file prepared by Mix, reads it and runs all operations requested
> while playing (again - no guarantees on no glitches). It is easy to
> do all the volume and panning job, a little more difficult to run
> the effects - but if Mix is modularized and a library is built out
> of it, here comes the previewer with effects et al.

That part about "fairly easy"...wasn't it Wanda Landowska who observed
that there's no such thing as an easy piece of music ? (Just poking,
Nicola, don't take me seriously. You know far more about this stuff than
I do, so if you say it's fairly easy then I'll take your word for it.
But mix.c is scary stuff...)

> There are some
> good reasons, I think, to keep Mix out of real time - the first one
> I could really use is to have infinite tracks, or infinite stack
> of effects, etc. (up to memory limits of course). These are things
> no CoolEdit nor ProTools nor whatever
> can do because they always think in terms of real-time (while most
> of the time work is done offline - just previewing is done in real-time).

I guess I'm still legacy-locked by my experience with Windoze-based
editors and mixers. Nevertheless, I'm trying to find how the approach
you espouse (or the approach taken by ecasound) would work with my own
style. And I'm always willing to learn a better way...

> Now, regions are another story. I'd really like to see some serious
> region editing a` la ProTools in Mix. I've worked with ProTools quite
> a lot and if nobody has done anything about it by the end of september
> I might give it a try (god knows I should not promise anything...).

When Richard Kent and I first prepared a Linux version of Mix the most
persistent criticism I received was about its lack of support for
regions. Unfortunately the current code is not workable (so sayeth Dr.
Hammer) and should be dumped in favor of something that is. Well, the
end of September draws nearer everyday... ;)
 
> There's a number of things we should ask Dr.Hammer... The csound variable,
> the networking stuff: what were they meant to do? (hoping that he
> remembers - if it was me, after two months I'd already forgotten...)

I'm on it. I recently received some clarification from him regarding the
Csound variable and a few other items (the Time Machine in particular).
I've just started to looking at the networking code: there's nothing
about it in the original documentation, I'll just have to experiment.
Ditto for the MIDI stuff, unless Guenter has already figured it.

I will add the stuff re: the Time Machine and then make the updated docs
available to whoever wants them. There aren't any great surprises, I
just cleaned up some of the page's appearance and lightly edited some of
the text. As I said, there's still no documentation of the MIDI and
network functions.

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Thu Aug 19 13:55:58 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA23802
	for <slinkp@ulster.net>; Thu, 19 Aug 1999 11:17:53 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA19704 for linux-audio-dev-list; Thu, 19 Aug 1999 10:28:55 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id KAA19701 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 19 Aug 1999 10:28:49 -0400
From: est@hyperreal.org
Received: (qmail 12741 invoked by uid 162); 19 Aug 1999 14:26:08 -0000
Message-ID: <19990819142608.12740.qmail@hyperreal.org>
Subject: [linux-audio-dev] hardware vs. OS limits
In-Reply-To: <Pine.LNX.4.10.9908180703420.2702-100000@ax-nicb.axnet.it> from
 Nicola Bernardini at "Aug 18, 1999 07:29:04 am"
To: Nicola Bernardini <nicb@axnet.it>
Date: Thu, 19 Aug 1999 07:26:08 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: f9ad4d1a3a5d2d21e0e6d269a2673341

Nicola Bernardini discourseth:
> Speaking of which, and on the other thread of IDE drives, linux drivers
> etc. (sorry for mixing threads), while we should of course push the
> issue on kernel developers (especially considering the UDMA/66
> interface etc.), we should not ignore the fact that software like
> ProTools is extremely bitchy about what kind of disk drive you have
> (generally they want UW SCSI 10000 RPMs: fairly expensive stuff,
> and certainly nothing less than UW 7200 RPMs). The moral of the story
> is: if you want real-time, your hardware (not the software) is going
> to be the limit.

I've got IDE and UW SCSI here, and they give me equal performance
(even with my non-Intel chipset).  If I want real-time, I find I need
to patch linux. :)

Eric

From - Thu Aug 19 18:34:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA05714
	for <slinkp@ulster.net>; Thu, 19 Aug 1999 16:36:03 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA20136 for linux-audio-dev-list; Thu, 19 Aug 1999 15:48:09 -0400
Received: from ax-nicb.axnet.it (ax-nicb.axnet.it [194.184.60.149]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA20133 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 19 Aug 1999 15:46:41 -0400
Received: (from nicb@localhost)
	by ax-nicb.axnet.it (8.8.7/8.8.7) id SAA13931;
	Thu, 19 Aug 1999 18:09:35 +0200
Date: Thu, 19 Aug 1999 18:09:35 +0200 (CEST)
From: Nicola Bernardini <nicb@axnet.it>
To: Erik de Castro Lopo <erikd@zip.com.au>
cc: Linux Audio Development Mailing list <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Nicola Bernardini's sound file library
 comments
In-Reply-To: <37BAACA8.6FCC6ED9@zip.com.au>
Message-ID: <Pine.LNX.4.10.9908191757400.2702-100000@ax-nicb.axnet.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ea18bae95fd3c7541f486bfcbd94703e

Yesterday, Erik de Castro Lopo mi scrisse cio` che segue:

[snip]
> One of the things I have on my TODO list is to make libsndfile work
> so it can read and write pipes. Unfortunately, once one has started
> writing a large amount of data to a pipe it is not possible to fseek ()
> back to the beginning of the file and correct the header like one can 
> with regular files. I see no way around this problem.

how does a pager like 'less' do? less can read infinitely large
files from a pipe and go back and forth. Or am I wrong?

[snip]
> I should mention that I had originally thought that operation on
> pipes was not necessary. I then received email from the LAME
> (http://www.sulaco.org/mp3/) mpeg 3 encoder project. They were 
> using libsndfile when encoding files from disk and different code
> when reading a pipe. It turns out LAME can accept data piped out
> of a CD ripper. Working with pipes is now high on my list of 
> priorities. When I get that working the LAME people will probably
> drop their own header parsing code.

any streaming operation will probably be wanting pipes...

[snip]
> I'm not really sure that something like this belongs in a library
> for reading and writing sound files. Being able to split a multichannel 
> file and read samples from one channel at a time might be useful, 
> but at the moment it is not high on my list of priorities. Being
> able to mix a number of channels down to mono or a stereo pair
> was not something I even envisioned. I think it would be difficult
> to make it general enough for even a large majority of the cases where
> mixing is done.

I agree with Erik. I think it is important to layer out things:
this library looks like the lower layer, possibly in parallel
with the audio hardware handling layer (which in Bill Schottstaedt's
libsnd are held in the same library, and after all it might not
be a bad idea). In order to keep things *simple* (which was one
of the requirements I had in the mail that exploded this thread),
I think that anything more complex than this belongs to an
upper layer. This does not mean that the end package has a number
of layers together: it's just a conceptual division, but it
helps a lot approaching the library and using it.

ciao

Nicola

------------------------------------------------------------------------
Nicola Bernardini
E-mail: nicb@axnet.it
 
Re graphics: A picture is worth 10K words -- but only those to describe
the picture.  Hardly any sets of 10K words can be adequately described
with pictures.

From - Thu Aug 19 18:34:35 1999
Received: from ax-nicb.axnet.it (root@ax-nicb.axnet.it [194.184.60.149])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id QAA06339
	for <slinkp@ulster.net>; Thu, 19 Aug 1999 16:41:21 -0400
Received: (from nicb@localhost)
	by ax-nicb.axnet.it (8.8.7/8.8.7) id WAA15427;
	Thu, 19 Aug 1999 22:10:14 +0200
Date: Thu, 19 Aug 1999 22:10:13 +0200 (CEST)
From: Nicola Bernardini <nicb@axnet.it>
To: Paul Winkler <slinkp@ulster.net>
cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Mix
In-Reply-To: <37BBBC06.ADC57096@ulster.net>
Message-ID: <Pine.LNX.4.10.9908192208510.2702-100000@ax-nicb.axnet.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4e4547cf2c61bcf2b0936bd382621306

Today, Paul Winkler mi scrisse cio` che segue:

> Nicola Bernardini wrote:
> 
> > Now, regions are another story. I'd really like to see some serious
> > region editing a` la ProTools in Mix. I've worked with ProTools quite
> > a lot and if nobody has done anything about it by the end of september
> > I might give it a try (god knows I should not promise anything...).
> 
> Oh, Nicola, why do you tease me so? It's sheer torture!

Dear Paul,

as I specified: 'if nobody has done anything about it'...
You can start, I'll pick up at the end of september... :)

ciao

Nicola

------------------------------------------------------------------------
Nicola Bernardini
E-mail: nicb@axnet.it
 
Re graphics: A picture is worth 10K words -- but only those to describe
the picture.  Hardly any sets of 10K words can be adequately described
with pictures.

From - Thu Aug 19 18:34:40 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA11666
	for <slinkp@ulster.net>; Thu, 19 Aug 1999 17:11:35 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA20215 for linux-audio-dev-list; Thu, 19 Aug 1999 16:32:50 -0400
Received: from ax-nicb.axnet.it (ax-nicb.axnet.it [194.184.60.149]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA20212 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 19 Aug 1999 16:32:29 -0400
Received: (from nicb@localhost)
	by ax-nicb.axnet.it (8.8.7/8.8.7) id WAA15478;
	Thu, 19 Aug 1999 22:20:30 +0200
Date: Thu, 19 Aug 1999 22:20:30 +0200 (CEST)
From: Nicola Bernardini <nicb@axnet.it>
To: Dave Phillips <dlphilp@bright.net>
cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Mix
In-Reply-To: <37BC07D8.D1D5FA83@bright.net>
Message-ID: <Pine.LNX.4.10.9908192211150.2702-100000@ax-nicb.axnet.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 1ab847596618dd7165ce626d916dad8b

Dear Dave, dear all,

Today, Dave Phillips mi scrisse cio` che segue:

[snip]
DP> That part about "fairly easy"...wasn't it Wanda Landowska who observed
DP> that there's no such thing as an easy piece of music ? (Just poking,
DP> Nicola, don't take me seriously. You know far more about this stuff than
DP> I do, so if you say it's fairly easy then I'll take your word for it.
DP> But mix.c is scary stuff...)

well, I did'nt say 'fairly easy', I said '*fairly* easy' ;-)
It is exactly because mix.c is scary stuff that I'd like to get
more functionality on other side-applications. Whenever playback is
needed, Mix prepares a file, forks off a playback process feeding
it the file. Same for recording (even **easier** perhaps). We just
need to work out a mini-description of the file produced by mix,
then have the playback process parse it out and execute it.

DP> > There are some
DP> > good reasons, I think, to keep Mix out of real time - the first one
DP> > I could really use is to have infinite tracks, or infinite stack
DP> > of effects, etc. (up to memory limits of course). These are things
DP> > no CoolEdit nor ProTools nor whatever
DP> > can do because they always think in terms of real-time (while most
DP> > of the time work is done offline - just previewing is done in real-time).
DP> 
DP> I guess I'm still legacy-locked by my experience with Windoze-based
DP> editors and mixers. Nevertheless, I'm trying to find how the approach
DP> you espouse (or the approach taken by ecasound) would work with my own
DP> style. And I'm always willing to learn a better way...

Windoze can only have it one way, I want to have both :)
We will (one day) have real-time stuff like Quasimodo or Pd or jMax,
and then we *should* also have unlimited resource stuff like csound
and Mix (things that other OSes don't even think to do, don't ask me why).
We could even have csound and Mix doing both if possible (as it is
practically happening now), so that as machines get more and more
powerful we do more and more things...

[snip]
DP> When Richard Kent and I first prepared a Linux version of Mix the most
DP> persistent criticism I received was about its lack of support for
DP> regions. Unfortunately the current code is not workable (so sayeth Dr.
DP> Hammer) and should be dumped in favor of something that is. Well, the
DP> end of September draws nearer everyday... ;)

Unfortunately yes (my piece not ready yet!!!). Nobody hold her/his
breath, please.

ciao

Nicola

------------------------------------------------------------------------
Nicola Bernardini
E-mail: nicb@axnet.it
 
Re graphics: A picture is worth 10K words -- but only those to describe
the picture.  Hardly any sets of 10K words can be adequately described
with pictures.

From - Thu Aug 19 18:34:42 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA12174
	for <slinkp@ulster.net>; Thu, 19 Aug 1999 17:14:34 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA20209 for linux-audio-dev-list; Thu, 19 Aug 1999 16:31:51 -0400
Received: from ax-nicb.axnet.it (ax-nicb.axnet.it [194.184.60.149]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA20206 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 19 Aug 1999 16:31:32 -0400
Received: (from nicb@localhost)
	by ax-nicb.axnet.it (8.8.7/8.8.7) id WAA15506;
	Thu, 19 Aug 1999 22:25:45 +0200
Date: Thu, 19 Aug 1999 22:25:45 +0200 (CEST)
From: Nicola Bernardini <nicb@axnet.it>
To: Erik de Castro Lopo <erikd@zip.com.au>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] The future of libsndfile
In-Reply-To: <37BBF65B.7B1C8959@zip.com.au>
Message-ID: <Pine.LNX.4.10.9908192221040.2702-100000@ax-nicb.axnet.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 040a6350752f0ea6c96d93c4c3d784da

Today, Erik de Castro Lopo mi scrisse cio` che segue:

[snip]
EDC> Anyway, now I have explained it I am less convinced than I was. With a 
EDC> little encouragement I'll probably make a decision to change the read
EDC> and write operations from items to frames. From a coding point of
EDC> view its a trivial change but I'm going to try and come up with a 
EDC> way of making the change without breaking any existing apps.

How about having *both* in two different calls? (my trotzkist soul
comes out again and again :)

[snip]
EDC> I have also been having some thoughts along the lines of non-destructive
EDC> editing with edit lists etc. My conclucion was that none of the formats
EDC> libsndfile currently supports is all that well suited to this problem.
EDC> My idea was to make a new (or yet another) file format which would 
EDC> specifically be designed to be cross platform and allow non-destructive
EDC> editing. It would also be possible to write a rendering routine which
EDC> takes a file in this new format as input and mixes/renders it into one 
EDC> of the standard playback formats like WAV or AIFF. The only questions is
EDC> whether this should be part of the library or a separte application.

Let me insist. This is another layer of worms. Let's first try
and have a nice *simple* library. It's important. Non-destructive
editing may be done and is probably done and needed in zillion
different ways. Let's try to implement it first in some application
(like Mix, or the famous Juhana's editor, or whatever you like) and
see if there are enough points in common to build a library with it.
Please. :)

ciao

Nicola
------------------------------------------------------------------------
Nicola Bernardini
E-mail: nicb@axnet.it
 
Re graphics: A picture is worth 10K words -- but only those to describe
the picture.  Hardly any sets of 10K words can be adequately described
with pictures.

From - Thu Aug 19 18:34:48 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA22708
	for <slinkp@ulster.net>; Thu, 19 Aug 1999 18:11:33 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA20304 for linux-audio-dev-list; Thu, 19 Aug 1999 17:20:29 -0400
Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA20301 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 19 Aug 1999 17:20:25 -0400
Received: from hendrix (krusty41.zip.com.au [61.8.16.73])
	by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id HAA05771
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 20 Aug 1999 07:07:13 +1000 (EST)
Message-ID: <37BC7475.5F895A97@zip.com.au>
Date: Fri, 20 Aug 1999 07:17:41 +1000
From: Erik de Castro Lopo <erikd@zip.com.au>
Organization: Eric Conspiracy Secret Labs
X-Mailer: Mozilla 3.04Gold (X11; I; Linux 2.2.11 i586)
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] hardware vs. OS limits
References: <19990819142608.12740.qmail@hyperreal.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 48e65bbaa3950c31e89fc38a74bb44b0

est@hyperreal.org wrote:
> 
> I've got IDE and UW SCSI here, and they give me equal performance
> (even with my non-Intel chipset).  If I want real-time, I find I need
> to patch linux. :)

Questions, so many questions :-).

What application is this? 

Do you know if its using the standard realtime scheduler or 
rt-linux? 

Has anybody made a comparision of the performance of a standard process
vs a realtime process (ie using sched_setscheduler) vs rt-linux vs
linux kernel with patches? Care to write a paper about it?

Erik
-- 
+-------------------------------------------------+
     Erik de Castro Lopo     erikd@zip.com.au
+-------------------------------------------------+
The day Microsoft makes something that doesn't suck is 
probably the day they start making vacuum cleaners.

From - Thu Aug 19 18:34:49 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA23221
	for <slinkp@ulster.net>; Thu, 19 Aug 1999 18:14:37 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA20314 for linux-audio-dev-list; Thu, 19 Aug 1999 17:29:07 -0400
Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA20311 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 19 Aug 1999 17:29:03 -0400
Received: from hendrix (krusty41.zip.com.au [61.8.16.73])
	by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id HAA06025;
	Fri, 20 Aug 1999 07:15:38 +1000 (EST)
Message-ID: <37BC766E.60953A21@zip.com.au>
Date: Fri, 20 Aug 1999 07:26:06 +1000
From: Erik de Castro Lopo <erikd@zip.com.au>
Organization: Eric Conspiracy Secret Labs
X-Mailer: Mozilla 3.04Gold (X11; I; Linux 2.2.11 i586)
MIME-Version: 1.0
To: Nicola Bernardini <nicb@axnet.it>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Nicola Bernardini's sound file library  comments
References: <Pine.LNX.4.10.9908191757400.2702-100000@ax-nicb.axnet.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 44c4ff5fd4ab00b65a6ae459fb5b3383

Nicola Bernardini wrote:
> 
> Yesterday, Erik de Castro Lopo mi scrisse cio` che segue:
> 
> [snip]
> > One of the things I have on my TODO list is to make libsndfile work
> > so it can read and write pipes. Unfortunately, once one has started
> > writing a large amount of data to a pipe it is not possible to fseek ()
> > back to the beginning of the file and correct the header like one can
> > with regular files. I see no way around this problem.
> 
> how does a pager like 'less' do? less can read infinitely large
> files from a pipe and go back and forth. Or am I wrong?

Interesting observation Nicola! On read from a pipe it may well be 
possible to seek back an forth thru the whole file. Write however
is quite a different matter. Once I get pipes working I'll do some
experimentation.

Erik
-- 
+-------------------------------------------------+
     Erik de Castro Lopo     erikd@zip.com.au
+-------------------------------------------------+
Windows NT : An evolutionary dead end.

From - Thu Aug 19 18:34:51 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA24284
	for <slinkp@ulster.net>; Thu, 19 Aug 1999 18:20:35 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA20339 for linux-audio-dev-list; Thu, 19 Aug 1999 17:36:34 -0400
Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA20336 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 19 Aug 1999 17:36:30 -0400
Received: from hendrix (krusty41.zip.com.au [61.8.16.73])
	by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id HAA06257;
	Fri, 20 Aug 1999 07:23:05 +1000 (EST)
Message-ID: <37BC782D.6022F3A1@zip.com.au>
Date: Fri, 20 Aug 1999 07:33:33 +1000
From: Erik de Castro Lopo <erikd@zip.com.au>
Organization: Eric Conspiracy Secret Labs
X-Mailer: Mozilla 3.04Gold (X11; I; Linux 2.2.11 i586)
MIME-Version: 1.0
To: Nicola Bernardini <nicb@axnet.it>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] The future of libsndfile
References: <Pine.LNX.4.10.9908192221040.2702-100000@ax-nicb.axnet.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 512a0e37c585901b05ee2e2ccb6d2ec5

Nicola Bernardini wrote:
> 
> Today, Erik de Castro Lopo mi scrisse cio` che segue:
> 
> [snip]
> EDC> Anyway, now I have explained it I am less convinced than I was. With a
> EDC> little encouragement I'll probably make a decision to change the read
> EDC> and write operations from items to frames. From a coding point of
> EDC> view its a trivial change but I'm going to try and come up with a
> EDC> way of making the change without breaking any existing apps.
> 
> How about having *both* in two different calls? (my trotzkist soul
> comes out again and again :)

That was the idea I was playing around with.

> [snip]
> EDC> I have also been having some thoughts along the lines of non-destructive
> EDC> editing with edit lists etc. My conclucion was that none of the formats
> EDC> libsndfile currently supports is all that well suited to this problem.
> EDC> My idea was to make a new (or yet another) file format which would
> EDC> specifically be designed to be cross platform and allow non-destructive
> EDC> editing. It would also be possible to write a rendering routine which
> EDC> takes a file in this new format as input and mixes/renders it into one
> EDC> of the standard playback formats like WAV or AIFF. The only questions is
> EDC> whether this should be part of the library or a separte application.
> 
> Let me insist. This is another layer of worms. Let's first try
> and have a nice *simple* library. It's important. Non-destructive
> editing may be done and is probably done and needed in zillion
> different ways. Let's try to implement it first in some application
> (like Mix, or the famous Juhana's editor, or whatever you like) and
> see if there are enough points in common to build a library with it.
> Please. :)

I have more than enough work cut out for myself. The new non-destructive
editing format was a long term goal. Obviously such a thing requires
a lot of thought.

Erik
-- 
+-------------------------------------------------+
     Erik de Castro Lopo     erikd@zip.com.au
+-------------------------------------------------+
J. Headley: "God, root, what is difference ?"
G. Haverland: "God can change the byte order on the CPU, root can't."

From - Thu Aug 19 19:04:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA31788
	for <slinkp@ulster.net>; Thu, 19 Aug 1999 19:05:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA20454 for linux-audio-dev-list; Thu, 19 Aug 1999 18:26:12 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id SAA20450 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 19 Aug 1999 18:26:04 -0400
From: est@hyperreal.org
Received: (qmail 25284 invoked by uid 162); 19 Aug 1999 22:16:32 -0000
Message-ID: <19990819221632.25283.qmail@hyperreal.org>
Subject: [linux-audio-dev] linux real-time audio performance
In-Reply-To: <37BC7475.5F895A97@zip.com.au> from Erik de Castro Lopo at "Aug
 20, 1999 07:17:41 am"
To: Erik de Castro Lopo <erikd@zip.com.au>
Date: Thu, 19 Aug 1999 15:16:31 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8003
X-Mozilla-Status2: 00000000
X-UIDL: 6d1bb3155603d94f0fa9f41cc49c6c7d

Erik de Castro Lopo discourseth:
> est@hyperreal.org wrote:
> > 
> > I've got IDE and UW SCSI here, and they give me equal performance
> > (even with my non-Intel chipset).  If I want real-time, I find I need
> > to patch linux. :)
> 
> Questions, so many questions :-).
> 
> What application is this? 

latencytest, oolaboola, rtcskips (a more q&d dropout test than
latencytest).

> Do you know if its using the standard realtime scheduler or 
> rt-linux? 

Standard POSIX real-time.

> Has anybody made a comparision of the performance of a standard process
> vs a realtime process (ie using sched_setscheduler) vs rt-linux vs
> linux kernel with patches?

I've done all of that..with various kernel versions and patches except
rtlinux.  You can pretty much count on occasional dropouts >50ms on
stock linux.  pre-2.2.8 is even worse.  Using linux 2.2.10 and the
latest (non-public) patches this comes down to 3ms..and at that point
it starts to become processor rather than disk dependent so I should
say that that's on my amd k6-2/350.

rtlinux apparently can provide sample-level latency even while a stock
linux is doing wacky things (I have no reason to doubt David Olofson
on this).  However, rtlinux has a completely different development
architecutre than POSIX (some commonality is emerging due to David's
efforts, but differences will remain).  Also, as soon as a single
element of control goes through standard linux then control latency is
at the mercy of standard linux even if data latency is maintained by
rtlinux.

> Care to write a paper about it?

Well, these answers should be integrated into Paul Winkler's FAQ..and
people should keep asking questions. :)

The most urgent question to me is how we, as a community, can lobby
consistently and constructively for attaining and maintaining high
standards in this area.

Eric

From - Fri Aug 20 11:41:53 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA28853
	for <slinkp@ulster.net>; Fri, 20 Aug 1999 01:24:32 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA20969 for linux-audio-dev-list; Fri, 20 Aug 1999 00:37:32 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA20964 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 20 Aug 1999 00:37:29 -0400
Received: from ulster.net (port244.king.ulster.net [208.242.160.245])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id AAA23932;
	Fri, 20 Aug 1999 00:48:33 -0400
Message-ID: <37BC917F.B36561@ulster.net>
Date: Thu, 19 Aug 1999 19:21:35 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: est@hyperreal.org
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] linux real-time audio performance
References: <19990819221632.25283.qmail@hyperreal.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5311d30555e0d6d6b8c5b8ddaf20338e

est@hyperreal.org wrote:
> 
> Erik de Castro Lopo discourseth:
> > Has anybody made a comparision of the performance of a standard process
> > vs a realtime process (ie using sched_setscheduler) vs rt-linux vs
> > linux kernel with patches?
> 
> I've done all of that..with various kernel versions and patches except
> rtlinux.  You can pretty much count on occasional dropouts >50ms on
> stock linux.  pre-2.2.8 is even worse.  Using linux 2.2.10 and the
> latest (non-public) patches this comes down to 3ms..and at that point
> it starts to become processor rather than disk dependent so I should
> say that that's on my amd k6-2/350.

Just making sure I've got this right... You're talking about with the
POSIX realtime stuff, right? Have you compared this to equivalent code
that doesn't use the POSIX stuff?

(snip)
> > Care to write a paper about it?
> 
> Well, these answers should be integrated into Paul Winkler's FAQ..and
> people should keep asking questions. :)

Will do. I'm a bit slowed down with it at the moment. Maybe next week
some new stuff will be up. the main thing I am working on is adding
user-level posting/editing capability. There are some cgi packages out
there that do this; I'm checking them out to see what would work for me.
 

----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================


From - Fri Aug 20 00:41:48 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA10141
	for <slinkp@ulster.net>; Thu, 19 Aug 1999 23:19:44 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA20803 for linux-audio-dev-list; Thu, 19 Aug 1999 22:35:37 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA20800 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 19 Aug 1999 22:35:34 -0400
Received: from ux01 (dgslomin@ux01 [128.112.169.21])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id WAA26785
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 19 Aug 1999 22:31:32 -0400 (EDT)
Received: from localhost by ux01 (8.8.8+Sun) id WAA12143; Thu, 19 Aug 1999 22:31:31 -0400 (EDT)
Date: Thu, 19 Aug 1999 22:31:25 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] re: less and seeking on piped input
In-Reply-To: <37BC766E.60953A21@zip.com.au>
Message-ID: <Pine.GSO.4.10.9908192216250.10441-100000@ux01.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8003
X-Mozilla-Status2: 00000000
X-UIDL: de36c60a7ff05ba52e187b5cc49b3e18


Nicola> how does a pager like 'less' do? less can read infinitely large
Nicola> files from a pipe and go back and forth. Or am I wrong?

Erik> Interesting observation Nicola! On read from a pipe it may well be 
Erik> possible to seek back an forth thru the whole file. Write however
Erik> is quite a different matter. Once I get pipes working I'll do some
Erik> experimentation.

I always assumed that it copied stdin into a temp file, or at least into
buffers in memory.  This is fine for text (as with less), but audio data
is orders of magnitude larger.  This could be problematic because both
methods (temp file or buffers so large that they cause paging) mean extra
disk access, the latency of which might well defeat the whole purpose.

BTW, Erik, getting pipes to work is really trivial if you already have
code that reads a file (sequentially, not random access).  Just do an
fdopen on file descriptor zero, and you're done.  

You can also test the limits of what pipes can do without modifying your
code at all by using named pipes (fifos).  These are wonderful but often
overlooked "files" (in the manner that devices are "files") which you can
open for reading and writing at once by different apps.  Take a look at
the mkfifo man page.  I have no idea why they're not used more often.

I had a lot of fun playing with piping MIDI messages between little filter
apps in realtime (transpose, add parallel chords, etc).  MIDI itself is
low enough bandwidth that I didn't have any latency problems whatsoever,
although I didn't rig up anything to time down to the microsecond.  I can
send my code if you'd like, although it's nothing fancy.

Div.

From - Fri Aug 20 11:41:55 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA28899
	for <slinkp@ulster.net>; Fri, 20 Aug 1999 01:24:53 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA20972 for linux-audio-dev-list; Fri, 20 Aug 1999 00:37:34 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA20968 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 20 Aug 1999 00:37:31 -0400
Received: from ulster.net (port244.king.ulster.net [208.242.160.245])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id AAA23948;
	Fri, 20 Aug 1999 00:48:39 -0400
Message-ID: <37BCDC26.8AD3C4A@ulster.net>
Date: Fri, 20 Aug 1999 00:40:06 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
CC: Nicola Bernardini <nicb@axnet.it>
Subject: Re: [linux-audio-dev] Re: Mix
References: <Pine.LNX.4.10.9908192211150.2702-100000@ax-nicb.axnet.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 8f68705042fc07ce103b09b13adc1583

Nicola Bernardini wrote:
> and then we *should* also have unlimited resource stuff like csound
> and Mix ...(snip)

Has it occurred to anyone but me that, at the moment, the functionality
of mix is a subset of the functionality of csound? And that, since Mix
stores your work as a simple (even human-readable) text file, a
mix-to-csound translation utility is theoretically possible?

To create such a utility, one would have to:
1) Write a Csound orchestra that can do everything Mix can do.
2) Write a script (Perl? Python? Whatever?) that translates mixfiles
into a score that can be used with this special Csound orc.

I could imagine a lot of uses for such things: Throw together some ideas
in Mix, then export the mixfile to a csound score which can then be
extended with ten thousand effects... 

I've been thinking for a while that Csound can, in principle, do a lot
of the things a full digital studio can do; it just lacks nice
interfaces for most tasks. Cecilia and Quasimodo demonstrate the
potential here. One could conceivable create a Csound-based soundfile
editor that does totally non-destructive "editing" by using diskin with
different skip times. Rendering a waveform display of your edits would
be an interesting problem.


----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Fri Aug 20 11:41:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA29361
	for <slinkp@ulster.net>; Fri, 20 Aug 1999 01:27:44 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA20986 for linux-audio-dev-list; Fri, 20 Aug 1999 00:40:30 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA20977 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 20 Aug 1999 00:40:27 -0400
Received: from ulster.net (port244.king.ulster.net [208.242.160.245])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id AAA24373;
	Fri, 20 Aug 1999 00:51:35 -0400
Message-ID: <37BCDD2E.E1562C0D@ulster.net>
Date: Fri, 20 Aug 1999 00:44:30 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: David Slomin <dgslomin@CS.Princeton.EDU>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] re: less and seeking on piped input
References: <Pine.GSO.4.10.9908192216250.10441-100000@ux01.CS.Princeton.EDU>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f5cfe606b5d46f19c7fd5e04589bdd9a

David Slomin wrote:

> I had a lot of fun playing with piping MIDI messages between little filter
> apps in realtime (transpose, add parallel chords, etc).  MIDI itself is
> low enough bandwidth that I didn't have any latency problems whatsoever,
> although I didn't rig up anything to time down to the microsecond.  I can
> send my code if you'd like, although it's nothing fancy.

Please post it somewhere, or send me a copy. I'd love to play with this! 

--PW

---------------    paul winkler    ------------------

From - Fri Aug 20 11:41:57 1999
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA32087
	for <slinkp@ulster.net>; Fri, 20 Aug 1999 01:54:35 -0400
From: est@hyperreal.org
Received: (qmail 21976 invoked by uid 162); 20 Aug 1999 05:40:38 -0000
Message-ID: <19990820054038.21975.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] linux real-time audio performance
In-Reply-To: <37BC917F.B36561@ulster.net> from Paul Winkler at "Aug 19, 1999
 07:21:35 pm"
To: Paul Winkler <slinkp@ulster.net>
Date: Thu, 19 Aug 1999 22:40:38 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 22a0722eceaf49172bc2fe2b6ce9f934

Paul Winkler discourseth:
> 
> Just making sure I've got this right... You're talking about with the
> POSIX realtime stuff, right?

Yes indeed..sorry I was vague there. :)

> Have you compared this to equivalent code that doesn't use the POSIX stuff?

Not extensively.  During early oolaboola development it became clear
that going real-time eliminated the totally reliable dropout each time
top(1) updated and during much X activity (this with a 1/50th second
audio buffer).  That was enough data for me. :)  Also, It's pretty easy
to see the limits of non-realtime processes a priori.  I believe the
default linux time-slice is 210ms.  A compute-bound process can
monopolize the cpu for that long unless a real-time process grabs it.

> > > Care to write a paper about it?
> > 
> > Well, these answers should be integrated into Paul Winkler's FAQ..and
> > people should keep asking questions. :)
> 
> Will do. I'm a bit slowed down with it at the moment. Maybe next week
> some new stuff will be up. the main thing I am working on is adding
> user-level posting/editing capability. There are some cgi packages out
> there that do this; I'm checking them out to see what would work for me.

Neato. :)  I really like your FAQ and I think it can be a great
focusing device for multimedia support concerns.

Eric

From - Fri Aug 20 11:42:07 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id IAA24042
	for <slinkp@ulster.net>; Fri, 20 Aug 1999 08:23:04 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id HAA21640 for linux-audio-dev-list; Fri, 20 Aug 1999 07:18:20 -0400
Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA21637 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 20 Aug 1999 07:18:15 -0400
Received: from hendrix (cartman107.zip.com.au [61.8.20.235])
	by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id VAA23747;
	Fri, 20 Aug 1999 21:04:52 +1000 (EST)
Message-ID: <37BD38CB.455544BA@zip.com.au>
Date: Fri, 20 Aug 1999 21:15:23 +1000
From: Erik de Castro Lopo <erikd@zip.com.au>
Organization: Eric Conspiracy Secret Labs
X-Mailer: Mozilla 3.04Gold (X11; I; Linux 2.2.11 i586)
MIME-Version: 1.0
To: David Slomin <dgslomin@CS.Princeton.EDU>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] re: less and seeking on piped input
References: <Pine.GSO.4.10.9908192216250.10441-100000@ux01.CS.Princeton.EDU>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 47e610802c0327d5aadc3f221e5356c2

David Slomin wrote:

<snip>

> BTW, Erik, getting pipes to work is really trivial if you already have
> code that reads a file (sequentially, not random access).  Just do an
> fdopen on file descriptor zero, and you're done.

Or use variables stdin/stdout as the FILE* parameter for fread/frwrite.

> You can also test the limits of what pipes can do without modifying your
> code at all by using named pipes (fifos).  These are wonderful but often
> overlooked "files" (in the manner that devices are "files") which you can
> open for reading and writing at once by different apps.  Take a look at
> the mkfifo man page.  I have no idea why they're not used more often.

Good idea.

I've actually used them before. I have a little daemon program running
which writes to a named pipe (".signature") in my home directory.
Whenever
I send mail or a newsgroup posting Netscape reads this file and the
daemon
then writes a new message to the named pipe. Kind of cute.

Erik
-- 
+-------------------------------------------------+
     Erik de Castro Lopo     erikd@zip.com.au
+-------------------------------------------------+
Linux: generous programmers from around the world all join
forces to help you shoot yourself in the foot for free.

From - Fri Aug 20 11:42:02 1999
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id HAA17805
	for <slinkp@ulster.net>; Fri, 20 Aug 1999 07:09:02 -0400
Received: from bright.net (find-cas1-cs-25.dial.bright.net [209.143.26.128])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id GAA13130;
	Fri, 20 Aug 1999 06:55:01 -0400 (EDT)
Sender: root@sparticus.bright.net
Message-ID: <37BD3A4A.C889ADDF@bright.net>
Date: Fri, 20 Aug 1999 07:21:46 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Winkler <slinkp@ulster.net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Mix
References: <Pine.LNX.4.10.9908192211150.2702-100000@ax-nicb.axnet.it> <37BCDC26.8AD3C4A@ulster.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 4b7788a0149bd4a2b9b4ba331a1dafc3

Paul Winkler wrote:

> Has it occurred to anyone but me that, at the moment, the functionality
> of mix is a subset of the functionality of csound? And that, since Mix
> stores your work as a simple (even human-readable) text file, a
> mix-to-csound translation utility is theoretically possible?
> 
> To create such a utility, one would have to:
> 1) Write a Csound orchestra that can do everything Mix can do.
> 2) Write a script (Perl? Python? Whatever?) that translates mixfiles
> into a score that can be used with this special Csound orc.

Paul, I'm not sure I wouldn't just use C instead of all that glue.
However, following your example, I think it's a pretty cool idea. I
might just have to mess around with it...
 
> ...One could conceivable create a Csound-based soundfile
> editor that does totally non-destructive "editing" by using diskin with
> different skip times. Rendering a waveform display of your edits would
> be an interesting problem.

Well, Csound already has simple hooks into X displays, so perhaps it
isn't really all that difficult. And there's the CLM/Snd connection to
look at too.

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Fri Aug 20 11:42:08 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA00877
	for <slinkp@ulster.net>; Fri, 20 Aug 1999 09:41:46 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA21768 for linux-audio-dev-list; Fri, 20 Aug 1999 08:57:20 -0400
Received: from cmn14.stanford.edu (cmn14.Stanford.EDU [36.49.0.93]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA21765 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 20 Aug 1999 08:57:17 -0400
Received: (from bil@localhost)
	by cmn14.stanford.edu (8.8.8/8.8.8) id FAA09174
	for linux-audio-dev@ginette.musique.umontreal.ca; Fri, 20 Aug 1999 05:54:37 -0700 (PDT)
Message-Id: <199908201254.FAA09174@cmn14.stanford.edu>
Content-Type: text/plain
MIME-Version: 1.0 (NeXT Mail 3.3 v148.2.1)
In-Reply-To: <Pine.LNX.4.10.9908192221040.2702-100000@ax-nicb.axnet.it>
X-Nextstep-Mailer: Mail 3.3 [m68k] (Enhance 2.2p2)
Received: by NeXT.Mailer (1.148.2.1)
From: Bill Schottstaedt <bil@ccrma.Stanford.EDU>
Date: Fri, 20 Aug 1999 05:54:35 -0700
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] non-destructive editing
References: <Pine.LNX.4.10.9908192221040.2702-100000@ax-nicb.axnet.it>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 37c6ed11627445f61aa4419c8e3e8d03

> Let's first try
> and have a nice *simple* library. It's important. Non-destructive
> editing may be done and is probably done and needed in zillion
> different ways. Let's try to implement it first in some application

One example is snd-edits.c in Snd; I wasn't thinking of it
as something for a library, so it's not that style of code,
but it appears to work.  If there's interest I could write
a description of it ("the code *is* the documentation").


(An aside about being able to read one channel of a multi-channel
file -- this becomes important when you're dealing with 8
or 24 channel files, both in time and memory; and another
aside, now that I'm typing (I'm going to regret this...),
the choice of integer format in sndlib was not made for
reasons of computational speed).

From - Fri Aug 20 11:42:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA06238
	for <slinkp@ulster.net>; Fri, 20 Aug 1999 10:17:13 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA21836 for linux-audio-dev-list; Fri, 20 Aug 1999 09:32:41 -0400
Received: from kaybee.org (kaybee.resnet.gatech.edu [128.61.15.250]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA21833 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 20 Aug 1999 09:32:38 -0400
Received: from localhost (rob@localhost)
	by kaybee.org (8.8.7/8.8.7) with ESMTP id JAA09651;
	Fri, 20 Aug 1999 09:29:34 -0400
Date: Fri, 20 Aug 1999 09:29:34 -0400 (EDT)
From: rob <rob@kaybee.org>
To: Erik de Castro Lopo <erikd@zip.com.au>
cc: Nicola Bernardini <nicb@axnet.it>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] The future of libsndfile
In-Reply-To: <37BC782D.6022F3A1@zip.com.au>
Message-ID: <Pine.LNX.4.10.9908200924370.9619-100000@kaybee.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 555854e13577258540894922f001a9ff

On Fri, 20 Aug 1999, Erik de Castro Lopo wrote:

> Nicola Bernardini wrote:
> > 
> > Let me insist. This is another layer of worms. Let's first try
> > and have a nice *simple* library. It's important. Non-destructive
> > editing may be done and is probably done and needed in zillion
> > different ways. 

> I have more than enough work cut out for myself. The new non-destructive
> editing format was a long term goal. Obviously such a thing requires
> a lot of thought.
> 

	indeed, first things first.  the nice part is that this needn't be
done in the same library, and it doesn't really depend on anything else.
integration (if and when) is just a matter of hacking the read/write
functions to allow the app to use the non-dest. editing transparently.
the important part is that it be in some library available for re/use.  
	hooray another thing on my todo list (right there under 'save
the world' and 'have breakfast' :D) .

				rob

----
Rob Melby
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
Internet: rob@kaybee.org, gt4255a@prism.gatech.edu

From - Fri Aug 20 13:15:18 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA29929
	for <slinkp@ulster.net>; Fri, 20 Aug 1999 12:55:29 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA22059 for linux-audio-dev-list; Fri, 20 Aug 1999 12:11:22 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id MAA22056 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 20 Aug 1999 12:11:19 -0400
From: est@hyperreal.org
Received: (qmail 8724 invoked by uid 162); 20 Aug 1999 16:08:40 -0000
Message-ID: <19990820160840.8723.qmail@hyperreal.org>
Subject: [linux-audio-dev] cecilia no go :(
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Fri, 20 Aug 1999 09:08:39 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 74021671d2372ab76c4d00e7df93cc96

It freezes on the pretty splash screen and stdout say it's checking
the csound version (which happens to be 3.49.0d).  ps shows both
cecilia and csound sleeping and the splash doesn't get updated when
covered/uncovered.  This is cecilia2.0.2 off Dave's ftp site.

Any ideas?

Eric

From - Fri Aug 20 13:15:15 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA29879
	for <slinkp@ulster.net>; Fri, 20 Aug 1999 12:54:57 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA22052 for linux-audio-dev-list; Fri, 20 Aug 1999 12:08:23 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA22049 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 20 Aug 1999 12:08:20 -0400
Received: from ulster.net (annex2-port47.ulster.net [208.133.193.47])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id MAA24730;
	Fri, 20 Aug 1999 12:19:32 -0400
Message-ID: <37BD7E50.678BD838@ulster.net>
Date: Fri, 20 Aug 1999 12:12:00 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Dave Phillips <dlphilp@bright.net>
CC: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Mix
References: <Pine.LNX.4.10.9908192211150.2702-100000@ax-nicb.axnet.it> <37BCDC26.8AD3C4A@ulster.net> <37BD3A4A.C889ADDF@bright.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 08d7434b8480c97e4cac4d227c253d0e

Dave Phillips wrote:
> 
> Paul Winkler wrote:
> 
> > Has it occurred to anyone but me that, at the moment, the functionality
> > of mix is a subset of the functionality of csound? And that, since Mix
> > stores your work as a simple (even human-readable) text file, a
> > mix-to-csound translation utility is theoretically possible?
> >
> > To create such a utility, one would have to:
> > 1) Write a Csound orchestra that can do everything Mix can do.
> > 2) Write a script (Perl? Python? Whatever?) that translates mixfiles
> > into a score that can be used with this special Csound orc.
> 
> Paul, I'm not sure I wouldn't just use C instead of all that glue.
> However, following your example, I think it's a pretty cool idea. I
> might just have to mess around with it...

I honestly think "all that glue" leaves you with less to deal with than
just using C. For instance, both Csound and the common scripting
languages deal with all memory allocation for you. And Csound is pretty
well-developed and documented and understood by lots of people. I hear
people on this list talking about separating the "engine" from the
interface; why not use an engine that already exists? When Quasimodo
reaches a point of reasonable stability, maybe one could use Q instead.

Not that I'm saying Csound could be used for just anything... its
conditional branching syntax is pretty ancient. Personally I find that
once I have more than a couple of "goto"s in a csound orc, I have a hard
time keeping track of what's actually going on. Hey, PBD, is it too much
to hope that Quasimodo will have such things as "while" and "for"
statements? Or allow other results of "if" than "goto"? That would
probably complicate backwards compatibility, but it might be worth it.

And I do admit the "wave editor" idea is probably a stretch.

> Well, Csound already has simple hooks into X displays, so perhaps it
> isn't really all that difficult. And there's the CLM/Snd connection to
> look at too.

That might be a better way to go. Except then you have to understand
LISP. One of these days I'll try it...
 
> == Dave Phillips
> 
>        http://www.bright.net/~dlphilp/index.html
>    http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

-- 

----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Fri Aug 20 13:15:19 1999
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA31962
	for <slinkp@ulster.net>; Fri, 20 Aug 1999 13:05:59 -0400
From: est@hyperreal.org
Received: (qmail 18891 invoked by uid 162); 20 Aug 1999 16:51:57 -0000
Message-ID: <19990820165157.18890.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] Re: Mix
In-Reply-To: <37BD7E50.678BD838@ulster.net> from Paul Winkler at "Aug 20, 1999
 12:12:00 pm"
To: Paul Winkler <slinkp@ulster.net>
Date: Fri, 20 Aug 1999 09:51:57 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 976477064f9daef886c925b41622b822

Paul Winkler discourseth:
> > >
> > > To create such a utility, one would have to:
> > > 1) Write a Csound orchestra that can do everything Mix can do.
> > > 2) Write a script (Perl? Python? Whatever?) that translates mixfiles
> > > into a score that can be used with this special Csound orc.
> > 
> > Paul, I'm not sure I wouldn't just use C instead of all that glue.
> > However, following your example, I think it's a pretty cool idea. I
> > might just have to mess around with it...
> 
> I honestly think "all that glue" leaves you with less to deal with than
> just using C.

Well, presumably mix can parse its mixfiles?  If so, then it might be
easiest to add an option to mix to generate a .sco file, *or* to dump
the mix file in a form that can be even more easily and reliably
converted by (e.g.) a perl script.  Maybe that's what Dave was
thinking..in any case, it occured to me. :)

> > Well, Csound already has simple hooks into X displays, so perhaps it
> > isn't really all that difficult. And there's the CLM/Snd connection to
> > look at too.
> 
> That might be a better way to go. Except then you have to understand
> LISP. One of these days I'll try it...

..ah, and lisp will change the way you think and program forever. :)

Eric

From - Sat Aug 21 01:01:51 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA13769
	for <slinkp@ulster.net>; Fri, 20 Aug 1999 18:42:17 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA22529 for linux-audio-dev-list; Fri, 20 Aug 1999 17:53:32 -0400
Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA22526 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 20 Aug 1999 17:53:26 -0400
Received: (from uucp@localhost)
	by news-ma.rhein-neckar.de (8.8.8/8.8.8) with UUCP id XAA10377;
	Fri, 20 Aug 1999 23:50:20 +0200 (CEST)
	(envelope-from andreas@avix.rhein-neckar.de)
Received: from localhost (andreas@localhost [127.0.0.1])
	by avix.localnet (8.9.3/8.9.3) with ESMTP id CAA01139;
	Sat, 21 Aug 1999 02:36:34 +0200
Date: Sat, 21 Aug 1999 02:36:34 +0200 (MEST)
From: Andreas Voss <andreas@avix.rhein-neckar.de>
X-Sender: andreas@avix.localnet
To: David Slomin <dgslomin@CS.Princeton.EDU>, eli+@cs.cmu.edu
cc: Andreas Voss <andreas@avix.rhein-neckar.de>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Timed Event Editor Framework
In-Reply-To: <199908111845.OAA03725@ginette.musique.umontreal.ca>
Message-ID: <Pine.LNX.4.10.9908202340370.464-100000@avix.localnet>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 34d528aeaee3570345285a04905f9297

I've been on vacation, so this mail is a little late.

On Wed, 11 Aug 1999, Eli Brandt wrote:

> The way I think, I'd prefer a music sequencer that handles abstract
> time-structured data and maps it to MIDI.  

BIG agreement.

> For example, if I have some wiggly control gesture, I don't want to
> record it as a stream of some controller.  Because I _might_ want to
> map it to that controller, but I might also want to apply it to attack
> velocity, note duration, whatever. 

Also the end user wants to edit e.g the modulation wheel value and does
not want to worry about its MIDI representation (LSB/MSB in different
controller messages).


What I would really like to see/build is a highly configurable, universal
editor for abstract timed events. I'm thinking of an editor, that is aware
of timed events that have (mostly) numeric parameters and allows to edit
these. This editor should not know about the nature of the parameters,
e.g. it should not be hardcoded, how to present the pitch-parameter of a
midi note event to the user. This could be described by metadata
(configuration file, java-beans etc). So this thing could be seen as a
framework or library, from which you can build specialized editors for
different tasks.

There are many advantages of such an approach:

* different tasks

Editing a csound .sco file and a MIDI files is very similar. In MIDI you
place note events on time/pitch axis and adjust velocity and maybe
aftertouch. In csound you place i-events on a time (and probably pitch)
axis and adjust some user-defined parameters. In MIDI you edit some
controllers like volume, reverb, filter resonance etc, which differ with
vendors (XG, GS, GM) and representation (controller, sysex). In csound you
have similar events (reverb etc) with a user defined representation.

Another appliaction would be a mixer for audio files (e.g. mixdown
singular drum instruments to a complete drum loop). Here you place the
'audio events' on time/instrument axis.

Another useful event type in both worlds (midi + csound) would be a
phrase event, an event that contains other events. This may be used
- to structure a song
- to use predefined patterns or song fragments out of a library
- invent new event types like a chord event (you place Em7 somewhere
instead of its single notes)

There could be more esoteric event types, e.g. algorithm events that may
generate new events or modify existing events.

* reuse of code

Think of a piano roll editor, a window where you can edit small rectangles
(note events). x-axis is midi clock, y-axis is pitch. You could use this
editor to edit any two dimensional data, e.g. you could use this editor to
arrange a song by replacing the y-axis with the track-no and edit phrase
events instead of note events. Or you can place MIDI keysignature events
by replacing y with the possible 12 tunes. Or edit the value of a
controller over time, or note-velocity over note-pitch (e.g. to make high
notes louder), or ...

Another editor would be a curve painter, where you can e.g. paint the
value of the pitch wheel (y-axis) over time (x-axis). There are many
possible values for the y-axis for this editor like velocity, LFO, reverb,
volumen etc for MIDI.

There should be a general property editor, that allows to access all
properties of a selection. The metadata should provide a specialized GUI
component for each parameter type, e.g. the value of a midi program change
could be picked out of a list of instrument names, the value of the midi
clock could be typed in as 'bar:step:tick' and so on. This property editor
is independend of any specific event type an can be used for standard MIDI
evnets (like note), esoteric events (like chord or algorithm), csound
events (that may have many parameters) etc.

* extensibility

The framework should provide services like 
- general GUI like undo/redo, selections, cut/copy/paste, etc 
- interfaces for different backends (like midi, csound) 
- metadata handling 
- GUI components like axis beans for different editors (pitch axis, midi
  clock axis, table axis for track/phrase arrangement window) 
- complete editors like rectangle-editor (piano roll, arrangement window),
  property sheet, event list, curve painter 
- simple algorithms (linear interpolation from start value to end value) 
-...

Such a framework should be easy to extend with new editors, event types
and file formats (.mid, .sco)


I have been thinking of writing such a thing in java, but progress is very
slow. All I have so far is a few UML diagrams and some experimental GUI
stuff ...

Comments?

Andreas

From - Sat Aug 21 01:02:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA18319
	for <slinkp@ulster.net>; Sat, 21 Aug 1999 00:27:11 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA23380 for linux-audio-dev-list; Fri, 20 Aug 1999 23:29:18 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA23377 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 20 Aug 1999 23:29:14 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id XAA16234
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 20 Aug 1999 23:24:53 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id XAA29732; Fri, 20 Aug 1999 23:24:53 -0400 (EDT)
Date: Fri, 20 Aug 1999 23:24:51 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: Timed Event Editor Framework
In-Reply-To: <Pine.LNX.4.10.9908202340370.464-100000@avix.localnet>
Message-ID: <Pine.GSO.4.10.9908202117200.25004-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8003
X-Mozilla-Status2: 00000000
X-UIDL: 782f8fe79206f199673a059270bb9b50

On Sat, 21 Aug 1999, Andreas Voss wrote:

> Also the end user wants to edit e.g the modulation wheel value and does
> not want to worry about its MIDI representation (LSB/MSB in different
> controller messages).

s/the end user/some end users/

I hate software that thinks it is always smarter than the user.  There are
perfectly valid situations where a user may want to deal with raw messages
instead of compound pseudo messages.  As a simple example, most of the
time, you would want note-on and note-off events to be combined into
note-with-duration pseudo events, but if you're addressing a drum machine,
it is perfectly valid to have note-on's without corresponding note-off's.
 
That said, I think it is equally important to support the pseudo messages
for common cases, as long as they can be toggled on and off by the user
(and by plugins... I already have an example that needs that capability).

> What I would really like to see/build is a highly configurable, universal
> editor for abstract timed events. I'm thinking of an editor, that is aware
> of timed events that have (mostly) numeric parameters and allows to edit
> these. This editor should not know about the nature of the parameters,
> e.g. it should not be hardcoded, how to present the pitch-parameter of a
> midi note event to the user. This could be described by metadata
> (configuration file, java-beans etc). So this thing could be seen as a
> framework or library, from which you can build specialized editors for
> different tasks.

I love the concept and am all for it from a backend point of view.
However, I worry that it puts the user interface at risk, because it is
infinitely harder to make a general interface optimal than it is to make
a specific one.  This view is backed up by the abundance of terrible
interfaces on supposedly professional software that tries to be general
purpose.  

For example, Cakewalk was a fairly decent sequencer when all it
did was MIDI.  When they tried to mix in audio editing features, their
MIDI support languished (they have not addressed any of the deficiencies
or problems with their MIDI interface in numerous versions) while their
audio support has never progressed beyond mediocre.  Someone who valued
the quality of the software would use a better dedicated MIDI sequencer
and a better, separate, dedicated audio sequencer/mixer (like Pro Tools).

I'm all for sharing the backend; Java makes code reuse trivial, and even
in C, writing shared libraries is not a difficult task at all.  I think
that the user interface, like with the Unix shell tools, should be small
and optimized to each task so that it can do it well.  

<FLAME BAIT>Yes, I use vi, not emacs.</FLAME BAIT>

The reason I'm writing this bugger is because I'm fed up with suboptimal
interfaces specifically for MIDI editing, not because I want to create a
half-hearted attempt to handle everything.  I really am shooting for the
truly perfect UI, to the best of my ability.

In any event, I'm done with the initial implementation of the core
backend, ie: the event list structure.  Java's object orientation made it
natural to write the backend in the generalized manner you suggested, even
if I wasn't shooting for a generalized frontend.  Check out the class
derivation:

Object
   |
   +--Doubly Linked List (of List Elements)
   |      |
   |      +--Sequence (of Events)
   |
   +--List Element
          |
          +--Event
                |
                +--Event in a Track
                      |
                      +--MIDI Channel Event
                      |     |
                      |     +--Note On
                      |     |
                      |     +--Note Off
                      |     |
                      |     +--Note (Pseudo Event)
                      |     |
                      |     +--Controller
                      |     |     |
                      |     |     +--Raw Controller
                      |     |     |
                      |     |     +--Compound Controller (RPN, etc)
                      |     |
                      |     +--(etc)
                      |
                      +--Raw MIDI Sysex
                      |
                      +--SMF Lyric
                      |
                      +--CSound Note
                      |     |
                      |     +--Note with Pitch
                      |           |
                      |           +--Note for "foo" inst of "bar.orc"
                      |
                      +--Audio Clip
                      |
                      +--(etc)

True, I did not write an XML "SongPad event type description file" DTD and
parser, but you can easily add to the heirarchy in Java.  (Oh yeah, THAT'S 
what all this open source fuss is about.)

> Editing a csound .sco file and a MIDI files is very similar.

I take issue with this.  In CSound you specify all parameters for a note a
the time that it is fired.  In MIDI, you add or modify parameters over
time after the note has been fired.  (This is done in a poorly scoped
manner... try changing the modulation amount for only one note out of a
chord played on a single channel.)  This makes a big difference, at least
to me, in how they should be presented in a visual interface.

> Another appliaction would be a mixer for audio files (e.g. mixdown
> singular drum instruments to a complete drum loop). Here you place the
> 'audio events' on time/instrument axis.

Well put, although unintentionally.  The same backend could be used in
another SEPARATE application that would do that.  This is Unix; let's do a
little multitasking.  If you need to use the drum machine together with
the MIDI sequencer, they can be synchronized via MTC/SMPTE or any of a
number of other ways.

> Another useful event type in both worlds (midi + csound) would be a
> phrase event, an event that contains other events. This may be used
> - to structure a song
> - to use predefined patterns or song fragments out of a library
> - invent new event types like a chord event (you place Em7 somewhere
> instead of its single notes)
>
> There could be more esoteric event types, e.g. algorithm events that may
> generate new events or modify existing events.

I thought about this a lot, actually.  What it boiled down to, for me, was
that this was best handled in a separate app or scripting language,
because if you integrated it, you ended up with things like MOD trackers
which were over-optimized for a single style of music.  

Basically, to do this right, you'd want a complete set of scripting
functionality: conditionals, loops, functions with parameters, etc.  These
don't fit well into the linear event list model that's at the core of the
sequencer.  

Common Music (non-interactive) and JMix (interactive) are exactly the type
of separate apps I'm talking about which would cooperate beautifully with
the sequencer to fill this niche.  I could reinvent the wheel here (which
I'm not, as a rule, adverse to doing), but I don't have the interest nor
expertise in algorithmic composition to do it properly.

> Think of a piano roll editor, a window where you can edit small rectangles
> (note events). x-axis is midi clock, y-axis is pitch. You could use this
> editor to edit any two dimensional data, e.g. you could use this editor to
> arrange a song by replacing the y-axis with the track-no and edit phrase
> events instead of note events. Or you can place MIDI keysignature events
> by replacing y with the possible 12 tunes. Or edit the value of a
> controller over time, or note-velocity over note-pitch (e.g. to make high
> notes louder), or ...

I think you only got one of my older emails to the list.  My piano roll
does have two types of graphs... one is a very highly optimized note
editor which handles only Note-on, Note-off, and Note-with-duration
events.  This has to be handled carefully, because notes are the most
fundamental and critical part of the music (after time/rhythm itself).

The other is a general purpose graph for other controllers, where
the x-axis is always time, but the y-axis and color-axis are each
assignable to different editable parameters.  I'm not yet sure if there
will need to be special cases here for certain types of controllers; I
personally tend to input and edit controllers from a list view not a piano
roll view.  

At any rate, this arbitrary controller graph covers many of the cases you
have in mind.  What it does not cover is those not tied to time.  I have
not decided what to do about those yet, or if they're really in the domain
of what a sequencer should provide.  After all, a sequencer is something
that handles sequences... lists of events that are tied to times.

> There should be a general property editor, that allows to access all
> properties of a selection. The metadata should provide a specialized GUI
> component for each parameter type, e.g. the value of a midi program change
> could be picked out of a list of instrument names, the value of the midi
> clock could be typed in as 'bar:step:tick' and so on. This property editor
> is independend of any specific event type an can be used for standard MIDI
> evnets (like note), esoteric events (like chord or algorithm), csound
> events (that may have many parameters) etc.

This sort of thing is pretty common in existing piano rolls by
right-clicking on a note or event to get a pop-up editor for that event.
My plan was to make it even easier to do this multiple times in succession
by having it presented in a stay-up window rather than a pop-up.  But I
agree, this is important to have whether or not your editor is
generalized.

> The framework should provide services like 
> - general GUI like undo/redo, selections, cut/copy/paste, etc 
> - interfaces for different backends (like midi, csound) 

Agreed.

> - metadata handling 
> - GUI components like axis beans for different editors (pitch axis, midi
>   clock axis, table axis for track/phrase arrangement window) 
> - complete editors like rectangle-editor (piano roll, arrangement window),
>   property sheet, event list, curve painter 

Not agreed.  Although the term "axis beans" is intriguing, I think that
it would be nearly impossible to make a bean specification that would
handle all cases optimally.  Rather than try and fail, I'd rather do them
separately and get each one right.

> - simple algorithms (linear interpolation from start value to end value) 

Algorithms tend to come under the category of plugins.  This is another
issue I've thought a lot about.  Keeping plugin-writing simple and
powerful is the main reason I'm so adamant about keeping the fundamental
data structure a single event list for the whole song (not even separate
lists for separate tracks).  The algorithms are far simpler when you're
dealing with linear streams.  I've lost a lot of hair because of CAL.

> I have been thinking of writing such a thing in java, but progress is very
> slow. All I have so far is a few UML diagrams and some experimental GUI
> stuff ...

I know all about the slow progress stuff.  This whole thing started for me
about four years ago when I thought I wanted a better notation program not
a better sequencer.  I've been drawing mockups, writing specs, and
throwing away semifunctional coding attempts for it all this time.  
That's part of the reason I sound so stubborn on some of the issues here
-- it's not really all about ego.  :-)  I've just distilled my list of
complaints with existing sequencers down to a plan which I think is
feasible to implement properly, rather than ending up with more
complaints.


[  Going back and editing this message before pressing "send", I realize
that I wanted a quick conclusion here, but actually started a whole new 
message.  Foo.  :-)  ]


Anyway I think that once I get this done, we'll be well on our way to
having a really kick-ass music production system from the LAD community.  
My personal needs for such would be:

1. A good MIDI sequencer.  This is the most important for me, and as the
expression goes, if you want something done right, you have to do it
yourself.  (Especially when nobody seems to agree with your definition of
"done right"!)  That doesn't mean that I expect everyone to agree, but
Jazz and KuBase aren't about to disappear either.

2. A decent notation program.  Although this is pretty important for me,
I'm afraid that it will be the one piece that remains missing from the LAD
music production system for the longest.  For a while I had hoped that
Guido would fill the niche, but they've slowrolled their promised release
of the source code for too long to rely on them.  

And no, please don't mention Lilypond.  Even if you have the patience to
learn the language (which I might if sufficiently motivated), that fool
thing is right near impossible to successfully install.  This goes deeper
than just lacking automake; it has too many dependencies, and referring to
its internal architecture as spaghetti code is a serious understatement.

3.  A solid, non-sequencing audio sample editor/recorder.  It looks like
Snd is starting to become mature enough to fill this niche.  I rank audio
effects as much less important than the core editing functions here.

4.  A good non-realtime audio sequencer/mixer/compositor.  The recent
progress on Mix sounds very promising here, although the nine track limit
sounds very artificial to me.  Then again, I'm personally biased towards
Rt (also ported to Linux from SGI, with similar Motif troubles) which was
written by my prof.

To respond to another thread, I'd not be adverse to writing a perl script
that would turn CSound into a compositor of this sort, reading a Mix, Rt,
or custom format script file.  However, I'm a little busy with the
sequencer right now, and there are other people here who are much better
at CSound than me (most of you, in fact!).  This might also fill the niche
sufficiently, especially if you then added an optional GUI (not
prohibitively hard in Tk, for instance).

5.  A powerful synthesis engine.  Here, the LAD community rules... we have
CSound, a mature program which can do nearly everything you'd want a
synthesis engine to do, but we also have quite a few other powerful apps
in this category, some mature and some under active development!

6.  Lastly, a good realtime algorithm engine.  This is not as essential as
the others for me, but it is still a very useful thing to have.  Although
I haven't learned how to work it yet, JMax sounds like it fills this niche
rather nicely.

Once we have robust apps to fill these 6 niches (and assuming that they
all play well together with IPC and drivers and such), Linux will truly be
a formidable music production system!

Div.

From - Sat Aug 21 01:02:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA18877
	for <slinkp@ulster.net>; Sat, 21 Aug 1999 00:34:43 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA23428 for linux-audio-dev-list; Sat, 21 Aug 1999 00:01:17 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA23425 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 21 Aug 1999 00:01:14 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id XAA17810
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 20 Aug 1999 23:58:14 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id XAA00897; Fri, 20 Aug 1999 23:58:14 -0400 (EDT)
Date: Fri, 20 Aug 1999 23:58:07 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] re: less and seeking on piped input
In-Reply-To: <37BCDD2E.E1562C0D@ulster.net>
Message-ID: <Pine.GSO.4.10.9908202353450.745-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e70d96c57a5144906ad7d24714941882

On Fri, 20 Aug 1999, Paul Winkler wrote:

> David Slomin wrote:
> 
> > I had a lot of fun playing with piping MIDI messages between little filter
> > apps in realtime (transpose, add parallel chords, etc).  MIDI itself is
> > low enough bandwidth that I didn't have any latency problems whatsoever,
> > although I didn't rig up anything to time down to the microsecond.  I can
> > send my code if you'd like, although it's nothing fancy.
> 
> Please post it somewhere, or send me a copy. I'd love to play with this! 

It's now available for download from
"http://patriot.altavista-software.com/~div/xfr".

Please don't mob the machine... it's my poor old 486.  (I subscribe to 
the school of thought that says: when your machine gets too old to be a
desktop, turn it into a headless mail and personal web server.)

And yes, the domain is for real... I write search engines during the day.
Div.

From - Sat Aug 21 02:02:08 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id CAA24759
	for <slinkp@ulster.net>; Sat, 21 Aug 1999 02:08:04 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id BAA23556 for linux-audio-dev-list; Sat, 21 Aug 1999 01:32:53 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA23553 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 21 Aug 1999 01:32:51 -0400
Received: from ulster.net (port133.king.ulster.net [208.242.160.134])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id BAA23646;
	Sat, 21 Aug 1999 01:44:04 -0400
Message-ID: <37BE3AF4.C8FF2DA8@ulster.net>
Date: Sat, 21 Aug 1999 01:36:52 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: David Slomin <dgslomin@CS.Princeton.EDU>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Timed Event Editor Framework
References: <Pine.GSO.4.10.9908202117200.25004-100000@ux02.CS.Princeton.EDU>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1762e32c109ba2a31e847da2337cedbc

David Slomin wrote:

> Algorithms tend to come under the category of plugins.  This is another
> issue I've thought a lot about.  Keeping plugin-writing simple and
> powerful is the main reason I'm so adamant about keeping the fundamental
> data structure a single event list for the whole song (not even separate
> lists for separate tracks).  The algorithms are far simpler when you're
> dealing with linear streams.  I've lost a lot of hair because of CAL.

What's CAL?

And while I'm asking:  Why does separate lists for separate tracks make
things harder? How might one implement tracks with a single list? (I ask
because I might someday resurrect my "pscore" project, which was a perl
module for playing with csound scores; I found keeping tracks in
separate lists was an obvious way to make sense of what I was doing, but
then I didn't spend much time thinking about alternatives.)

> Anyway I think that once I get this done, we'll be well on our way to
> having a really kick-ass music production system from the LAD community.

Any idea when your code might be made public?
I'm pretty frustrated with most sequencers I've tried...

> 3.  A solid, non-sequencing audio sample editor/recorder.  It looks like
> Snd is starting to become mature enough to fill this niche.  I rank audio
> effects as much less important than the core editing functions here.

That's fine-- Snd now supports plugins, so maybe we'll start to see
people come up with snd plugins. And I noticed from the documentation
that it is even theoretically possible to use csound as a plugin for snd
(by writing temp files... slow but it should work).
 
> 4.  A good non-realtime audio sequencer/mixer/compositor.  The recent
> progress on Mix sounds very promising here, although the nine track limit
> sounds very artificial to me.

Yep, I'd be in favor of removing that ASAP.

>  Then again, I'm personally biased towards
> Rt (also ported to Linux from SGI, with similar Motif troubles) which was
> written by my prof.

Cool! Rt remains the only non-MIDI computer-music system with which I've
ever actually _finished_ a composition. (It's on my webpage, in fact.
Too bad I have long since lost the rt script, and all the source
soundfiles. :( )
 
> To respond to another thread, I'd not be adverse to writing a perl script
> that would turn CSound into a compositor of this sort, reading a Mix, Rt,
> or custom format script file.  However, I'm a little busy with the
> sequencer right now, and there are other people here who are much better
> at CSound than me (most of you, in fact!).

I would like to do this script, but I don't know when I would get around
to it. Also I'd probably do it in Python, not perl, just because I kind
of like python.


----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Sun Aug 22 01:38:36 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA00499
	for <slinkp@ulster.net>; Sat, 21 Aug 1999 18:20:26 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA02588 for linux-audio-dev-list; Sat, 21 Aug 1999 17:40:09 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id RAA02585 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 21 Aug 1999 17:40:06 -0400
From: est@hyperreal.org
Received: (qmail 25251 invoked by uid 162); 21 Aug 1999 21:37:38 -0000
Message-ID: <19990821213738.25250.qmail@hyperreal.org>
Subject: [linux-audio-dev] sequencing..Symbolic Control Protocol
In-Reply-To: <199908111845.OAA03725@ginette.musique.umontreal.ca> from Eli Brandt
 at "Aug 11, 1999 02:42:51 pm"
To: eli+@cs.cmu.edu
Date: Sat, 21 Aug 1999 14:37:38 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Eric-Conspiracy: Conspiratio Schematis
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 4e17f96102df731d50ba2b88314e1ec5

Eli Brandt discourseth:
> 
> The way I think, I'd prefer a music sequencer that handles abstract
> time-structured data and maps it to MIDI.

I'm totally into this approach.  I think a canonical textual
representation is useful as well.

For example, oolaboola (www.hyperreal.org/~est/oolaboola) has complete
separation of the dsp and the gui.  They communicate over a pair of
pipes using something I call (though it's only in a nascent state)
Symbolic Control Protocol (scp) which uses Scheme symbolic expressions
for its lexical structure.  Both the protocol and oola's use of it
need considerable fleshing out.  All communications from the gui to
the dsp are logged to a time-stamped (in its name) sequence file.  The
file has entries like:

 (delta 31.010903 (file0 "/music/all-in-your-hands.wav"))

..meaning 31.010903 seconds after the previous event, load
"/music/all-in-your-hands.wav" onto player 0.

The oola distribution includes a tiny sequencer program (`seq', which
is installed into the oola library directory) which can be used to run
the dsp using one of these log files.

The long-term idea is that scp-speaking resources would have a grammar.
For example a midi device might have a grammar that includes

(type channel (range 1 16))
(type key (range 0 127))
(type velocity (range 0 127))

(event (| (note-on channel key velocity))
        ...)

It might be worthwhile to restrict such grammars to be regular (in the
linguistic complexity sense).

Given a grammar and a sequence file, a sequence editor could be pretty
friendly.  Useful composite operations could be created for various
grammars with standard ones in a library.

Other interesting scp uses include:

* Mapping of raw MIDI to more abstract MIDI grammars might be useful.
  When it comes to computer-based sound processing, however, I find it
  pleasant to completely forget about MIDI. :)

* scp can be used for hand-shaking between resources which then set up
  streaming data connections via tcp or (if on the same machine)
  shared-memory.

* scp-speaking resources could be accessed via URLs (e.g.,
  scp://localhost/my-soundcard), and programs could determine where to
  send output (control and/or data) via an scp URL specified in an
  environment variable (like the X DISPLAY variable).  I'll be doing
  something like this when oola is extended to handle multiple cheap
  soundcards.

One obvious question about the scp approach is `why not XML'?  The
decision doesn't seem clear-cut either way to me.  Some salient points
are:

* XML was never intended for streaming messages.

* Scheme has well-defined lexics for numerical quantities.  The type
  schemata extensions to XML are in a draft stage and are, IMHO,
  fairly poor.

* Scheme symbolic expressions are cheap and easy to parse and have had
  their structure debugged over 40 years.

* I'm a lisp chavinist. :)

* In any case, translation between xml and scp doesn't seem too difficult.

Thoughts?

Eric

From - Sun Aug 22 01:38:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA11657
	for <slinkp@ulster.net>; Sat, 21 Aug 1999 20:30:22 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA02769 for linux-audio-dev-list; Sat, 21 Aug 1999 19:47:15 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA02766 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 21 Aug 1999 19:47:13 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id TAA15661
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 21 Aug 1999 19:44:42 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id TAA11308; Sat, 21 Aug 1999 19:44:43 -0400 (EDT)
Date: Sat, 21 Aug 1999 19:44:37 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Timed Event Editor Framework
In-Reply-To: <37BE3AF4.C8FF2DA8@ulster.net>
Message-ID: <Pine.GSO.4.10.9908211907001.9991-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c59e3aa83ade36af1ae304f27dc20b45

On Sat, 21 Aug 1999, Paul Winkler wrote:

> What's CAL?

Cakewalk Application Language, the scripting language for the Cakewalk
sequencer.  It is very roughly Lisp-based, but lacks all of Lisp's
expressive strength.  Truly, it is difficult to do even the simplest of
tasks with it, and is impossible to do many advanced but useful things. To
make life worse, its documentation is both inaccurate and incomplete.

I've been using Cakewalk for years, and consider it the best of the
various sequencers I've tried, but it has many faults (not just its
commercial, Windows-only status) which drive me nuts.
 
> And while I'm asking:  Why does separate lists for separate tracks make
> things harder? How might one implement tracks with a single list? (I ask
> because I might someday resurrect my "pscore" project, which was a perl
> module for playing with csound scores; I found keeping tracks in
> separate lists was an obvious way to make sense of what I was doing, but
> then I didn't spend much time thinking about alternatives.)

The way to do it is very simple: for every event in the list, include a
field that says what track it's in.  Then as you iterate over the list,
you can either use that field or ignore it according to your needs at the
time.  

The reason to do it this way is less clearcut.  Actually, now that I stop
and think about it, neither approach is particularly better, since it is
easy enough to use a nested loop to address all tracks in the multiple
list version, or use a filter to address one track in the single list
version.

My initial decision was based on extreme frustration with CAL, which uses
separate lists for separate tracks but does not support nested loops
(aaaaaagh!).  I decided to keep it for a couple of reasons:

1.  The single list approach is easier to send over a stream, for instance
to an external script for algorithmic processing (Bourne script-based
plugins or such).

2.  For displaying the event list gui, the natural structure is to have
them merged.  For my initial design of the piano roll gui (all tracks
mixed together on a single graph, distinguished by color), the merged
structure is also more natural.  However, I've since decided to separate
tracks into different (vertically stacked) graphs in the piano roll, so
that is no longer a consideration, but the filtering (extracting a single
track from the list) is very computationally cheap.

3.  For playback, there's no mixdown required.  This is one area where the
computational complexity really does count.

> Any idea when your code might be made public?
> I'm pretty frustrated with most sequencers I've tried...

Now look what I've done... I was trying so hard to avoid vaporware, but I
got too excited about the project to keep my mouth shut.  :-)  I'll start
releasing the code as soon as I have something useful.

Probably the first part that I release won't be a functioning sequencer,
but just the core event list structures and SMF I/O routines with some
samples of them in use.  Soon after will be the first shot at the event
list view gui.  Next will be the first shot at the piano roll gui, which
will be the first release that looks vaguely like a sequencer.  More will
come later. I expect the first part to be ready within a week or two, but
don't quote me on it.

> Cool! Rt remains the only non-MIDI computer-music system with which I've
> ever actually _finished_ a composition. (It's on my webpage, in fact.
> Too bad I have long since lost the rt script, and all the source
> soundfiles. :( )

Rt was the central tool we used in CS/Music-325 class under Prof Lansky,
although we also worked with Ein and CMix, all on black-hardware NeXTs
(they were so very cool).  I rather liked Rt, but wished it didn't focus
on realtime or have the stupid gui so that it would be more portable.  
(Yes, you could make Rt run handmade score files, but it still loaded the
damn gui.)  I actually had started work on a replacement for Rt that
addressed these two issues, but I decided that the sequencer was more
worth my time.  The code's up for grabs if anybody would like it, but it
doesn't work yet.

Div.


From - Sun Aug 22 01:38:42 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA14730
	for <slinkp@ulster.net>; Sat, 21 Aug 1999 21:04:24 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA02819 for linux-audio-dev-list; Sat, 21 Aug 1999 20:17:16 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA02816 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 21 Aug 1999 20:17:13 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id UAA17101
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 21 Aug 1999 20:13:14 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id UAA12311; Sat, 21 Aug 1999 20:13:15 -0400 (EDT)
Date: Sat, 21 Aug 1999 20:13:12 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] sequencing..Symbolic Control Protocol
In-Reply-To: <19990821213738.25250.qmail@hyperreal.org>
Message-ID: <Pine.GSO.4.10.9908212006410.9991-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 8b590a3f1229fbd0f79b61214d2f8738

On Sat, 21 Aug 1999 est@hyperreal.org wrote:

> I'm totally into this approach.  I think a canonical textual
> representation is useful as well.

I tend to worry about tying a protocol to a single language, although it
can have its benefits.  However, when you're talking about streaming, a
language like scheme (which supports loops and functions, inherently
nonlinear concepts) would be even more inappropriate than XML.

Have you seen SKINI?  My favorite prof, Perry Cook came up with it as
a textual representation for MIDI (and then some).  It is used directly by
his Synthesis Toolkit (see either Princeton or CCRMA), but can easily be
translated to/from MIDI and other streaming event protocols.  I wouldn't
call it perfect by any means, but it wouldn't be a terrible place to
start.

Div.

From - Sun Aug 22 01:38:43 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA18741
	for <slinkp@ulster.net>; Sat, 21 Aug 1999 21:50:56 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA02882 for linux-audio-dev-list; Sat, 21 Aug 1999 21:02:09 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id VAA02879 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 21 Aug 1999 21:02:06 -0400
From: est@hyperreal.org
Received: (qmail 4321 invoked by uid 162); 22 Aug 1999 00:59:37 -0000
Message-ID: <19990822005937.4320.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] sequencing..Symbolic Control Protocol
In-Reply-To: <Pine.GSO.4.10.9908212006410.9991-100000@ux02.CS.Princeton.EDU>
 from David Slomin at "Aug 21, 1999 08:13:12 pm"
To: David Slomin <dgslomin@CS.Princeton.EDU>
Date: Sat, 21 Aug 1999 17:59:37 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 13174ce7b008b56f05bf6ffb9e346fba

David Slomin discourseth:
> On Sat, 21 Aug 1999 est@hyperreal.org wrote:
> 
> > I'm totally into this approach.  I think a canonical textual
> > representation is useful as well.
> 
> I tend to worry about tying a protocol to a single language, although it
> can have its benefits.  However, when you're talking about streaming, a
> language like scheme (which supports loops and functions, inherently
> nonlinear concepts) would be even more inappropriate than XML.

I'm only using the lexical structure of scheme symbolic expressions,
so it's not tied to any language in the sense of transmitting
executable code.  Oolaboola uses it to communicate between programs
written in C++ and Python..no Scheme in the mix!

> Have you seen SKINI?  My favorite prof, Perry Cook came up with it as
> a textual representation for MIDI (and then some).  It is used directly by
> his Synthesis Toolkit (see either Princeton or CCRMA), but can easily be
> translated to/from MIDI and other streaming event protocols.  I wouldn't
> call it perfect by any means, but it wouldn't be a terrible place to
> start.

I'd love to see it.  The scp thing is almost a meta-protocol..not
really incompatible with anything..and ready to digest many
paradigms. :)  I haven't looked much at Synthesis Toolkit because, last
I looked, it had a restrictive license.

Eric

From - Sun Aug 22 14:14:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA12502
	for <slinkp@ulster.net>; Sun, 22 Aug 1999 12:14:41 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA03666 for linux-audio-dev-list; Sun, 22 Aug 1999 11:34:21 -0400
Received: from fep02-svc.tin.it (mta02-acc.tin.it [212.216.176.33]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA03663 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 22 Aug 1999 11:34:17 -0400
Received: from tin.it ([212.216.171.233]) by fep02-svc.tin.it
          (InterMail v4.01.01.02 201-229-111-106) with ESMTP
          id <19990822153142.HGYX16170.fep02-svc@tin.it>
          for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Sun, 22 Aug 1999 17:31:42 +0200
Message-ID: <37C01622.50BE17AF@tin.it>
Date: Sun, 22 Aug 1999 17:24:18 +0200
From: Maurizio Umberto Puxeddu <umbpux@tin.it>
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] The future of libsndfile
References: <37BBF65B.7B1C8959@zip.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: fb00b613e370f78189af8cff6f4db14b

Erik de Castro Lopo wrote:
> 
> Hi all,
> 
> I've been a little overwhelmed with the recent discussion about what
> features people would like. Rather than trying to answer each email
> separately I will try to respond to all the issues in one go. If
> I have missed anything please point it out.
> 
> Maurizio Umberto Puxeddu had the following suggestion:
> > > > 2) Some applications (see Csound) may need to update the file header
> > > > each time you perform a write operation (so that B can read while A is
> > > > writing).
> <snip>
> > Csound can rewrite continuously
> > the header while writing a sound file (-R switch), so that you can use
> > an audioplayer to move through the file during the synthesis. (You
> > probably sets the file length to the maximum value before the close
> > operation, but this is a bit dangerous.)
> 
> Yes I think this is a good idea. I have been thinking about cleaning up
> the
> header writing code and when I do this I will add an interface something
> like sf_update_header () which will rewrite the header with the number
> of samples written at the time it is called.
An alternative could be setting an "Auto header updating" property at
open time and
conditionally rewriting the header each write call. Don't know what it's
better.
 
> Another of Maurizio's suggestions was:
> > I was not (not only) asking Erik to insert one or two features. I meant:
> > you have the code for doing this operation while reading/writing a file
> > but an application may have to do the same with audio data resident in
> > memory. Why
> > don't include in your API functions like
> >
> > swap_word_endianess(word_t *, size_t);
> >
> > convert_double_to_ulaw8(double *, size_t, byte_t *);
> 
> These functions in libsndfile are slightly different but I will expose
> whatever may be useful. The exposed functions will all be named sf_* ().
> In order to minimise the size of the libsndfile headers, I will use two
> header files sndfile.h which will be similar to the current one and
> sndfileex.h which contains the extra utility functions and includes
> the first header.
This is the best solution. I'll also adopt a similar habit.
 
[...snip...]
> I have also been having some thoughts along the lines of non-destructive
> editing with edit lists etc. My conclucion was that none of the formats
> libsndfile currently supports is all that well suited to this problem.
I think that basically (but still in a general way) non-destructive
editing can be done using just a playing list of audio fragments, that
supports
fragment insertion/deletion and splitting a fragment in two, seeking and
reading samples.

I think I'll post a C++ API proposal in a week or two.

Erik, do you think you (or I) could do little changes to libsndfile
_internals_ to allow a better code sharing between C and C++ interfaces?
I'm speaking about moving some code in a separate file, splitting a
function call in two or so.

Thank you,
Maurizio Umberto Puxeddu

From - Tue Aug 24 02:24:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA19012
	for <slinkp@ulster.net>; Sun, 22 Aug 1999 19:26:58 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA04047 for linux-audio-dev-list; Sun, 22 Aug 1999 18:15:37 -0400
Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA04044 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 22 Aug 1999 18:15:31 -0400
Received: from hendrix (krusty48.zip.com.au [61.8.16.80])
	by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id IAA15107;
	Mon, 23 Aug 1999 08:01:51 +1000 (EST)
Message-ID: <37C075D8.2A26C5E4@zip.com.au>
Date: Mon, 23 Aug 1999 08:12:40 +1000
From: Erik de Castro Lopo <erikd@zip.com.au>
Organization: Eric Conspiracy Secret Labs
X-Mailer: Mozilla 3.04Gold (X11; I; Linux 2.2.11 i586)
MIME-Version: 1.0
To: Maurizio Umberto Puxeddu <umbpux@tin.it>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] The future of libsndfile
References: <37BBF65B.7B1C8959@zip.com.au> <37C01622.50BE17AF@tin.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 280f3563741a5546a1b87bd47dfa92d2

Maurizio Umberto Puxeddu wrote:
> 
> Erik de Castro Lopo wrote:
> > Yes I think this is a good idea. I have been thinking about cleaning up the
> > header writing code and when I do this I will add an interface something
> > like sf_update_header () which will rewrite the header with the number
> > of samples written at the time it is called.
>
> An alternative could be setting an "Auto header updating" property at
> open time and conditionally rewriting the header each write call. Don't know 
> what it's  better.

I'll definitely consider it, but I will add an explicit sf_update_header ()
for people who don't want the auto feature.

> I think that basically (but still in a general way) non-destructive
> editing can be done using just a playing list of audio fragments, that
> supports fragment insertion/deletion and splitting a fragment in two, 
> seeking and reading samples.
> 
> I think I'll post a C++ API proposal in a week or two.

This is still a bit premature for libsndfile but I'd be very 
interested in your thoughts.

> Erik, do you think you (or I) could do little changes to libsndfile
> _internals_ to allow a better code sharing between C and C++ interfaces?
> I'm speaking about moving some code in a separate file, splitting a
> function call in two or so.

I'll certainly consider it. What were you proposing? Be aware that I
am already hacking away at the internals so that while I am still
able to cope with the load, it may be better if I do the changes on
my current development tree.

Erik
-- 
+-------------------------------------------------+
     Erik de Castro Lopo     erikd@zip.com.au
+-------------------------------------------------+
BSD:  A psychoactive drug, popular in the 80s, probably developed at UC
Berkeley or thereabouts.  Similar in many ways to the prescription-only
medication called "System V", but infinitely more useful. (Or, at least,
more fun.)  The full chemical name is "Berkeley Standard Distribution".

From - Tue Aug 24 02:24:02 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA25096
	for <slinkp@ulster.net>; Sun, 22 Aug 1999 20:27:21 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA04149 for linux-audio-dev-list; Sun, 22 Aug 1999 19:41:48 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA04146 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 22 Aug 1999 19:41:45 -0400
Received: from bright.net (find-cas1-cs-16.dial.bright.net [209.143.26.119])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id TAA14759;
	Sun, 22 Aug 1999 19:39:07 -0400 (EDT)
Message-ID: <37C09056.52AF3416@bright.net>
Date: Sun, 22 Aug 1999 20:05:42 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Nicola Bernardini <nicb@axnet.it>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
CC: Csound Linux/Unix Development Group <csound-unix-dev@ilogic.com.au>
Subject: [linux-audio-dev] Re: [CUD] 3.57.0.1d is in the CVS repository (.csd's, finally!)
References: <Pine.LNX.4.10.9908221108110.260-100000@ax-nicb.axnet.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 80521e6deb5c6fb45833eb085377e00c

Greetings:

  It is now available at ftp://mustec.bgsu.edu/pub/linux as a
source-only distribution.

  Thanks, Nicola, for your work on this one. I'll test the csd stuff
tomorrow, will report on it then.

  Swamped and rushed here...

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Tue Aug 24 02:24:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA01573
	for <slinkp@ulster.net>; Sun, 22 Aug 1999 21:48:37 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA04270 for linux-audio-dev-list; Sun, 22 Aug 1999 21:07:56 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id VAA04267 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 22 Aug 1999 21:07:50 -0400
From: est@hyperreal.org
Received: (qmail 6223 invoked by uid 162); 23 Aug 1999 01:05:16 -0000
Message-ID: <19990823010516.6222.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] Re: [CUD] 3.57.0.1d is in the CVS repository (.csd's,
 finally!)
In-Reply-To: <37C09056.52AF3416@bright.net> from Dave Phillips at "Aug 22, 1999
 08:05:42 pm"
To: Dave Phillips <dlphilp@bright.net>
Date: Sun, 22 Aug 1999 18:05:16 -0700 (PDT)
CC: Nicola Bernardini <nicb@axnet.it>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>,
        Csound Linux/Unix Development Group <csound-unix-dev@ilogic.com.au>
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0fba9b0ec65e72be7b2e99b3fd153935

Hmm, `make depend' gives me:

rm -f .depend
make - .depend
make[1]: Entering directory `/usr/local/src/unofficial-csound-3.57.0.1d-linux.s\rc'
Building dependencies (this may take some time)...
gcc: rtlinux.c: No such file or directory
make[1]: *** [.depend] Error 1
make[1]: Leaving directory `/usr/local/src/unofficial-csound-3.57.0.1d-linux.sr\c'
make: *** [depend] Error 2

..unless I do ./configure --enable-OSS-RTAUDIO=yes

Also, a distclean target would be nice.

Otherwise it seems to work.

Can anyone tell me where to get prior versions of unix/linux csound..
preferably going back to 3.47?

Thanks,

Eric

From - Tue Aug 24 02:24:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA15733
	for <slinkp@ulster.net>; Mon, 23 Aug 1999 09:20:34 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA05183 for linux-audio-dev-list; Mon, 23 Aug 1999 08:34:44 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA05180 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 23 Aug 1999 08:34:41 -0400
Received: from bright.net (find-cas1-cs-26.dial.bright.net [209.143.26.129])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id IAA18332;
	Mon, 23 Aug 1999 08:31:50 -0400 (EDT)
Message-ID: <37C1456E.9D13FC82@bright.net>
Date: Mon, 23 Aug 1999 08:58:22 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: est@hyperreal.org
CC: Nicola Bernardini <nicb@axnet.it>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>,
        Csound Linux/Unix Development Group <csound-unix-dev@ilogic.com.au>,
        pete moss <bantha@bigfoot.com>,
        "srenner@lycosmail.com" <srenner@lycosmail.com>
Subject: Re: [linux-audio-dev] Re: [CUD] 3.57.0.1d is in the CVS repository 
 (.csd's,finally!)
References: <19990823010516.6222.qmail@hyperreal.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b3339d48961efba42014c2be2ff6492c

est@hyperreal.org wrote:

> Hmm, `make depend' gives me:
> 
> rm -f .depend
> make - .depend
> make[1]: Entering directory `/usr/local/src/unofficial-csound-3.57.0.1d-linux.s\rc'
> Building dependencies (this may take some time)...
> gcc: rtlinux.c: No such file or directory
> make[1]: *** [.depend] Error 1
> make[1]: Leaving directory `/usr/local/src/unofficial-csound-3.57.0.1d-linux.sr\c'
> make: *** [depend] Error 2
> 
> ..unless I do ./configure --enable-OSS-RTAUDIO=yes

Nicola, is 'make src-distrib' packaging everything ? I acquired the
sources directly from the CVS and everything builds fine, with or
without --enable-OSS-RTAUDIO.

> Also, a distclean target would be nice.

Agreed.
 
> Can anyone tell me where to get prior versions of unix/linux csound..
> preferably going back to 3.47?

There are some early versions on ftp://mustec.bgsu.edu/pub/linux but I'm
not sure they go back that far.

********
To all:
********

Please use the latest version (3.57.0.1d) instead of the earlier
versions up on MusTec. rtlinux.c is available from that site too and I
will replace it with the latest version if we're really missing it from
the tree packaging.

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Tue Aug 24 14:08:57 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA07386
	for <slinkp@ulster.net>; Tue, 24 Aug 1999 12:20:57 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA07295 for linux-audio-dev-list; Tue, 24 Aug 1999 11:30:05 -0400
Received: from icemserv.folkwang.uni-essen.de (icemserv.folkwang.uni-essen.de [132.252.170.129]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA07291 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 24 Aug 1999 11:29:54 -0400
Received: from folkwang.uni-essen.de (nettings@dialup1.folkwang.uni-essen.de [132.252.170.1]) by icemserv.folkwang.uni-essen.de (8.8.8/8.7.3) with ESMTP id PAA06387 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 24 Aug 1999 15:25:28 +0200 (CEST)
Message-ID: <37C2A18B.3AB948DA@folkwang.uni-essen.de>
Date: Tue, 24 Aug 1999 13:43:39 +0000
From: =?iso-8859-1?Q?J=F6rn?= Nettingsmeier <nettings@folkwang.uni-essen.de>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] non-real-time EQ/FX ?
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 490719ec87021c318e0ed714b124c5b1

hello everybody !

first of all, thanks to all linux sound programmers for their code
donations !
i've been lurking on this list for quite a while now, and  i'm quite
impressed about what's going on.

now, some comments from a non-hacker:

when i compare my analog setup to my computer, there are two things
i miss in linux.
#1 high quality stand-alone parametric equalizing
#2 high quality stand-alone reverberation

what im thinking of is true million-dollar-sound :), mostly for 2
track mastering. 
now i understand there is always the problem of quality vs computing
capacity.
  so how about having a fast little real-time eq/fx program with
limited quality for knob-twiddling on-the-fly which hands the
parameters over to an off-line algorithm that finally applies the
effect to the sound file in non-real-time ?

this would allow several effects at once, like in a multitrack
setup, without degrading sound. and it would ease hardware
requirements.
  maybe the final pass can be implemented as a command-line filter
that audio files can 
be piped into, like: 

$cat something.wav | eq | reverb > somethingbetter.wav

does this make sense ?  have i overlooked anything that already
exists ?


regards,

jrn

-- 
Jo"rn Nettingsmeier
Effmannstr. 6, 45239 Essen/Germany 
Phone/Fax +49 201 491621


From - Tue Aug 24 14:09:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA24368
	for <slinkp@ulster.net>; Tue, 24 Aug 1999 14:11:53 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA07292 for linux-audio-dev-list; Tue, 24 Aug 1999 11:29:56 -0400
Received: from icemserv.folkwang.uni-essen.de (icemserv.folkwang.uni-essen.de [132.252.170.129]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA07287 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 24 Aug 1999 11:29:01 -0400
Received: from folkwang.uni-essen.de (nettings@dialup1.folkwang.uni-essen.de [132.252.170.1]) by icemserv.folkwang.uni-essen.de (8.8.8/8.7.3) with ESMTP id PAA06389 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 24 Aug 1999 15:25:32 +0200 (CEST)
Message-ID: <37C2A3B3.D007035A@folkwang.uni-essen.de>
Date: Tue, 24 Aug 1999 13:52:51 +0000
From: =?iso-8859-1?Q?J=F6rn?= Nettingsmeier <nettings@folkwang.uni-essen.de>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] convolution reverb ?
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 14d51df64cb8cf68696c809b7bbf38ff

hello everybody !

at a workshop (see below) i learned about a concept called
convolution.
basically, this is about multiplying a signal with an impulse
response file of
a room with nice reverb, resulting in the signal sounding *exactly*
as if played back in that particular room. 
drawbacks are lack of tweakability, non-real-time processing and the
difficulty to
obtain good impulse responses that are free from street noise and
the like.
the advantage is: it sounds incredibly natural.
  does anyone know about linux implementations of this concept ?
the algorithm doesnt appear too complicated, it seems its all
about cpu-time.

regards, 
jrn
 

for an excellent documentation on synthesis refer to
http://www.folkwang.uni-essen.de:80/~ludi/Public/kurs/offenKurs.html
convolution is mentioned in section 5.4 (sorry, mostly in german)

-- 
Jo"rn Nettingsmeier
Effmannstr. 6, 45239 Essen/Germany 
Phone/Fax +49 201 491621

From - Tue Aug 24 14:09:03 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA21228
	for <slinkp@ulster.net>; Tue, 24 Aug 1999 13:52:25 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA07418 for linux-audio-dev-list; Tue, 24 Aug 1999 13:02:17 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA07415 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 24 Aug 1999 13:02:11 -0400
Received: from bright.net (find-cas2-cs-2.dial.bright.net [209.143.26.156])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id MAA12436;
	Tue, 24 Aug 1999 12:59:18 -0400 (EDT)
Message-ID: <37C2D59D.4350F185@bright.net>
Date: Tue, 24 Aug 1999 13:25:49 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: =?iso-8859-1?Q?J=F6rn?= Nettingsmeier <nettings@folkwang.uni-essen.de>
CC: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] convolution reverb ?
References: <37C2A3B3.D007035A@folkwang.uni-essen.de>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by sparticus.bright.net id MAA12436
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id NAA21228
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 9c5329fce10c8671becf71560330c381

Jrn Nettingsmeier wrote:

> at a workshop (see below) i learned about a concept called
> convolution. [snip]
>
>   does anyone know about linux implementations of this concept ?
> the algorithm doesnt appear too complicated, it seems its all
> about cpu-time.

Csound does pretty decent convolution, and my Csound Resources page
lists some sources for impulse response files. You do have to be careful
about amplitudes, but yes, the results are worth the time waiting.
Convolution seems a bit beyond realtime at this point, at least for my
machine. Does anyone know of research or implementation of realtime
audio convolution ?

Finally, there's a good explanation of it (with source code) in F.R.
Moore's "Elements Of Computer Music".

The Linux Csound/Csound Resources page is located at:

	http://www.bright.net/~dlphilp/linux_csound.html

Lots of great stuff listed here, and it has been updated as of this
morning.

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Wed Aug 25 16:06:13 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA00644
	for <slinkp@ulster.net>; Tue, 24 Aug 1999 19:03:17 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA07948 for linux-audio-dev-list; Tue, 24 Aug 1999 18:18:33 -0400
Received: from gauss.deltav.hu (gauss.deltav.hu [194.9.64.225]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA07945 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 24 Aug 1999 18:18:29 -0400
Received: from cerealbox (70.dial02.deltav.hu [194.9.64.70])
          by gauss.deltav.hu (Netscape Messaging Server 3.6)  with ESMTP
          id AAA2A36 for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Wed, 25 Aug 1999 00:18:53 +0200
Received: from reactor by cerealbox with local (Exim 1.92 #1 (Debian))
	id 11JOwf-00007p-00; Wed, 25 Aug 1999 00:21:33 +0200
Message-ID: <19990825002133.A406@cerealbox>
Date: Wed, 25 Aug 1999 00:21:33 +0200
From: reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] plugin format
Reply-To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.91.2
Organization: CTP media laboratories
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: d585e59bb3890d012833294da373097d

yo!

i think it's high time we declared a standard for for plugins.
should we copy GIMP's plugin system? or use the system seen
in x11amp/xmms? is there any possibility to use/make VST plugins
on linux? waiting for VST2? any new, groundbreaking ideas?
with a nice standard plugin format, every linux audioware could
multiply its power...

byah!

-- 

  Mt Rcz  ->  reactor/CTPmedia
  my music   ->  http://linux.gyakg.u-szeged.hu/~reactor/

From - Wed Aug 25 16:06:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA25453
	for <slinkp@ulster.net>; Tue, 24 Aug 1999 22:05:06 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA08144 for linux-audio-dev-list; Tue, 24 Aug 1999 21:15:00 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA08141 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 24 Aug 1999 21:14:57 -0400
Received: from bright.net (find-cas3-cs-17.dial.bright.net [209.143.26.222])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id VAA21461;
	Tue, 24 Aug 1999 21:12:11 -0400 (EDT)
Message-ID: <37C34923.F0096D03@bright.net>
Date: Tue, 24 Aug 1999 21:38:43 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
CC: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] plugin format
References: <19990825002133.A406@cerealbox>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 64aad8f41166650b78d1e2b4b4e4f660

reactor/CTPmedia wrote:

> i think it's high time we declared a standard for for plugins.
> should we copy GIMP's plugin system? or use the system seen
> in x11amp/xmms? is there any possibility to use/make VST plugins
> on linux? waiting for VST2? any new, groundbreaking ideas?
> with a nice standard plugin format, every linux audioware could
> multiply its power...

I haven't yet investigated the Xmms model, but Guenter Geiger has
developed a straightforward model for his version of Mix.

Plug-in architectures abound, but you're right in claiming we should
have a standard. I think it will happen, it's an important-enough topic.

I checked out one of your MP3 files, good stuff there. What tools did
you use to make them ?

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Wed Aug 25 16:06:25 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA05074
	for <slinkp@ulster.net>; Tue, 24 Aug 1999 23:41:13 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA08250 for linux-audio-dev-list; Tue, 24 Aug 1999 22:56:15 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA08247 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 24 Aug 1999 22:56:04 -0400
Received: from swipnet.se (dialup84-11-8.swipnet.se [130.244.84.168]) 
          by mb04.swip.net (8.8.8/8.8.8) with ESMTP 
          id EAA04381; 
          Wed, 25 Aug 1999 04:53:16 +0200 (MET DST)
Message-ID: <37C35B30.EEA6DD85@swipnet.se>
Date: Wed, 25 Aug 1999 04:55:44 +0200
From: David Olofson <audiality@swipnet.se>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-RTL_BETA12 i686)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
CC: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] plugin format
References: <19990825002133.A406@cerealbox>
Content-Type: multipart/mixed;
 boundary="------------3B9A1E09619499BDFFF1E127"
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d84252400c5920a10c6ea59e6c55236e

This is a multi-part message in MIME format.
--------------3B9A1E09619499BDFFF1E127
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

reactor/CTPmedia wrote:
> 
> yo!
> 
> i think it's high time we declared a standard for for plugins.

*heh..* I just had the idea that I should open up my design work on the
Audiality Plug-in API... :-)

As I'm still working on a layer for porting Linux drivers to RTLinux
(latest results: .4 ms latency with an AudioPCI card, rock solid), I
haven't yet got around to hack a serious spec. But I have quite a few
ideas from the last ten years or so I've been playing with audio and
code, and I have a rather clear picture of the basic implementation
details in my mind.

> should we copy GIMP's plugin system?

How would that map to hosting tens of plug-ins in a low latency real
time system? Haven't seen the spec (should take a look at that one too,
I guess), but I'd be surprized if it differs much from most plug-in APIs
of that kind. Not very well suited for audio, I'd guess...

> or use the system seen
> in x11amp/xmms?

No detailed knowledge, but it sounds more like it.

> is there any possibility to use/make VST plugins
> on linux?

There IS a VST 2.0 SDK for SGI... However, I consider VST still too
limited, and now (2.0) it already carries old legacy stuff. And it's 32
bit FP audio streaming only; exactly what I want, but perhaps not what
you had in mind?

> waiting for VST2?

Already here... Anyway, I certainly don't like their way of allowing
various system calls and things like that from within the plug-in code.
Stricter GUI/processing separation is needed for a really clean API, and
it's absolutely crucial in a hard real time system, as ANY system call
would break the real time performance completely! And under RTLinux,
most of those calls don't even exist...

> any new, groundbreaking ideas?

Naah... Not groundbreaking perhaps, but the Audiality plug-in API will,
among other things...

1. Allow plug-ins to inform the engine about inherent/unwanted latency
2. Allow plug-ins to tell the engine about their inherent/desired
latency
3. Handle sample accuracy time stamped events
4. Support control signals in the form of low frequency audio streams

1 means that the engine can compensate for inherent latency in certain
algorithms, so that the user doesn't have to keep that in mind. (Say,
you split a signal into "low" and "high" using a dividing filter
network, process the two new signals with different plug-ins, and then
merge them together into a full signal. Meep! Phase error, unless the
engine keeps track of the latencies caused by all plug-ins.)

2 lets the engine keep track of 1 without simply adding to the total
system latency, and is also required for supporting feedback loops in a
controlled fashion.

3 means that you can send events at exact times (for example changing a
preset on a plug-in), rather than processing all "events" between the
processing buffers. Plug-ins can chose to support this in the process
loop for maximum performance under heavy event traffic, or just tell the
engine to split the buffers with the precision it sees fit, when there's
an event to handle.

4 is first of all a way of reusing audio processing plug-ins for control
signal processing (useful in modular synthesizers); second, a way to get
nicer and faster plug-in code that pumping in masses of events would
result in.

Well, that's about what comes to mind right now... More ideas and design
stuff in various kinds of documents all over the place here. :-)

> with a nice standard plugin format, every linux audioware could
> multiply its power...

Yep. And I'm looking further. Audiality is not meant to be an API for
plug-ins and host applications - Audiality doesn't *have* host
applications in the normal case. Audiality will be a complete, general
purpose (not only audio), real time signal processing engine with
support for plug-ins and client applications. The engine is meant to be
a shared system resource, so hardware resources, plug-ins and streaming
databases can be used by multiple applications at once, if desired. That
is, if you run a soft synth, a multitracker and a MIDI sequencer,
they'll all be able to share the hardware, and they're automatically
synchronized with sub-sample precision.

The main Audiality engine implementation will run under RTLinux for
extreme performance and reliability, and will use drivers recompiled
into RTLinux drivers using the Driver Programming Interface I'm
currently hacking. This means that complete, existing Linux drivers can
be ported very easily, without even needing to adapt them to a new API -
I've implemented the most frequently used kernel calls as RTLinux safe,
context sensitive versions. (Bonus effect of the current version: The
drivers still work as standard Linux drivers, _at the same time_ as
being used by RTLinux threads.)

For safer development, and for users that can live with some 5 ms of
latency (new kernel patches by Ingo Molnar, in case you haven't heard...
:-), there will also be a user space SCHED_FIFO version of the engine,
that doesn't need RTLinux.

Both engine implementations will load and run the same plug-in binaries,
and in theory (if someone feels like porting an ELF loader), they could
be binary portable across all platforms using the CPU the code was
compiled for. (However, I don't care much for Windoze and MacOS anymore,
and nothing, not even BeOS, gets close the the RTLinux performance,
so...)


Some very, very preliminary API specs I started hacking the other day is
attached if you want to have a look... Doesn't explain much perhaps, but
at least gives a hint about the most important thing; the minimal impact
of flexibility on performance. That is, there will be no ultra flexible
handle-anything-you-could-imagine function call interfaces to be used
from the processing code, as that would kill performance completely,
especially when dealing with very small buffers. Not needed, and only
generate bugs... If VST, TDM or DirectX does the job in your studio (or
whatever), you should certainly not miss anything here. Oh, and no one
will charge $1000, ask you to sign an NDA, or even require that you
don't improve or change the API in your engine, if you decide you want
the SDK. ;-)


So, what is it you want, more specifically? Would VST do, or do you want
video streaming, network transparency and other stuff that has nothing
to do with low latency real time? Can't have it all under one API for
performance and complexity reasons, but I'm open to any suggestions;
sane or insane! Still time for some more brainstorming before I start to
hack engine code.

Let's get this right from the start and whipe the floor with DirectX and
VST 2.0, so we get some serious plug-in developers over to Linux soon.
:-)


//David
--------------3B9A1E09619499BDFFF1E127
Content-Type: text/plain; charset=us-ascii;
 name="plugin.h"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="plugin.h"

/*
 *	Audiality Plug-In Programming Interface - draft 0.1
 *
 *	Copyright (C) David Olofson, 1999
 *
 *	This code is released under the terms of the LGPL
 */

struct plugin_instance_t;

/*
 * Plug-in "class" description
 * A filled-in plugin_t should be passed to the engine
 * when registering. (This should probably handle sample
 * rates for control signals as well, as those should
 * actually *be* audio streams... That is, different
 * rates for different inputs and outputs, but within
 * certain restrictions.)
 */
struct plugin_t
{
	/*
	 * Restrictions to the number of frames processed
	 * by one process_XXX() call
	 */
	int frames_flags;	/* FF_POWER_OF_TWO and things like that */
	int frames_min;
	int frames_max;
	int frames_granularity;	/* buffer size granularity */
	/*
	 * Restrictions to the sample rate
	 */
	int rate_flags;		/* RF_POWER_OF_TWO,... */
	float rate_min;
	float rate_max;
	float rate_granularity;	/* have to think more about this... */
	/*
	 * Instance constructor and destructor...
	 */
	int (*create) (plugin_instance_t *plugin);
	int (*destroy) (plugin_instance_t *plugin);
	/*
	 * process_mix() mixes data into destination buffers,
	 * process_replace() overwrites.
	 *
	 * ! process_mix() _requires_ the plug-in to have
	 * ! output gain controls for the outputs!
	 *
	 * ? Should these be present in instances as well,
	 * ? so that plug-ins can change callbacks runtime?
	 * ? Probably not, for various reasons. And would
	 * ? anyone have any use for it in real life?
	 */
	int (*process_mix) (plugin_instance_t *plugin,
				float **inputs, float **outputs,
				int frames);
	int (*process_replace) (plugin_instance_t *plugin,
				float **inputs, float **outputs,
				int frames);
};

/*
 * The plug-in instance struct.
 * These should be created by the *host*, as it may
 * want to add extra info outside the struct.
 * (The use of the word "frame" instead of "sample"
 * is because I have ideas for other uses...)
 */
struct plugin_instance_t
{
	plugin_t *kind;
	float framerate;
	float inherent_delay;	/* Inherent means inherent to the
				 * processing algorithm, and is
				 * used for processing latency
				 * compensation.
				 * Value is in frames, and should
				 * reflect sub-sample resolution.
				 */
	int look_ahead;		/* Number of extra frames needed
				 * after the end of input buffers.
				 * Can be negative.
				 */
	int skip_behind;	/* Number of frames skipped
				 * at the start of input buffers.
				 * (That is, inputs[n]+=look_behind
				 * before process_XXX() is called.)
				 * Can be negative.
				 */
	void *user_data;
};

--------------3B9A1E09619499BDFFF1E127--


From - Wed Aug 25 16:06:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA05333
	for <slinkp@ulster.net>; Tue, 24 Aug 1999 23:43:47 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA08298 for linux-audio-dev-list; Tue, 24 Aug 1999 23:10:31 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA08295 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 24 Aug 1999 23:10:29 -0400
Received: from swipnet.se (dialup84-11-8.swipnet.se [130.244.84.168]) 
          by mb04.swip.net (8.8.8/8.8.8) with ESMTP 
          id FAA06307; 
          Wed, 25 Aug 1999 05:07:41 +0200 (MET DST)
Message-ID: <37C35F36.69C8D357@swipnet.se>
Date: Wed, 25 Aug 1999 05:12:54 +0200
From: David Olofson <audiality@swipnet.se>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-RTL_BETA12 i686)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: Dave Phillips <dlphilp@bright.net>
CC: reactor <reactor@sagv5.gyakg.u-szeged.hu>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] plugin format
References: <19990825002133.A406@cerealbox> <37C34923.F0096D03@bright.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: bd2881400687d11c5a7ad38997d3a24a

Dave Phillips wrote:
(...)
> I haven't yet investigated the Xmms model, but Guenter Geiger has
> developed a straightforward model for his version of Mix.

Downloading Guenter's code... Might find a few cool ideas. :-)

Will look at Xmms. Do you know of a site/doc with specs, or where I can
get source easiest? (Will look around - just wondering if you have a
link handy.)

> Plug-in architectures abound, but you're right in claiming we should
> have a standard. I think it will happen, it's an important-enough topic.

Certainly. Now that Ingo Molnar have hacked the kernel where Benno
Senoner found latency problems, and we're approaching BeOS class
performance, we'll probably hear from developers and vendors. And
providing an easy way in, and a way to make all future Linux audio
applications and plug-ins cooperate nicely (as opposed the the normal
case with Windoze and MacOS...), means BeOS will be history. (Nice OS,
but it's still proprietary, and I have seen to many of those die,
regardless of their qualities... I will not go there.)


//David

From - Wed Aug 25 16:06:31 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA09460
	for <slinkp@ulster.net>; Wed, 25 Aug 1999 00:25:22 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA08333 for linux-audio-dev-list; Tue, 24 Aug 1999 23:40:37 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA08330 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 24 Aug 1999 23:40:34 -0400
Received: from swipnet.se (dialup84-11-8.swipnet.se [130.244.84.168]) 
          by mb04.swip.net (8.8.8/8.8.8) with ESMTP 
          id FAA10501 for <linux-audio-dev@ginette.musique.umontreal.ca>; 
          Wed, 25 Aug 1999 05:37:50 +0200 (MET DST)
Message-ID: <37C36645.92B9E049@swipnet.se>
Date: Wed, 25 Aug 1999 05:43:01 +0200
From: David Olofson <audiality@swipnet.se>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-RTL_BETA12 i686)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] And Yo, What's Audiality!?
References: <19990825002133.A406@cerealbox> <37C34923.F0096D03@bright.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8003
X-Mozilla-Status2: 00000000
X-UIDL: 3627e199fbe7db4bc98c3911c72bac96

In case people are starting to wonder who this plug-in maniac who just
jumped in is:

David Olofson, 24. Hacked various stuff for various machines for around
15 years, but released little of interest so far. Writes dance/R&B/soul
music; main instrument: vocals. Works as a programmer, doing mostly
embeded real time stuff for lab instruments in the $50,000 range.
(Currently developing a complete application under Linux/RTLinux. :-)

Dream hack: The ultimate high end audio system, based on pure CPU power
(multiprocessor, including clusters) and clean multi channel audio I/O
cards - no dedicated hardware to limit flexibility, no need for external
mixers, no noticable audio latency, no external machines with messy
protocols and slow interfaces... Just raw power to use for anything that
comes into mind.

Audiality is the foundation for this, and the most important part; a
hard real time kernel, is already there in the form of RTLinux. A driver
porting toolkit is what I'm hacking right now, and I've already tested a
ported sound card driver at the hardware limit of around .4 ms input ->
output latency; no drop-outs ever, regardless of system stress.

Audiality web site at:

	http://www.angelfire.com/or/audiality/audiality.html

(Sorry for the temporary halfway update; the downloads link can be found
at the bottom of the pages.)


//David

From - Wed Aug 25 16:06:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA11026
	for <slinkp@ulster.net>; Wed, 25 Aug 1999 00:42:11 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA08357 for linux-audio-dev-list; Tue, 24 Aug 1999 23:59:27 -0400
Received: from hotmail.com (wya-lfd113.hotmail.com [207.82.252.177]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id XAA08354 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 24 Aug 1999 23:59:25 -0400
Received: (qmail 32158 invoked by uid 0); 25 Aug 1999 03:56:41 -0000
Message-ID: <19990825035641.32157.qmail@hotmail.com>
Received: from 203.29.128.21 by www.hotmail.com with HTTP;
	Tue, 24 Aug 1999 20:56:39 PDT
X-Originating-IP: [203.29.128.21]
From: "J Digital" <joshdigital@hotmail.com>
To: dlphilp@bright.net, nettings@folkwang.uni-essen.de
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] convolution reverb ?
Date: Tue, 24 Aug 1999 20:56:39 PDT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 80b6387cc61ff7bf5f0a0c2567aac552

I use real time convolution all the time (except when i am emailing, or 
sleeping). I dont know how common my 'trick' is - but what i do is make a 
LONG circular buffer, eg 4 seconds, and specify a SMALL number of taps on 
that buffer (eg 64). Then you can do neat things by applying controller 
curves to not only the feedforward and feedback parameters, but also to the 
tap point..
check out some dodgy source code at www.response.cx

josh
--
josh@response.cx


>From: Dave Phillips <dlphilp@bright.net>
>To: Jrn Nettingsmeier <nettings@folkwang.uni-essen.de>
>CC: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
>Subject: Re: [linux-audio-dev] convolution reverb ?
>Date: Tue, 24 Aug 1999 13:25:49 -0400
>
>Jrn Nettingsmeier wrote:
>
> > at a workshop (see below) i learned about a concept called
> > convolution. [snip]
> >
> >   does anyone know about linux implementations of this concept ?
> > the algorithm doesnt appear too complicated, it seems its all
> > about cpu-time.
>
>Csound does pretty decent convolution, and my Csound Resources page
>lists some sources for impulse response files. You do have to be careful
>about amplitudes, but yes, the results are worth the time waiting.
>Convolution seems a bit beyond realtime at this point, at least for my
>machine. Does anyone know of research or implementation of realtime
>audio convolution ?
>
>Finally, there's a good explanation of it (with source code) in F.R.
>Moore's "Elements Of Computer Music".
>
>The Linux Csound/Csound Resources page is located at:
>
>	http://www.bright.net/~dlphilp/linux_csound.html
>
>Lots of great stuff listed here, and it has been updated as of this
>morning.
>
>== Dave Phillips
>
>        http://www.bright.net/~dlphilp/index.html
>    http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From - Wed Aug 25 16:06:48 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA32354
	for <slinkp@ulster.net>; Wed, 25 Aug 1999 10:45:30 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA09015 for linux-audio-dev-list; Wed, 25 Aug 1999 09:57:48 -0400
Received: from gauss.deltav.hu (gauss.deltav.hu [194.9.64.225]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA09012 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 25 Aug 1999 09:57:44 -0400
Received: from cerealbox (87.dial02.deltav.hu [194.9.64.87])
          by gauss.deltav.hu (Netscape Messaging Server 3.6)  with ESMTP
          id AAA32C4 for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Wed, 25 Aug 1999 15:58:07 +0200
Received: from reactor by cerealbox with local (Exim 1.92 #1 (Debian))
	id 11Jdbe-000049-00; Wed, 25 Aug 1999 16:00:50 +0200
Message-ID: <19990825160050.B172@cerealbox>
Date: Wed, 25 Aug 1999 16:00:50 +0200
From: reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] still plugins
Reply-To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.91.2
Organization: CTP media laboratories
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: a09396b1b5fee6a60fe8874b44b6209d

hyah!

but how can we do the plugins like under windoze?
i mean, those plugins are simple DLL files, there.
under linux these should be shared libraries (.so?) or what?

byah!

-- 

  Mt Rcz  ->  reactor/CTPmedia  <-  sound and MIDI software developer

  CTP Ltd., media division  ->  http://ctpmedia.scene.hu/
  my own personal homepage  ->  http://linux.gyakg.u-szeged.hu/~reactor/

From - Wed Aug 25 16:06:50 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA10919
	for <slinkp@ulster.net>; Wed, 25 Aug 1999 12:00:55 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA09136 for linux-audio-dev-list; Wed, 25 Aug 1999 11:13:56 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA09132 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 25 Aug 1999 11:13:54 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S44454AbPHYPKx>; Wed, 25 Aug 1999 18:10:53 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <37C2A18B.3AB948DA@folkwang.uni-essen.de>
	(nettings@folkwang.uni-essen.de)
Subject: Re: [linux-audio-dev] non-real-time EQ/FX ?
Message-Id: <19990825151103Z44454-31050+53@nic.funet.fi>
Date:   Wed, 25 Aug 1999 18:10:53 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d1440e46a49ea0cf120857775a0b5f01

>#2 high quality stand-alone reverberation

I'm working on such. But I will include 3D spatialization within such
reverb so that it takes sometime to complete it -- maybe this year.
Look at my patent free version of patented SB Live reverb at
"http://www.funet.fi/~kouhia/waves/".

I'm missing some AES conference papers/preprints on reverberation, anyone
could help me in getting them? Please mail me for detailed titles.

Yours,

Juhana

From - Wed Aug 25 16:06:49 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA09591
	for <slinkp@ulster.net>; Wed, 25 Aug 1999 11:50:53 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA09103 for linux-audio-dev-list; Wed, 25 Aug 1999 11:04:39 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA09100 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 25 Aug 1999 11:04:36 -0400
Received: from bright.net (find-cas2-cs-31.dial.bright.net [209.143.26.185])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id LAA09939;
	Wed, 25 Aug 1999 11:01:43 -0400 (EDT)
Message-ID: <37C40B8A.CFCD2C22@bright.net>
Date: Wed, 25 Aug 1999 11:28:10 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: David Olofson <audiality@swipnet.se>
CC: reactor <reactor@sagv5.gyakg.u-szeged.hu>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] plugin format
References: <19990825002133.A406@cerealbox> <37C34923.F0096D03@bright.net> <37C35F36.69C8D357@swipnet.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7a4903e4209509d36c30c554cc7d56d1

David Olofson wrote:

> Will look at Xmms. Do you know of a site/doc with specs, or where I can
> get source easiest? (Will look around - just wondering if you have a
> link handy.)

	http://www.xmms.org

Guenter is still polishing his plug-in API. He'll probably announce its
completion here.
 
> Certainly. Now that Ingo Molnar have hacked the kernel where Benno
> Senoner found latency problems, and we're approaching BeOS class
> performance, we'll probably hear from developers and vendors.

I didn't realize there was another active linux-sound mail list where
Alan Cox hangs out. Can anyone direct me to subscription information ?

> ...BeOS will be history. (Nice OS,
> but it's still proprietary, and I have seen to many of those die,
> regardless of their qualities... I will not go there.)

As nice as it looks, its closed-source nature is a major turn-off for
me. I've also not seen the expected flood of great applications expected
for it. If Linux can resolve latency and filesystem problems affecting
audio, then our platform will indeed become much more attractive to
professional developers. But they're going to want to see the money
trail...

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Wed Aug 25 16:06:52 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA16837
	for <slinkp@ulster.net>; Wed, 25 Aug 1999 12:46:41 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA09187 for linux-audio-dev-list; Wed, 25 Aug 1999 11:52:22 -0400
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id LAA09184 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 25 Aug 1999 11:52:20 -0400
Message-Id: <199908251552.LAA09184@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Timed Event Editor Framework
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Wed, 25 Aug 1999 11:48:58 -0400 (EDT)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
In-Reply-To: <Pine.GSO.4.10.9908202117200.25004-100000@ux02.CS.Princeton.EDU> from "David Slomin" at Aug 20, 99 11:24:51 pm
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2ba24d3aca50f9815dcb90d830146b36

David Slomin wrote:
> On Sat, 21 Aug 1999, Andreas Voss wrote:
> > Editing a csound .sco file and a MIDI files is very similar.
> 
> I take issue with this.  In CSound you specify all parameters for a note a
> the time that it is fired.  In MIDI, you add or modify parameters over
> time after the note has been fired.

That's a conceptual bug in Csound that IMO should be patched over --

Whatever the renderer, I'd like to approach a musical event as a
timestamped bundle of parameters: 
       (pitch_envelope == [3 3 3 3.1 3.2 3.1 3 2.9 ...],
        FM_index_envelope == [1 0.8 0.6 0.5 0.4 ...],
        filter_Q == 0.8
       )

If the rendering of abstract temporal data involves making a Csound
instrument accept continuous control from a table or through a
global(!?) variable, or involves placing each note on a separate MIDI
channel so it can be addressed... so be it.

Each instrument of course takes different parameters; one interesting
one would be the "cue audio" instrument, taking
       (sample: <an (audio) sample or a reference to one>,
        amplitude_envelope: float signal,
        pan_envelope: float signal,
        <whatever parameters seem like a good idea>
       )
So synthesizer control and audio sequencing fit into the same framework.

> Basically, to do this right, you'd want a complete set of scripting
> functionality: conditionals, loops, functions with parameters, etc.  These
> don't fit well into the linear event list model that's at the core of the
> sequencer.  

The linear event list model is at the core of MIDI, but should it be at
the core of the sequencer?  I hope to deal with music not as a flat list
of events, but as something with more temporal structure (structure laid
out by the composer, not the programmer), more parallel shape and control.

I see a few basic data-type constructors, each applicable to constructed
as well as atomic types.  And each, in a sequencer, with an associated
editing idiom (or several).  (This mention of temporal data types is way
too brief to be comprehensible, but if I get started I'll never stop.)

> > - simple algorithms (linear interpolation from start value to end value) 
> 
> Algorithms tend to come under the category of plugins.  This is another
> issue I've thought a lot about.  Keeping plugin-writing simple and
> powerful is the main reason I'm so adamant about keeping the fundamental
> data structure a single event list for the whole song (not even separate
> lists for separate tracks).  The algorithms are far simpler when you're
> dealing with linear streams.  I've lost a lot of hair because of CAL.

CAL is far too badly designed to be used as a warning against any
particular design approach. :-)  Seems to me it's easier to ignore
structure than it is to add it in after the fact.  Say something like

function delay_each_track(merged_tracks) =
        for each_track in merged_tracks, 
                for each event e in each_track,
                        old_e.time = e.time;  output old_e
                        old_e = e

        vs.

function delay_each_track(merged_tracks) =
        for each event e in merged_tracks,
                old_e[e.track].time = e.time;  output old_e[e.track]
                old_e[e.track] = e

Okay, the difference is not dramatic here, but as I start wanting more
and more temporal structure, it can either go in the data typing, or
I the programmer have to write code that parallels and maintains it by
hand.

> 1. A good MIDI sequencer.  This is the most important for me, and as the
> expression goes, if you want something done right, you have to do it
> yourself.  (Especially when nobody seems to agree with your definition of
> "done right"!)  That doesn't mean that I expect everyone to agree, but
> Jazz and KuBase aren't about to disappear either.

Fair enough, and I don't really expect you to turn on a dime and revamp
your stuff's conceptual basis after N years of development.  Just
getting some ideas skittering about....

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Wed Aug 25 16:06:54 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA18074
	for <slinkp@ulster.net>; Wed, 25 Aug 1999 12:55:41 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA09233 for linux-audio-dev-list; Wed, 25 Aug 1999 12:09:39 -0400
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id MAA09230 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 25 Aug 1999 12:09:37 -0400
Message-Id: <199908251609.MAA09230@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] convolution reverb ?
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Wed, 25 Aug 1999 12:06:43 -0400 (EDT)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
In-Reply-To: <37C2D59D.4350F185@bright.net> from "Dave Phillips" at Aug 24, 99 01:25:49 pm
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ad2602292090ae9e32734da5ecdd8e09

Dave Phillips wrote:
> Csound does pretty decent convolution, and my Csound Resources page
> lists some sources for impulse response files. You do have to be careful
> about amplitudes, but yes, the results are worth the time waiting.
> Convolution seems a bit beyond realtime at this point, at least for my
> machine. Does anyone know of research or implementation of realtime
> audio convolution ?

http://pcfarina.eng.unipr.it/aurora/waveconv.htm
describes (commercial) software that does 1-megapoint convolution in
real time on a p5/200.  (There's some other very snazzy-sounding stuff
in that package, too.)

Specifics are not mentioned, so I suspect "in real time" means just
that -- streaming processing -- with the usual delay from block-FFT
convolution.  You can get the delay down as low as you want by using
staggered blocks of increasing length, as described in Bill Gardner's
"Efficient convolution without input-output delay":
http://sound.media.mit.edu/people/billg/projects.html

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Wed Aug 25 16:06:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA24514
	for <slinkp@ulster.net>; Wed, 25 Aug 1999 13:41:50 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA09278 for linux-audio-dev-list; Wed, 25 Aug 1999 12:57:19 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id MAA09275 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 25 Aug 1999 12:57:17 -0400
From: est@hyperreal.org
Received: (qmail 14638 invoked by uid 162); 25 Aug 1999 16:54:24 -0000
Message-ID: <19990825165424.14637.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] Re: Timed Event Editor Framework
In-Reply-To: <199908251552.LAA09184@ginette.musique.umontreal.ca> from Eli Brandt
 at "Aug 25, 1999 11:48:58 am"
To: eli+@cs.cmu.edu
Date: Wed, 25 Aug 1999 09:54:24 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 8cfdc74929179e80c4b137ea4298dae6

Eli Brandt discourseth:
> 
> I see a few basic data-type constructors, each applicable to constructed
> as well as atomic types.  And each, in a sequencer, with an associated
> editing idiom (or several).  (This mention of temporal data types is way
> too brief to be comprehensible, but if I get started I'll never stop.)

Oh..please don't stop. :)

Eric

From - Wed Aug 25 16:46:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA18112
	for <slinkp@ulster.net>; Wed, 25 Aug 1999 16:49:23 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA09620 for linux-audio-dev-list; Wed, 25 Aug 1999 16:08:58 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA09617 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 25 Aug 1999 16:08:52 -0400
Received: from swipnet.se (dialup87-6-16.swipnet.se [130.244.87.96]) 
          by mb07.swip.net (8.8.8/8.8.8) with ESMTP 
          id VAA04471; 
          Wed, 25 Aug 1999 21:54:40 +0200 (MET DST)
Message-ID: <37C44B3A.ECA89700@swipnet.se>
Date: Wed, 25 Aug 1999 21:59:54 +0200
From: David Olofson <audiality@swipnet.se>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-RTL_BETA12 i686)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: Dave Phillips <dlphilp@bright.net>
CC: reactor <reactor@sagv5.gyakg.u-szeged.hu>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] plugin format
References: <19990825002133.A406@cerealbox> <37C34923.F0096D03@bright.net> <37C35F36.69C8D357@swipnet.se> <37C40B8A.CFCD2C22@bright.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 76ff6af2693c34db843ab89a077d8c8a

Dave Phillips wrote:
> 
> David Olofson wrote:
> 
> > Will look at Xmms. Do you know of a site/doc with specs, or where I can
> > get source easiest? (Will look around - just wondering if you have a
> > link handy.)
> 
>         http://www.xmms.org

Thanks! :-)

> Guenter is still polishing his plug-in API. He'll probably announce its
> completion here.

Ok...

> > Certainly. Now that Ingo Molnar have hacked the kernel where Benno
> > Senoner found latency problems, and we're approaching BeOS class
> > performance, we'll probably hear from developers and vendors.
> 
> I didn't realize there was another active linux-sound mail list where
> Alan Cox hangs out. Can anyone direct me to subscription information ?

Oh, this was on linux-kernel@veger.rutgers.edu, not a multimedia
specific list.

> > ...BeOS will be history. (Nice OS,
> > but it's still proprietary, and I have seen to many of those die,
> > regardless of their qualities... I will not go there.)
> 
> As nice as it looks, its closed-source nature is a major turn-off for
> me.

Same for me. I haven't seen so much interesting code to read in years as
in the Linux kernel, and being able to hack anything or borrow what you
need somewhere else, is incredibly valuable when dealing with hard real
time and other special stuff. RTLinux wouldn't even exist if it weren't
for that possibility.

> I've also not seen the expected flood of great applications expected
> for it. If Linux can resolve latency and filesystem problems affecting
> audio, then our platform will indeed become much more attractive to
> professional developers. But they're going to want to see the money
> trail...

Well, when all those serious hobby, semi-pro and pro users constantly
complaining about the latency and unreliability of Windoze and Mac gets
to know what's going on around here, and refuse to buy more half-way
"solutions" for those systesm, the developers will come here.

This is about so superior performance that no marketing in the world can
hide the fact that Windoze can never catch up, even if M$ should decide
to throw in a real time kernel and yet another bunch of APIs... True
*hard* real time with 5 ms in user space or less than .5 ms under
RTLinux, is a level of performance not available on any other desktop
OS, BeOS included.

(According to some pro developers, BeOS isn't hard real time, and
therefore has the same problems as Windoze and MacOS, even though the
performance is better. Haven't verified this myself, as the
"proprietary" obstacle is too big anyway.)


//David

From - Wed Aug 25 17:06:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA21574
	for <slinkp@ulster.net>; Wed, 25 Aug 1999 17:13:24 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA09651 for linux-audio-dev-list; Wed, 25 Aug 1999 16:29:38 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA09648 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 25 Aug 1999 16:29:36 -0400
Received: from swipnet.se (dialup87-6-16.swipnet.se [130.244.87.96]) 
          by mb07.swip.net (8.8.8/8.8.8) with ESMTP 
          id WAA03899; 
          Wed, 25 Aug 1999 22:25:03 +0200 (MET DST)
Message-ID: <37C45259.B6B425D4@swipnet.se>
Date: Wed, 25 Aug 1999 22:30:17 +0200
From: David Olofson <audiality@swipnet.se>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-RTL_BETA12 i686)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: Dave Phillips <dlphilp@bright.net>,
        reactor <reactor@sagv5.gyakg.u-szeged.hu>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] plugin format
References: <19990825002133.A406@cerealbox> <37C34923.F0096D03@bright.net> <37C35F36.69C8D357@swipnet.se> <37C40B8A.CFCD2C22@bright.net> <37C44B3A.ECA89700@swipnet.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7d3b7d5ee1fb4c33e229a155c7991b6b

David Olofson wrote:
> Oh, this was on linux-kernel@veger.rutgers.edu, not a multimedia
                                ^
Damn, I'm unconcentrated these days! Second time I have a typo in a
domain name...

This is the address to post to:
	linux-kernel@vger.rutgers.edu

Talk to majordomo@vger.rutgers.edu about subscription, but beware;
you'll get some 150 messages a day... :-)

See http://www.tux.org/lkml/#s3-4 for linux-kernel archives.


//David

From - Wed Aug 25 16:06:59 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA09003
	for <slinkp@ulster.net>; Wed, 25 Aug 1999 15:47:47 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA09436 for linux-audio-dev-list; Wed, 25 Aug 1999 14:59:52 -0400
Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA09433 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 25 Aug 1999 14:59:48 -0400
Received: (from uucp@localhost)
	by news-ma.rhein-neckar.de (8.8.8/8.8.8) with UUCP id UAA25380;
	Wed, 25 Aug 1999 20:56:44 +0200 (CEST)
	(envelope-from andreas@avix.rhein-neckar.de)
Received: from localhost (andreas@localhost [127.0.0.1])
	by avix.localnet (8.9.3/8.9.3) with ESMTP id XAA00480;
	Wed, 25 Aug 1999 23:40:21 +0200
Date: Wed, 25 Aug 1999 23:40:21 +0200 (MEST)
From: Andreas Voss <andreas@avix.rhein-neckar.de>
X-Sender: andreas@avix.localnet
To: David Slomin <dgslomin@CS.Princeton.EDU>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Timed Event Editor Framework
In-Reply-To: <Pine.GSO.4.10.9908202117200.25004-100000@ux02.CS.Princeton.EDU>
Message-ID: <Pine.LNX.4.10.9908211531230.433-100000@avix.localnet>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 9b8895c0bfb93e5e3ce8945e4700c432

David Slomin wrote:

> As a simple example, most of the time, you would want note-on and
> note-off events to be combined into note-with-duration pseudo events,
> but if you're addressing a drum machine, it is perfectly valid to have
> note-on's without corresponding note-off's.

True, but if you separate these internally, I'm afraid that the code will
become quite complicated because on all processing you have to deal with
pairs note-on/note-off and you have to be prepared that the note-off is
missing. Dont think its worth the extra trouble.

> The reason I'm writing this bugger is because I'm fed up with suboptimal
> interfaces specifically for MIDI editing, not because I want to create a
> half-hearted attempt to handle everything.  I really am shooting for the
> truly perfect UI, to the best of my ability.

If you write a highly specialized piano roll editor that edits NoteEvent
objects, couldn't there be a java interface that specifies the methods of
these NoteEvents so it can be implemented in different ways, e.g.
MidiNoteEvent, CSoundNoteEvent etc? 

> Check out the class derivation:

I came up with a similar class hierarchy for the midi backend. But the
rest of the application operates on abstract (not midi specific) event
interfaces, that support a variable number of parameters. These interfaces
are implemented by the specialized midi, csound or whatever event classes.

Also I think a single track-no is not powerful enough to structure a song.
If you had a PhraseEvent (an event that can contain other events),
arranging of a song (like intro, refrain etc) would be much easier. Also
it would allow to have nested structure (e.g. notes in a chord in a phrase
in a track in a song).

I agree that there is no "right" way to design a sequencer. If you want a
pure midi editor, your approach is the way to go. If you want to support
other musical concepts too, the flat midi event structure is probably not
the best foundation for the internal structures of a sequencer.

Best Regards,
Andreas

From - Thu Aug 26 02:12:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA00730
	for <slinkp@ulster.net>; Wed, 25 Aug 1999 18:32:37 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA09765 for linux-audio-dev-list; Wed, 25 Aug 1999 17:38:12 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA09762 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 25 Aug 1999 17:38:10 -0400
Received: from ulster.net (port212.king.ulster.net [208.242.160.213])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id RAA27332;
	Wed, 25 Aug 1999 17:49:32 -0400
Message-ID: <37C462ED.A0BF6B87@ulster.net>
Date: Wed, 25 Aug 1999 17:41:01 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
CC: reactor <reactor@sagv5.gyakg.u-szeged.hu>
Subject: Re: [linux-audio-dev] plugin format
References: <19990825002133.A406@cerealbox> <37C34923.F0096D03@bright.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: a9e504bfd38dfea3a8f408b6938bdb9e

Dave Phillips wrote:
(to Reactor)
> I checked out one of your MP3 files, good stuff there. What tools did
> you use to make them ?

I agree. "krunch" is the most interesting dance-type mp3 I have yet
downloaded (admittedly not all that many, but still!). I'm grabbing the
other at the moment... If you're making this stuff on a Linux box, I
want to know how!

--PW

From - Thu Aug 26 02:12:36 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA01283
	for <slinkp@ulster.net>; Wed, 25 Aug 1999 18:36:37 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA09803 for linux-audio-dev-list; Wed, 25 Aug 1999 18:01:46 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA09800 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 25 Aug 1999 18:01:44 -0400
Received: from ulster.net (port212.king.ulster.net [208.242.160.213])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id SAA30653;
	Wed, 25 Aug 1999 18:13:35 -0400
Message-ID: <37C463CC.26BFE9@ulster.net>
Date: Wed, 25 Aug 1999 17:44:44 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: David Olofson <audiality@swipnet.se>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] And Yo, What's Audiality!?
References: <19990825002133.A406@cerealbox> <37C34923.F0096D03@bright.net> <37C36645.92B9E049@swipnet.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e04d33463af1f55d7670d7c9c3e607bb

David Olofson wrote:

> Dream hack: The ultimate high end audio system, based on pure CPU power
> (multiprocessor, including clusters) and clean multi channel audio I/O
> cards - no dedicated hardware to limit flexibility, no need for external
> mixers, no noticable audio latency, no external machines with messy
> protocols and slow interfaces... Just raw power to use for anything that
> comes into mind.
(snip)

David, I read your posts and checked out your site. If you actually meet
your design goals (and I have no reason to think you won't), this will
be very, very, VERY cool.

And in my perpetual role as luser-on-the-dev.-list, I must ask the
obligatory annoying question:
WHEN WILL IT BE OUT???

Patiently yrs,

PW
----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================


From - Thu Aug 26 02:12:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA05229
	for <slinkp@ulster.net>; Wed, 25 Aug 1999 19:04:47 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA09871 for linux-audio-dev-list; Wed, 25 Aug 1999 18:23:22 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA09868 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 25 Aug 1999 18:23:20 -0400
Received: from swipnet.se (dialup251-1-175.swipnet.se [130.244.251.175]) 
          by mb04.swip.net (8.8.8/8.8.8) with ESMTP 
          id AAA23292; 
          Thu, 26 Aug 1999 00:20:27 +0200 (MET DST)
Message-ID: <37C46D64.27215A9A@swipnet.se>
Date: Thu, 26 Aug 1999 00:25:40 +0200
From: David Olofson <audiality@swipnet.se>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-RTL_BETA12 i686)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: Paul Winkler <slinkp@ulster.net>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] And Yo, What's Audiality!?
References: <19990825002133.A406@cerealbox> <37C34923.F0096D03@bright.net> <37C36645.92B9E049@swipnet.se> <37C463CC.26BFE9@ulster.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c9e59436c8d6168637d7fca5c55f3410

Paul Winkler wrote:
(...)
> David, I read your posts and checked out your site. If you actually meet
> your design goals (and I have no reason to think you won't), this will
> be very, very, VERY cool.

I think so to... That's what keeps me hacking through the nights. :-)

> And in my perpetual role as luser-on-the-dev.-list, I must ask the
> obligatory annoying question:
> WHEN WILL IT BE OUT???

That's very hard to say... But given that Mingo's very firm "soft" real
time hack will simplify things a lot around the user space part, and
that there are so many hackers interested in getting something together,
it'll most likely take less time than I expected. :-)

Anyway, I'll design and hack most of the RTLinux + user space engine,
there are others who have working code that might be usable in the
multichannel streamer daemon (the part that handles hard disk recording,
that is), and maintainers of other projects have shown interest in
suporting Audiality. Further, the Audiality engine will provide virtual
audio and MIDI devices (OSS compatible) for use by any applications,
which means you'll be able to use the real time processing as soon as
there's an engine, a tool to configure the routing and run the plug-in
GUIs, and an application capable of streaming to/from multichannel audio
devices. That is, Audiality acts like a digital mixer, which you feed
the audio streams from the applications directly into.

When? Well... Months until the first "usable" release, I'd guess.
Depends on how sucessful my design becomes, and how many hackers care to
help.


//David

From - Thu Aug 26 02:12:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA12088
	for <slinkp@ulster.net>; Wed, 25 Aug 1999 19:59:28 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA09941 for linux-audio-dev-list; Wed, 25 Aug 1999 19:24:01 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA09938 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 25 Aug 1999 19:23:59 -0400
Received: from swipnet.se (dialup251-1-175.swipnet.se [130.244.251.175]) 
          by mb04.swip.net (8.8.8/8.8.8) with ESMTP 
          id BAA16603; 
          Thu, 26 Aug 1999 01:21:09 +0200 (MET DST)
Message-ID: <37C47B9E.1D1ECCA2@swipnet.se>
Date: Thu, 26 Aug 1999 01:26:22 +0200
From: David Olofson <audiality@swipnet.se>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-RTL_BETA12 i686)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: golinvaux@benjamin.net
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] plugin format
References: <199908252203.AAA28470@chekov.Belgium.EU.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5ffc7c783644203e41db9ac34fdd651e

Benjamin GOLINVAUX wrote:
> 
> >From what I understand from your posts regarding Audiality, it is
> basically
> an audio (& midi ?) stream engine running under RTLinux...

Yep, audio and MIDI. (Actually, MIDI will go along with the rest of the
events used for automation. Reusable sub-systems means power,
flexibility, less code, less bugs...)

> It seems like a _very_ interesting idea, but I have some questions :
> 
> 1 disk performance
> 
> How does RTLinux interface with the filesystem ?

It doesn't.

> Could you imagine to
> let audiality access its own partition ( la ProTools) but, even then,

Pointless. Hard drives are "high latency" by nature...

> how do you predict the latency due to the hard disk ?

Impossible. No systems do that. It's all about buffering...

> Do the spec
> include an AV hard disk (it could be the _only_ solution) ?

Yep; non-AV drives stop reading/writing when doing thermal calibration,
which results in a bandwidth drop that would require tens of seconds of
buffering to handle at any significant load. However, AV drives are just
as "sloppy" as normal drives when it comes to access times and transfer
rates, so the same rule still applies: It's all about buffering.

Basically; keep seeks below 10% of the maximum seek frequency by always
reading big chunks of data from one file at a time. A reasonable value
is 384 kB per file for 32 tracks at 44.1 kHz, 16 bit data on a decent
5400 rpm drive. (Try this on Cakewalk, Cubase VST or whatever if you
like... That's how you actually get those programs to do anything
useful. They're still inefficient, though.)

Note: View the disk as analog tape. There are always access times... The
processing is done on the other end of the buffers, so the processing
latency, and consequently, the response time to real time user input, is
determined by the audio processing engine. For example, Benno Senoner
(hacked the latencytest program that Ingo Molnar used to analyse the
latency problems) managed to stream around 50 44.1 kHz mono tracks from
his 5400 rpm drive while mixing them only 4.3 ms before playback... And
that's rock solid - no drop-outs ever.

> 2 protected memory
> 
> The main question I have regarding this platform is : how do you debug
> it ? I understand rtlinux code can screw the machine...

Correct.

> Do you plan to
> provide protected memory mechanism ?

Yes, but that's not an easy hack. Someone did it, but it was never
released. Victor Yodaiken suggested a solution for scheduling into user
space from RTL, but Linus was more than unhappy with all those context
checks in every user space -> kernel entrance... I have some ideas, but
I have to study the kernel code and the x86 architecture a bit more
before I can say exactly *how* complicated it is, but obviously, it's
far from trivial. (Unless those who tried missed something...)

> One good thing would be to let people test and debug their plugins
> using SCHED_FIFO... Provided enough similarities between the two
> programming models...

That's _exactly_ what I'll do. Actually, the full blown engine will be
possible to compile as a user space daemon/server as well as the RTLinux
kernel version, so there's no difference whatsoever, appart from
latency.

> 3 drivers
> 
> Your driver abstraction layer seems very cool... It's just that there
> is no high-quality audio card for Linux yet, am I wrong ?

There are, but those I know anything about have only binary OSS
drivers... I *can* use those drivers, however, as long as they support
mmap(). It's possible to run the engine as an RTLinux periodic task,
synchronized with the interrupts from the sound card. (That is, the
standard driver runs the card "freewheel" in mmap() mode, while the
engine hooks in on the IRQ to sync it's [higher frequency] periodic
scheduler. The engine transfers data to/from the card through the
mmap()ed window, so it never has to leave RT context.)

> I'm actually trying to develop a small dsp test bed using BeOS (I'm not
> developing for Linux yet) and I think the MediaKit programming model is
> very clean.
> 
> However, this is not hard-real time, which I agree is _indispensable_
> for audio production (yes, indispensable).... But will the constraints
> of RTLinux be viable for the developers ?

What constraints? The only problem that a _serious_ hard real time
programmer would react on is the lack of protected memory, but this can
be fixed. And the fix won't have affect the plug-in code; not even
existing binaries, if the API is planned correctly from the start.

Regarding system calls: If you're a hard real time programmer, you know
that's out of the question unless the system is a pure RTOS. And even
with QNX and similar systems, obviously, all resources can't be hard
real time capable. The same rules apply to RTL - the only difference is
that RTL doesn't (yet) implement a full wrapper for the non-real time
system, so you can't do the silly mistake of breaking real time
performance by calling non-real time system calls.

> Another question : since BeOS claims to be the MediaOS (which I agree
> being given their nice architecture), is Linux _as good as BeOS_
> regarding audio _right now_ (I mean, even without audiality) ?
> 
> I read about the linux 5ms latency using a new kernel patch, which is
> slightly more than Be engineers claim to have achieved using an Event
> Layla...

Well, the Linux latency figures holds true for normal consumer sound
cards with standard drivers, and it's completely rock solid regardless
of system stress. This is with 80% of the CPU power being used for
signal processing in that 4.3 ms latency thread...

Layla is pretty good pro card (I happen to own one, BTW...) _designed_
for this kind of things. And what kind of driver is that Layla/BeOS
driver? Standard BeOS audio driver? And what about using the CPU from
that real time thread, and what about reliability? I won't take Be
Inc.'s claim too seriously until I get some _hard facts_ about what
they're actually doing.

There are many ways to cheat... We don't. :-)

> Does it mean that, under some circumstances, one can process and audio
> stream 'live' under Linux with 5ms latency WITHOUT GLITCHES ?

Yep. (However, I think you'll either get just above 5 ms, or have to use
less than 80% CPU for processing if you're streaming from audio in to
audio out.) Benno has stressed his machine for hours and hours without
ever getting a drop-out, and the only "problem" we have left is the 2.9
ms jitter peak that limits latency to those 4.3 ms.

> Does the non-preemptive kernel block the audio processing sometimes ?

Nope. :-)

> Network ?

Nope. :-)

> disk ?

Nope. :-)

> I'd be glad to know since my interest in BeOS in _only_ because of the
> potential good LIVE daw perdormance...

What do you need? Rock solid audio in -> audio out processing with
around 10 ms latency at 80% CPU load shouldn't be a problem. (You'll
have to ask Benno about the results of his full duplex streaming tests.
The 4.3 ms is from the thread to the output, so one or two buffer
fragments will have to be added to handle full duplex reliably. [3
fragments are used in the output-only test.])

With RTLinux, the limit is the sound card's smallest DMA burst size
and/or internal buffering. I've tested .4 ms (in -> out) on AudioPCI,
and it should easily cope with .6 ms with 90% CPU load.

And there's another solution: Locking one CPU on an SMP box for signal
processing. You can stay in user space, so memory protection is still
there, and if you go all the way and actually use a kernel patch that
keeps all non-SCHED_FIFO tasks off your RT CPU, you can get down to
latencies below a single sample frame. (However, that's kind of
pointless, as there's already a delay of at least 2 sample frames
because of the oversampling, and then there's the digital filters...)


//David

From - Thu Aug 26 02:12:45 1999
Received: from gauss.deltav.hu (gauss.deltav.hu [194.9.64.225])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id VAA21537
	for <slinkp@ulster.net>; Wed, 25 Aug 1999 21:03:53 -0400
Received: from cerealbox (107.dial02.deltav.hu [194.9.64.107])
          by gauss.deltav.hu (Netscape Messaging Server 3.6)  with ESMTP
          id AAA5F6E for <slinkp@ulster.net>;
          Thu, 26 Aug 1999 02:52:09 +0200
Received: from reactor by cerealbox with local (Exim 1.92 #1 (Debian))
	id 11JnoY-00004C-00; Thu, 26 Aug 1999 02:54:50 +0200
Message-ID: <19990826025449.A242@cerealbox>
Date: Thu, 26 Aug 1999 02:54:49 +0200
From: reactor/CTPmedia <reactor@linux.gyakg.u-szeged.hu>
To: Paul Winkler <slinkp@ulster.net>
Subject: Re: [linux-audio-dev] plugin format
Reply-To: reactor <reactor@linux.gyakg.u-szeged.hu>
References: <19990825002133.A406@cerealbox> <37C34923.F0096D03@bright.net> <37C462ED.A0BF6B87@ulster.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.91.2
In-Reply-To: <37C462ED.A0BF6B87@ulster.net>; from Paul Winkler on Wed, Aug 25, 1999 at 05:41:01PM -0400
Organization: CTP media laboratories
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 47688a56bee23a26cfe957593a136278

yah!

 >% I agree. "krunch" is the most interesting dance-type mp3 I have yet
 >% downloaded (admittedly not all that many, but still!). I'm grabbing the
 >% other at the moment... If you're making this stuff on a Linux box, I
 >% want to know how!

i've told about all this to Dave
the song is made with Buzz and Soundforge, so unfortunately no linux is
used. (well, the mpeg-encoding was done with BladeEnc :))))
i think you know Soundforge, but maybe you haven't heard about Buzz
before. check it out at: www.buzz2.com
it'd be real fun to have such stuff for linux. there're some tries,
e.g. gsynth seems to be a linux buzz-wannabe.


bye!

-- 

  Mt Rcz a.k.a. reactor  -  http://linux.gyakg.u-szeged.hu/~reactor/
   CTP media - since 1995   -  http://ctpmedia.scene.hu/

From - Thu Aug 26 02:12:47 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA31863
	for <slinkp@ulster.net>; Wed, 25 Aug 1999 22:18:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA10082 for linux-audio-dev-list; Wed, 25 Aug 1999 21:23:21 -0400
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id VAA10079 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 25 Aug 1999 21:23:18 -0400
Message-Id: <199908260123.VAA10079@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Re: sequencing..Symbolic Control Protocol
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Wed, 25 Aug 1999 21:20:05 -0400 (EDT)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
In-Reply-To: <19990821213738.25250.qmail@hyperreal.org> from "est@hyperreal.org" at Aug 21, 99 02:37:38 pm
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 357f245038f601474eb3af0cddeb2a80

est@hyperreal.org wrote:
> 
> Eli Brandt discourseth:
> > 
> > The way I think, I'd prefer a music sequencer that handles abstract
> > time-structured data and maps it to MIDI.
> 
> I'm totally into this approach.  I think a canonical textual
> representation is useful as well.
> 
> For example, oolaboola (www.hyperreal.org/~est/oolaboola) has complete
> separation of the dsp and the gui.  They communicate over a pair of
> pipes using something I call (though it's only in a nascent state)
> Symbolic Control Protocol (scp) which uses Scheme symbolic expressions
> for its lexical structure.  Both the protocol and oola's use of it
> need considerable fleshing out.  All communications from the gui to
> the dsp are logged to a time-stamped (in its name) sequence file.  The
> file has entries like:
> 
>  (delta 31.010903 (file0 "/music/all-in-your-hands.wav"))
> 
> ..meaning 31.010903 seconds after the previous event, load
> "/music/all-in-your-hands.wav" onto player 0.
> 
> The oola distribution includes a tiny sequencer program (`seq', which
> is installed into the oola library directory) which can be used to run
> the dsp using one of these log files.
> 
> The long-term idea is that scp-speaking resources would have a grammar.
> For example a midi device might have a grammar that includes
> 
> (type channel (range 1 16))
> (type key (range 0 127))
> (type velocity (range 0 127))
> 
> (event (| (note-on channel key velocity))
>         ...)

Interesting.  I'm imagining that an scp-using program would accept an
arbitrary scp grammar, and let you edit a stream of events within that
grammar.  Hmm, where's the timing, attached to each event?

One point to look at is whether this carries enough semantic
information for the editor to use.  The grammar elements (timestamp
blah float) and (stretch blah float) are formally indistinguishable
until you grok the words "timestamp" and "stretch", but an editor
wants to put different UI handles on those floats.

BTW, a different approach to control:
http://cnmat.CNMAT.Berkeley.EDU/OpenSoundControl/
Hierarchical specification of message target; opaque binary message data.
Hard to edit opaque binary data, isn't it?

> It might be worthwhile to restrict such grammars to be regular (in the
> linguistic complexity sense).

Context-free is probably necessary and sufficient.  (Lookahead is bad
news for streaming, eh.)

> One obvious question about the scp approach is `why not XML'?

"<foo>bar baz</foo>", "(foo bar baz)", what's the difference, right?
If, as I understand it, XML tags are paren-nested.

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Thu Aug 26 02:12:37 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA03169
	for <slinkp@ulster.net>; Wed, 25 Aug 1999 18:49:01 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA09833 for linux-audio-dev-list; Wed, 25 Aug 1999 18:06:32 -0400
Received: from chekov.Belgium.EU.net (chekov.belgium.eu.net [193.74.208.161]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA09830 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 25 Aug 1999 18:06:30 -0400
Received: from (adial154.liege.eunet.be [195.207.174.154])
	by chekov.Belgium.EU.net  with SMTP id AAA28470 
	for <linux-audio-dev@ginette.musique.umontreal.ca>;
	Thu, 26 Aug 1999 00:03:41 +0200 (MET DST)
Message-Id: <199908252203.AAA28470@chekov.Belgium.EU.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] plugin format
Date: Wed, 25 Aug 1999 23:57:00 Set the time zone in the Time preference utility
From: "Benjamin GOLINVAUX" <golinvaux@benjamin.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1251"
Reply-To: golinvaux@benjamin.net
X-Mailer: BeOS Mail [R4.5.1]
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: adbeaf32dd88a73727efb9da396d3b14


>From what I understand from your posts regarding Audiality, it is 
basically
an audio (& midi ?) stream engine running under RTLinux...

It seems like a _very_ interesting idea, but I have some questions :

1 disk performance

How does RTLinux interface with the filesystem ? Could you imagine to 
let audiality access its own partition ( la ProTools) but, even then, 
how do you predict the latency due to the hard disk ? Do the spec 
include an AV hard disk (it could be the _only_ solution) ?

2 protected memory

The main question I have regarding this platform is : how do you debug 
it ? I understand rtlinux code can screw the machine... Do you plan to 
provide protected memory mechanism ?

One good thing would be to let people test and debug their plugins 
using SCHED_FIFO... Provided enough similarities between the two 
programming models...

3 drivers

Your driver abstraction layer seems very cool... It's just that there 
is no high-quality audio card for Linux yet, am I wrong ?


I'm actually trying to develop a small dsp test bed using BeOS (I'm not 
developing for Linux yet) and I think the MediaKit programming model is 
very clean.

However, this is not hard-real time, which I agree is _indispensable_ 
for audio production (yes, indispensable).... But will the constraints 
of RTLinux be viable for the developers ?


Another question : since BeOS claims to be the MediaOS (which I agree 
being given their nice architecture), is Linux _as good as BeOS_ 
regarding audio _right now_ (I mean, even without audiality) ?

I read about the linux 5ms latency using a new kernel patch, which is 
slightly more than Be engineers claim to have achieved using an Event 
Layla...

Does it mean that, under some circumstances, one can process and audio 
stream 'live' under Linux with 5ms latency WITHOUT GLITCHES ? 

Does the non-preemptive kernel block the audio processing sometimes ? 
Network ? disk ?

I'd be glad to know since my interest in BeOS in _only_ because of the 
potential good LIVE daw perdormance...


Benjamin-

From - Thu Aug 26 13:08:43 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA03739
	for <slinkp@ulster.net>; Thu, 26 Aug 1999 06:30:44 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA10810 for linux-audio-dev-list; Thu, 26 Aug 1999 05:28:35 -0400
Received: from mout0.01019freenet.de (mout0.01019freenet.de [62.104.201.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA10807 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 26 Aug 1999 05:28:32 -0400
Received: from [62.104.201.6] (helo=mx0.01019freenet.de)
	by mout0.01019freenet.de with esmtp (Exim 3.03 #1)
	id 11Jvmw-000098-00
	for linux-audio-dev@ginette.musique.umontreal.ca; Thu, 26 Aug 1999 11:25:42 +0200
Received: from [212.81.162.149] (helo=gmx.de)
	by mx0.01019freenet.de with esmtp (Exim 3.03 #1)
	id 11Jvmv-0005DZ-00
	for linux-audio-dev@ginette.musique.umontreal.ca; Thu, 26 Aug 1999 11:25:42 +0200
Message-ID: <37C4FB0F.17BBF73D@gmx.de>
Date: Thu, 26 Aug 1999 10:30:07 +0200
From: depet <depet@gmx.de>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.11 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] dynamic programming
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 7cdf63294d53fa154642af4cec2ac89c

I know that this list probably isn't the right place
for this question but I'm currently writing a realtime
effects app for two soundcards(because of the 8/16 bit 
dac problem sb16 have and the missing mute mic -> master-out).

I'm a newbie to C and my problem is to get a vector of integers
dynamically allocated (or something like that) as I'm using
samples as integers in the processing way.

It's for the flanger and the echo/reverb, they should be
configurable at runtime for the different lengths and depths.

thank you.

From - Thu Aug 26 13:08:45 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA03788
	for <slinkp@ulster.net>; Thu, 26 Aug 1999 06:31:31 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA10832 for linux-audio-dev-list; Thu, 26 Aug 1999 05:35:18 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA10828 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 26 Aug 1999 05:35:14 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m11Jvv7-000dylC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Thu, 26 Aug 1999 11:34:09 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Thu, 26 Aug 1999 11:34:09 +0200 (CEST)
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Mix with plugins
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14277.1416.415452.457000@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 3416112566f609caee028fb5bf1442f1


Hi !

As there has been a lot of discussion about plugin interfaces, realtime
scheduling and the like on this list, I thought I probably announce 
my recent hacks with plugins and mix.

The sources are accessible via anonymous CVS:

cvs -d :pserver:anonymous@gige.xdv.org:/cvs login

cvs checkout mix
cvs checkout strummin


The strummin plugin interface is rather basic, modelled loosely after
VST1.0.

It's not well worked out yet (hey, I only had one week for design and 
implementation), but functional for it's purpose within mix.

Plugins are shared objects, which are loaded from the main
application.

Mix currently only supports "int" plugins, but the plugin interface
can do other types too. I'm planning to add floating point support
soon.

If people want to try their favorite filter, effect or the like within 
mix, go ahead programming a plugin, send me the code and suggestions
how to make the API better :)

Guenter

From - Thu Aug 26 15:18:53 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA08951
	for <slinkp@ulster.net>; Thu, 26 Aug 1999 15:26:09 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA11411 for linux-audio-dev-list; Thu, 26 Aug 1999 14:37:27 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id OAA11408 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 26 Aug 1999 14:37:24 -0400
From: est@hyperreal.org
Received: (qmail 24264 invoked by uid 162); 26 Aug 1999 18:34:31 -0000
Message-ID: <19990826183431.24261.qmail@hyperreal.org>
Subject: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
In-Reply-To: <14277.1416.415452.457000@gige> from Guenter Geiger at "Aug 26,
 1999 11:34:09 am"
To: Guenter Geiger <geiger@epy.co.at>
Date: Thu, 26 Aug 1999 11:34:31 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: dee4c209a9bb4bc17a864ec4f35819d1

Guenter Geiger discourseth:
> 
> If people want to try their favorite filter, effect or the like within 
> mix, go ahead programming a plugin, send me the code and suggestions
> how to make the API better :)

Here are my suggestions for the API taking it as a starting point for
a general plugin standard.  I understand that Guenter may not have
intended it to be used for that purpose, but, in any case, I applaud
him for taking the lead on this by posting his API. :) I'm really
excited about the idea of coding to a spec that this list has worked
over.  The prosepctive increase in functionality is dazzling.  I hope
Guenter will put audioplug.h on the web for wider availability.

Note that these suggestions take the contents of the strummin
directory as their context.  Many of my suggestions may be based on
ignorance or misunderstandings.

* The whole thing should move to a class/instance paradigm so I can
  instantiate multiple instances of a plugin.  Parameter descriptions
  should be in the class and their values in the instance, etc.

* The only global defined by a plugin should be a uniquely named
  function that returns a plugin class.  The idea here is to make it
  possible to use static as well as dynamic linking.

* Change properties to a * int32_t to avoid binary compatibility concerns.

* Change sparebytes to a void * for the same reason.

* Change the prefix to something other than `st_' which has too much
  history in unix.  A three-character prefix would be much safer.

* Use uint32_t instead of u_int32_t for POSIX 1.g compatibility.

* The param/type field needs some definition and should have an enum
  type.

* We want to be able to say that a param must be integral.

* There should be a parameter default value field along with a flag so
  say whether it's valid.

* String parameters should be provided for.

* We need a flag to say whether a parameter can be modified in between
  any two calls to the process method as opposed to being settable only
  for initizlization purposes.

* The number of channels per input and output signal should be a
  plugin property vector.  Counts of frames and samples should be
  clearly distinguished throughout.

* The sample rate should be optionally settable at instance creation
  time and the input and output buffer sizes should be optionally
  settable per call to the process method.  I usually code in a way that
  can accomodate this, but I agree that it's important to support less
  flexible plugins as well.

* To handle resampling, variable output buffer sizes are important.
  It's also important that the process method can report how many output
  frames it generated (is this the function of the return value of the
  process method?).  It may even be important that the plugin can
  be queried as to how many output frames *will* be generated to avoid
  overruns due to disagreements about fencepost issues.

* The popup method should probably be expanded to a vector of generic
  gui methods.

* Memory allocation hooks are probably desirable.  That way I can get
  a plugin to throw bad_alloc even if it know nothing about C++.

Hmm..enough for now. :)

Eric

From - Thu Aug 26 23:43:57 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA19025
	for <slinkp@ulster.net>; Thu, 26 Aug 1999 16:30:49 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA11517 for linux-audio-dev-list; Thu, 26 Aug 1999 15:43:15 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA11514 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 26 Aug 1999 15:43:12 -0400
From: est@hyperreal.org
Received: (qmail 6741 invoked by uid 162); 26 Aug 1999 19:40:18 -0000
Message-ID: <19990826194018.6740.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
In-Reply-To: <19990826183431.24261.qmail@hyperreal.org> from "est@hyperreal.org"
 at "Aug 26, 1999 11:34:31 am"
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Thu, 26 Aug 1999 12:40:18 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: dce855360f699537fb9733e948f03170

est@hyperreal.org discourseth:
>
> * Use uint32_t instead of u_int32_t for POSIX 1.g compatibility.

Come to think of it, including glib.h and using guint32 etc might be
even better.

Eric

From - Thu Aug 26 23:43:58 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA20558
	for <slinkp@ulster.net>; Thu, 26 Aug 1999 16:41:49 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA11553 for linux-audio-dev-list; Thu, 26 Aug 1999 15:54:25 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA11550 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 26 Aug 1999 15:54:21 -0400
From: est@hyperreal.org
Received: (qmail 19663 invoked by uid 162); 26 Aug 1999 19:51:11 -0000
Message-ID: <19990826195111.19662.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] Re: sequencing..Symbolic Control Protocol
In-Reply-To: <199908260123.VAA10079@ginette.musique.umontreal.ca> from Eli Brandt
 at "Aug 25, 1999 09:20:05 pm"
To: eli+@cs.cmu.edu
Date: Thu, 26 Aug 1999 12:51:11 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3fe412ac76db719c627e0481080b9f92

Eli Brandt discourseth:
> 
> Interesting.  I'm imagining that an scp-using program would accept an
> arbitrary scp grammar, and let you edit a stream of events within that
> grammar.

Exactly.

> Hmm, where's the timing, attached to each event?

The files I'm generating at the moment are of the form:

 (delta <time since preceeding event> <event>) ...

> One point to look at is whether this carries enough semantic
> information for the editor to use.

Certainly not yet..or not to be fun to use anyhow.

> The grammar elements (timestamp
> blah float) and (stretch blah float) are formally indistinguishable
> until you grok the words "timestamp" and "stretch", but an editor
> wants to put different UI handles on those floats.

Yeah, the editor *has* to know about times.  Conventions for many
other things are desirable as well.

An editor might be able to provide *some* conveniences based on the
actual usage in a data stream it's editing.  After all, if a parameter
is set once at the beginning, it's an instrument/performance
parameter.  If it's set thousands of times, it's a continuous
controller.

This is all of fairly vital interest to me since I'm already
generating the data sets. :O

> BTW, a different approach to control:
> http://cnmat.CNMAT.Berkeley.EDU/OpenSoundControl/
> Hierarchical specification of message target; opaque binary message data.
> Hard to edit opaque binary data, isn't it?

Eww..but I shall check it out! :)

> > One obvious question about the scp approach is `why not XML'?
> 
> "<foo>bar baz</foo>", "(foo bar baz)", what's the difference, right?
> If, as I understand it, XML tags are paren-nested.

More or less yeah.  I'd think that (e.g.) a (note-on 5 60 90) scp
datum plus an scp midi grammar should allow the automatic creation of
<note-on channel=5 key=60 velocity=90> and vice versa.

Eric

From - Thu Aug 26 23:44:02 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA26371
	for <slinkp@ulster.net>; Thu, 26 Aug 1999 17:17:26 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA11630 for linux-audio-dev-list; Thu, 26 Aug 1999 16:32:27 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id QAA11627 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 26 Aug 1999 16:32:23 -0400
From: est@hyperreal.org
Received: (qmail 14080 invoked by uid 162); 26 Aug 1999 20:25:43 -0000
Message-ID: <19990826202543.14078.qmail@hyperreal.org>
Subject: [linux-audio-dev] we should use gtk objects for our plugins
In-Reply-To: <19990826194018.6740.qmail@hyperreal.org> from "est@hyperreal.org"
 at "Aug 26, 1999 12:40:18 pm"
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Thu, 26 Aug 1999 13:25:43 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: bda2df76f12db29eecb367b42ccafccb

OK, people..considering I'm now replying to myself replying to myself, I'm
probably losing it. :)

est@hyperreal.org discourseth:
> est@hyperreal.org discourseth:
> >
> > * Use uint32_t instead of u_int32_t for POSIX 1.g compatibility.
> 
> Come to think of it, including glib.h and using guint32 etc might be
> even better.

Using the gtk object system for our plugins might be best of all.  It
provides a C-based object system with wide use and multi-lingual
support.  Note that gtk objects (as opposed to widgets) have nothing
X-windows-specific about them.  I'm pretty sure this approach could be
Audiality-friendly, for example.

Interested parties should look in particular at gtkobject.[ch],
gtktypeutils.[ch] and gtkarg.[ch].  Doesn't it look like a plugin API?
:)  We need only make a domain-specific sub-class.

What do you think?

Eric

From - Thu Aug 26 23:44:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA27802
	for <slinkp@ulster.net>; Thu, 26 Aug 1999 17:27:05 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA11661 for linux-audio-dev-list; Thu, 26 Aug 1999 16:42:25 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id QAA11658 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 26 Aug 1999 16:42:22 -0400
From: est@hyperreal.org
Received: (qmail 5119 invoked by uid 162); 26 Aug 1999 20:39:30 -0000
Message-ID: <19990826203930.5118.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] Re: sequencing..Symbolic Control Protocol
In-Reply-To: <Pine.LNX.4.10.9908262328060.321-100000@avix.localnet> from Andreas
 Voss at "Aug 26, 1999 11:32:44 pm"
To: Andreas Voss <andreas@avix.rhein-neckar.de>
Date: Thu, 26 Aug 1999 13:39:30 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: fd7788a1d917fb9ca20ae7272eb6e55f

Andreas Voss discourseth:
> > > One obvious question about the scp approach is `why not XML'?
> > 
> > "<foo>bar baz</foo>", "(foo bar baz)", what's the difference, right?
> 
> The big advantage of XML is that there are tons of resources like editors,
> parsers etc available.

Can you recommend any good xml editors?  I'd be especially interested
in those that can abstract curves of continuous controller data for
easy editing.

The existing parsers don't seem very useful for handling streaming
control input (it just doesn't seem to fit the xml paradigm), though I
could very well be wrong about that.

Thanks,

Eric

From - Thu Aug 26 23:44:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA32099
	for <slinkp@ulster.net>; Thu, 26 Aug 1999 17:55:41 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA11708 for linux-audio-dev-list; Thu, 26 Aug 1999 17:10:10 -0400
Received: from mail.virginia.edu (mail.Virginia.EDU [128.143.2.9]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id RAA11705 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 26 Aug 1999 17:10:08 -0400
Received: from neon.mail.virginia.edu by mail.virginia.edu id aa24441;
          26 Aug 99 17:07 EDT
Received: from virginia.edu (djt7p@jangle.music.Virginia.EDU [128.143.140.24])
	by neon.mail.Virginia.EDU (8.8.7/8.8.7) with ESMTP id RAA11974
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 26 Aug 1999 17:07:16 -0400 (EDT)
Message-ID: <37C5ACBF.A8A03203@virginia.edu>
Date: Thu, 26 Aug 1999 17:08:15 -0400
From: "David J. Topper" <topper@virginia.edu>
Organization: UVA - VCCM
X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i686)
MIME-Version: 1.0
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Good MIDI library?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: c2451e446acb5ecd35181435fb9e4b49

Hi folks,

I'm looking for a simple / robust MIDI parser written in C to plug into
an interface package I'm working on.  I don't need something that does
polling, I'm using GTK/GDK for that.  So what I really need to be able
to do is feed the thing some MIDI bytes, then have it tell me what they
are (eg., NOTE_ON, NOTE_OFF, PITCH_BEND) and so forth.

Thanks all,

Dave Topper
--
Technical Director, Virginia Center for Computer Music
http://www.people.virginia.edu/~djt7p

From - Thu Aug 26 23:44:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA21280
	for <slinkp@ulster.net>; Thu, 26 Aug 1999 16:46:33 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA11567 for linux-audio-dev-list; Thu, 26 Aug 1999 16:00:30 -0400
Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA11564 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 26 Aug 1999 16:00:20 -0400
Received: (from uucp@localhost)
	by news-ma.rhein-neckar.de (8.8.8/8.8.8) with UUCP id VAA16166;
	Thu, 26 Aug 1999 21:56:46 +0200 (CEST)
	(envelope-from andreas@avix.rhein-neckar.de)
Received: from localhost (andreas@localhost [127.0.0.1])
	by avix.localnet (8.9.3/8.9.3) with ESMTP id XAA00390;
	Thu, 26 Aug 1999 23:32:44 +0200
Date: Thu, 26 Aug 1999 23:32:44 +0200 (MEST)
From: Andreas Voss <andreas@avix.rhein-neckar.de>
X-Sender: andreas@avix.localnet
To: eli+@cs.cmu.edu
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: sequencing..Symbolic Control Protocol
In-Reply-To: <199908260123.VAA10079@ginette.musique.umontreal.ca>
Message-ID: <Pine.LNX.4.10.9908262328060.321-100000@avix.localnet>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 6113210b3585d1706c64cff1f208dfa2

> > One obvious question about the scp approach is `why not XML'?
> 
> "<foo>bar baz</foo>", "(foo bar baz)", what's the difference, right?

The big advantage of XML is that there are tons of resources like editors,
parsers etc available.

Andreas


From - Thu Aug 26 23:44:07 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA14621
	for <slinkp@ulster.net>; Thu, 26 Aug 1999 19:49:38 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA11833 for linux-audio-dev-list; Thu, 26 Aug 1999 19:05:17 -0400
Received: from gauss.deltav.hu (gauss.deltav.hu [194.9.64.225]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA11830 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 26 Aug 1999 19:05:13 -0400
Received: from cerealbox (70.dial02.deltav.hu [194.9.64.70])
          by gauss.deltav.hu (Netscape Messaging Server 3.6)  with ESMTP
          id AAA276 for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Fri, 27 Aug 1999 01:05:21 +0200
Received: from reactor by cerealbox with local (Exim 1.92 #1 (Debian))
	id 11K8co-00009N-00; Fri, 27 Aug 1999 01:08:06 +0200
Message-ID: <19990827010806.B312@cerealbox>
Date: Fri, 27 Aug 1999 01:08:06 +0200
From: reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Mix with plugins
Reply-To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
References: <14277.1416.415452.457000@gige>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.91.2
In-Reply-To: <14277.1416.415452.457000@gige>; from Guenter Geiger on Thu, Aug 26, 1999 at 11:34:09AM +0200
Organization: CTP media laboratories
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 60a7178ffe1914bf993a2dd043841cee

 >% The sources are accessible via anonymous CVS:

can't i simply download 'em somewhere? i don't have any kind of cvs stuff
here at home :)

and i still can't see how the plugin system could be done through shared
libraries. could anyone enlight me about the system calls to read/use
shared libraries' functions?

bye!
 
-- 

  Mt Rcz a.k.a. reactor  -  http://linux.gyakg.u-szeged.hu/~reactor/
   CTP media - since 1995   -  http://ctpmedia.scene.hu/

From - Thu Aug 26 23:44:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA14626
	for <slinkp@ulster.net>; Thu, 26 Aug 1999 19:49:40 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA11843 for linux-audio-dev-list; Thu, 26 Aug 1999 19:09:56 -0400
Received: from gauss.deltav.hu (gauss.deltav.hu [194.9.64.225]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA11840 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 26 Aug 1999 19:09:53 -0400
Received: from cerealbox (70.dial02.deltav.hu [194.9.64.70])
          by gauss.deltav.hu (Netscape Messaging Server 3.6)  with ESMTP
          id AAA2B2 for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Fri, 27 Aug 1999 01:10:12 +0200
Received: from reactor by cerealbox with local (Exim 1.92 #1 (Debian))
	id 11K8hV-00009U-00; Fri, 27 Aug 1999 01:12:57 +0200
Message-ID: <19990827011257.C312@cerealbox>
Date: Fri, 27 Aug 1999 01:12:57 +0200
From: reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] bytesex
Reply-To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.91.2
Organization: CTP media laboratories
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 11a75ba88069d6e7c9936c63d3f7c990

yo!

what should we do about bytesex? i want my program to run on every machine
that has linux, not just on lousy 80x86s.

a dude on irc said i should store my data in network format, using the
system calls ntohl, ntohs, htonl, htons.

i thought about that i should write (actually, rip out from Mikmod's source)
specific filereading/writing routines for little and big endian machines.

any new ideas?


ps: glib is cool, so we should use it as a standard base for lotsa stuff.

-- 

  Mt Rcz a.k.a. reactor  -  http://linux.gyakg.u-szeged.hu/~reactor/
   CTP media - since 1995   -  http://ctpmedia.scene.hu/

From - Thu Aug 26 23:44:10 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA19366
	for <slinkp@ulster.net>; Thu, 26 Aug 1999 20:24:47 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA11895 for linux-audio-dev-list; Thu, 26 Aug 1999 19:49:22 -0400
Received: from fep10-svc.tin.it (mta10-acc.tin.it [212.216.176.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA11892 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 26 Aug 1999 19:49:20 -0400
Received: from tin.it ([212.216.171.123]) by fep10-svc.tin.it
          (InterMail v4.01.01.02 201-229-111-106) with ESMTP
          id <19990826234626.CNVD27109.fep10-svc@tin.it>
          for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Fri, 27 Aug 1999 01:46:26 +0200
Message-ID: <37C5D008.E3CCE36C@tin.it>
Date: Fri, 27 Aug 1999 01:38:48 +0200
From: Maurizio Umberto Puxeddu <umbpux@tin.it>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
CC: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Mix with plugins
References: <14277.1416.415452.457000@gige> <19990827010806.B312@cerealbox>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: da4d913a3585e59ef85f2640a667d424

reactor/CTPmedia wrote:
>[...snip...]
> and i still can't see how the plugin system could be done through shared
> libraries. could anyone enlight me about the system calls to read/use
> shared libraries' functions?

It's very easy: use dlopen(), dlsym() and dlclose().

You define a plugin as a shared module that defines certain symbols, say 

// BOGO HEADER STARTS HERE
int audioplugin_init(void);
int audioplugin_process(sample_t *in, sample_t *out);
int audioplugin_shotdown(void);
int audioplugin_status;
// BOGO HEADER ENDS HERE

Then you open the library (plugin) with dlopen() and ask for the value
of the symbols you have to use.

// BOGO CODE STARTS HERE

plugin = dlopen("Superreverb.so", RTDL_LAZY);
int ( *superreverb_init)(void) = dlsym(plugin, "audioplugin_init");
// etc.

// Then 

superreverb_init();
// etc.

// BOGOCODE ENDS HERE

See the their man pages, including the short example that says all, for
additional info.

Ciao!
Maurizio Umberto Puxeddu

From - Thu Aug 26 23:44:11 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA19372
	for <slinkp@ulster.net>; Thu, 26 Aug 1999 20:24:48 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA11889 for linux-audio-dev-list; Thu, 26 Aug 1999 19:48:16 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id TAA11886 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 26 Aug 1999 19:48:13 -0400
From: est@hyperreal.org
Received: (qmail 29056 invoked by uid 162); 26 Aug 1999 23:45:14 -0000
Message-ID: <19990826234514.29055.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] bytesex (and dynamic loading reference)
In-Reply-To: <19990827011257.C312@cerealbox> from reactor/CTPmedia at "Aug 27,
 1999 01:12:57 am"
To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
Date: Thu, 26 Aug 1999 16:45:14 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 28beea9ba4b5dc6d9f5abd6fbdce54bf

reactor/CTPmedia discourseth:
[Charset iso-8859-2 unsupported, filtering to ASCII...]
> yo!
> 
> what should we do about bytesex? i want my program to run on every machine
> that has linux, not just on lousy 80x86s.

glib is *full* of bytesex stuff..including swapping routines with
architecture-conditional speed-ups.

> a dude on irc said i should store my data in network format, using the
> system calls ntohl, ntohs, htonl, htons.

glib provides versions of these.  I think network order is important
mostly when transmitting data over a network..in which case, it should
be used.  What irc channels/servers do you frequent?

> ps: glib is cool, so we should use it as a standard base for lotsa stuff.

In my paid work I need to support code on *lots* of unixes.  glib has
proven quite robust.  Only today have I started to realize how useful
it can be for audio routines as well. :)

Also, you were asking about dynamic loading.  See the dlopen(),
dlsym(), etc man pages.

Eric

From - Thu Aug 26 23:44:21 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA04923
	for <slinkp@ulster.net>; Thu, 26 Aug 1999 22:34:08 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA12149 for linux-audio-dev-list; Thu, 26 Aug 1999 21:54:25 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA12146 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 26 Aug 1999 21:54:22 -0400
Received: from swipnet.se (dialup87-2-7.swipnet.se [130.244.87.23]) 
          by mb07.swip.net (8.8.8/8.8.8) with ESMTP 
          id DAA20241; 
          Fri, 27 Aug 1999 03:51:13 +0200 (MET DST)
Message-ID: <37C5F04C.DF25154E@swipnet.se>
Date: Fri, 27 Aug 1999 03:56:28 +0200
From: David Olofson <audiality@swipnet.se>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-RTL_BETA12 i686)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: est@hyperreal.org
CC: Guenter Geiger <geiger@epy.co.at>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
References: <19990826183431.24261.qmail@hyperreal.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 76fe927811594748a61d73f2f5adce13

Well, things are really moving here! :-)

First, I have a few comments related to those Eric posted...

est@hyperreal.org wrote:
(...)
> * The whole thing should move to a class/instance paradigm so I can
>   instantiate multiple instances of a plugin.  Parameter descriptions
>   should be in the class and their values in the instance, etc.

Agree. Absolutely essential.

> * The only global defined by a plugin should be a uniquely named
>   function that returns a plugin class.  The idea here is to make it
>   possible to use static as well as dynamic linking.

Nope. For kernel modules, it only makes sense to export init_module()
and cleanup_module(), and init_module() has to
register_plugin(&audioeff_class) to tell the engine about the new class.
This eliminates name space conflicts, as no symbols are exported. Also,
a module/library can register multiple plug-in classes this way.

The registered audioeff_class should have a few callback functions,
including calls for creating and deleting instances.

> * String parameters should be provided for.

On the contrary, as much as possible of the not directly signal
processing related stuff should be kept *out* of the DSP part of the
plug-on spec. User interface stuff goes elsewhere, no matter if we're
dealing with a user space application, or the RTLinux Audiality engine.
Separation is good for stability. (You know what DirectX is like, right?
Let's not do it that way...)

> * We need a flag to say whether a parameter can be modified in between
>   any two calls to the process method as opposed to being settable only
>   for initizlization purposes.

Hmm... My plans are very different. I don't want parameters in the low
level plug-in spec at all. There should be only time stamped events and
data streams. Parameters are realized through an event based interface,
which means

1) Only one interface + subsystem for automation, MIDI-style
   events and system control events.

2) Events and parameter changes are independent of buffer sizes.

3) *Everything* can be defined in relation to real time.
   (A way for plug-ins to tell the engine which events they
   support, and their real time characteristics is needed.)

> * The number of channels per input and output signal should be a
>   plugin property vector.  Counts of frames and samples should be
>   clearly distinguished throughout.

IMHO, input and output signal should always be mono, because anything
else completely breaks the flexibility of free signal routing. Unless
you automatically throw in split/merge plugs where needed... I don't
think that's a good idea from the performance perspective.

OTOH, there might be a point in using multichannel bus formats for some
kinds of plug-ins, so supporting it isn't a bad idea. It can result in
faster code as long as everything fits nicely together.

> * The sample rate should be optionally settable at instance creation
>   time and the input and output buffer sizes should be optionally
>   settable per call to the process method.  I usually code in a way that
>   can accomodate this, but I agree that it's important to support less
>   flexible plugins as well.

The basic rule is that the engine gets to decides what sample rate to
use. Complex processing nets with plug-ins that have various smart ideas
about what sample rates to use just becomes a mess of lost quality and
CPU power...

> * To handle resampling, variable output buffer sizes are important.
>   It's also important that the process method can report how many output
>   frames it generated (is this the function of the return value of the
>   process method?).  It may even be important that the plugin can
>   be queried as to how many output frames *will* be generated to avoid
>   overruns due to disagreements about fencepost issues.

DO NOT adapt output buffer size to the inputs!!! It's doing it all
backwards.

This will not work in a low latency real time system, as there's no way
in h*ll to keep track of all plug-ins that happen to deliver a few
samples less than expected, and needs another call, which requires
another bunch of source data buffers to be generated
first,................... Forget it.

The algorithm is: "I need X samples. How many input samples do you need
for each channel?"

That's what this section of my little draft is for:

        int look_ahead;         /* Number of extra frames needed
                                 * after the end of input buffers.
                                 * Can be negative.
                                 */
        int skip_behind;        /* Number of frames skipped
                                 * at the start of input buffers.
                                 * (That is, inputs[n]+=look_behind
                                 * before process_XXX() is called.)
                                 * Can be negative.
                                 */

Either that, or sample rate and data format conversion cannot be done in
real time without extra latency and an incredibly stimulating complexity
in the engine.

> * The popup method should probably be expanded to a vector of generic
>   gui methods.

Nope. Drop it completely. There's no reason at all to have it in the
same file as the signal processing code. And you *CAN'T* unless you
restrict yourself to user space.

Besides, separating the GUI code from the processing code means that a
GUI crash doesn't even have to affect the signal processing - the GUI
process can just do an Explorer; that is, restart and hope the user
didn't notice... And you also get the bonus of knowing for sure what
part of your latest beta plug-in caused that crash after 3 hours of
correct operation while trying to reproduce that reported bug. And you
can skip the GUI code entirely and use a simple markup script to tell
the plug-in GUI engine what parameters there are, and how to display
them. No GUI code to port.

> * Memory allocation hooks are probably desirable.  That way I can get
>   a plugin to throw bad_alloc even if it know nothing about C++.

Yes, indeed. Also, it has to be strictly defined *when* you can allocate
and free memory, as it's not real time operations. It's possible to
design a fast, non fragmenting real time memory manager with a locked
memory pool for those who really need it, but dynamic allocation is
generally considered a no-no in hard real time systems. I'll have
something like that in the Audiality spec, but it's STRONGLY discouraged
for plug-ins to use it. It's an expensive resource...

Memory allocation/deallocation should be done in non real time context
as far as possible.


That's about what I have to say right now... I'll expand on my ideas for
the event passing/routing system later.


//David

From - Thu Aug 26 23:44:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA13437
	for <slinkp@ulster.net>; Thu, 26 Aug 1999 23:40:58 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA12227 for linux-audio-dev-list; Thu, 26 Aug 1999 22:56:07 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA12224 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 26 Aug 1999 22:56:04 -0400
Received: from swipnet.se (dialup88-5-8.swipnet.se [130.244.88.72]) 
          by mb05.swip.net (8.8.8/8.8.8) with ESMTP 
          id EAA22337; 
          Fri, 27 Aug 1999 04:53:08 +0200 (MET DST)
Message-ID: <37C5FA51.533CEBCC@swipnet.se>
Date: Fri, 27 Aug 1999 04:39:13 +0200
From: David Olofson <audiality@swipnet.se>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-RTL_BETA12 i686)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
CC: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] bytesex
References: <19990827011257.C312@cerealbox>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5006bb2288c4d2cfff5c6d293836071b

reactor/CTPmedia wrote:
> what should we do about bytesex? i want my program to run on every machine
> that has linux, not just on lousy 80x86s.

Code should work in the native format. Unless you do silly pointer
typecasting tricks, there's no need to worry about data formats except
when dealing with files and drivers. (That is, it's non-issue for signal
processing plug-ins.)

> a dude on irc said i should store my data in network format, using the
> system calls ntohl, ntohs, htonl, htons.

I'd say you should *store* data in the native format for preformance
reasons, but support reading of both formats to handle imported files.
The used endian format must of course, be indicated in the file headers!

OTOH, what I'm thinking about here is multitrack recording, where you
simply don't want to convert data on the fly for performance reasons -
the actual data chunks in files should be raw, and fit right into the
engine. It's not all that important when playing some single multimedia
file where the conversion takes .1% of your CPU time...

> i thought about that i should write (actually, rip out from Mikmod's source)
> specific filereading/writing routines for little and big endian machines.

Cool for data file portability, but rather pointless for writing
temporary/internal files from multimedia engines. Anyway, endian format
is defined in all (usable) standard file formats, so you kind of can't
miss it when writing read/write code for the. If you ever tried to code
a MOD file reader for x86, you should know what I mean... :-)


//David


From - Thu Aug 26 23:44:24 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA12768
	for <slinkp@ulster.net>; Thu, 26 Aug 1999 23:34:46 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA12232 for linux-audio-dev-list; Thu, 26 Aug 1999 22:56:12 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA12229 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 26 Aug 1999 22:56:09 -0400
Received: from swipnet.se (dialup88-5-8.swipnet.se [130.244.88.72]) 
          by mb05.swip.net (8.8.8/8.8.8) with ESMTP 
          id EAA22345; 
          Fri, 27 Aug 1999 04:53:10 +0200 (MET DST)
Message-ID: <37C5FE90.22A0AADB@swipnet.se>
Date: Fri, 27 Aug 1999 04:57:20 +0200
From: David Olofson <audiality@swipnet.se>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-RTL_BETA12 i686)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: est@hyperreal.org
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] we should use gtk objects for our plugins
References: <19990826202543.14078.qmail@hyperreal.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3cf9fc8da1150efd3142ec501638cd39

est@hyperreal.org wrote:
(...)
> Using the gtk object system for our plugins might be best of all.  It
> provides a C-based object system with wide use and multi-lingual
> support.  Note that gtk objects (as opposed to widgets) have nothing
> X-windows-specific about them.  I'm pretty sure this approach could be
> Audiality-friendly, for example.

As long as it means that we can have full control of memory allocation,
and make sure there are no system calls involved, yes, it could work
with Audiality. Everything that's declared *must* be explicitly provided
by the host, or we have no control over portability. (That is, no
portability.)

A hard real time environment will always be very different from a normal
environment, and a plug-in API for real time plug-ins must follow the
rules of real time programming for there to be any point with it. (That
the API might be possible to implement on the "structures & calls" level
in a certain environment isn't enough for real time.)

> Interested parties should look in particular at gtkobject.[ch],
> gtktypeutils.[ch] and gtkarg.[ch].  Doesn't it look like a plugin API?
> :)  We need only make a domain-specific sub-class.
> 
> What do you think?

Some interesting reading in there, but IMO, it's too complex as a
foundation for a real time audio plug-in system, while not specific
enough to help us very much. It's designed to handle the complete object
oriented complexity of GTK+, while we need little more than a single
level of classes and a basic way of handling instances. 

And BTW, no, I'd never consider C++ for DSP plug-ins. 90% of the C++
style OO features are far beyond what we need, and C++ style virtual
function calls generate slower code than C style OO. This becomes very
significant when buffers are 8 samples at 44.1 kHz, which you'll easily
get with Audiality real time mixing + monitoring, or within feedback
loops.

This also applies to the gtk stuff. Too many levels of indirection, and
too much complexity already, and we'd still have to add stuff.


I think we should do this from scratch, concentrating first of all on
getting good performance in the main data paths and the frequently used
subsystems. Then we could add extensions we need, as far as possible
without loading the main paths with conditionals and multiple
indirections. Flexibility is good, but if it costs too much, it's
pointless. The Linux kernel coding style rules.


//David

From - Fri Aug 27 00:14:50 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA16970
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 00:15:14 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA12311 for linux-audio-dev-list; Thu, 26 Aug 1999 23:29:47 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA12308 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 26 Aug 1999 23:29:44 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id XAA26429
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 26 Aug 1999 23:25:31 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id XAA22781; Thu, 26 Aug 1999 23:25:31 -0400 (EDT)
Date: Thu, 26 Aug 1999 23:25:29 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Timed Event Editor Framework
In-Reply-To: <Pine.LNX.4.10.9908211531230.433-100000@avix.localnet>
Message-ID: <Pine.GSO.4.10.9908262253440.22273-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5bf48039bff647eb8422072a25fa09e1

On Wed, 25 Aug 1999, Andreas Voss wrote:

> Also I think a single track-no is not powerful enough to structure a song.
> If you had a PhraseEvent (an event that can contain other events),
> arranging of a song (like intro, refrain etc) would be much easier. Also
> it would allow to have nested structure (e.g. notes in a chord in a phrase
> in a track in a song).

Here we come to the heart of our disagreement.  In my eyes, it is not the
job of a sequencer to impose structure on the song.  Certainly most songs
will have structure, but I feel that inherently the form of that structure
should be left up to the composer not the software. That's not to say you
couldn't have another program that used SMPTE/MTC to trigger the sequencer
to play phrases according to an algorithm, but the algorithm would exist
in the second program, not the sequencer.  This is what JMax does (at
least as far as I can figure out).

The sequencer itself thus remains a flat, structureless editor.  Let me
try to justify by analogy.  I propose that Photoshop is a more artistic
tool than the old Print Shop program.  Print Shop allows you to place
graphic elements on a page according to predefined structured layouts.  
If you want to use it to produce a poster in your own unique layout that
its designers didn't anticipate, you're out of luck.  Photoshop also lets
you place graphic elements on a page, but it doesn't provide you with any
predefined structure.  As such, it is harder to use than Print Shop, but
it does not suffer from the same limitations, and is thus the choice of
more artists.  If somebody created a third-party set of page layout
templates for Photoshop, these would fall under the category of that
"cooperative but external structure-adding tool" that would add the ease
of use back in, without sacrificing the artistic freedom.

If that example doesn't work for you, then compare Microsoft Word (suspend
your Microsoft hatred for a moment here) and LaTeX.  While LaTeX is
unarguably the better tool for producing a full-length book, I would argue
that it is much less artistic.  I don't say this because it lacks a GUI,
but rather because it is centered around imposing structure on your text.
Unless you fight rather hard against it, every document produced in LaTeX
tends to look just like every document that everybody who's ever used
LaTeX has produced.  This is not art.  (Using raw TeX rather than LaTeX is
a more artistic experience, but I don't know many people who do that.)

Basically, I don't mind algorithmic music, but I don't want a tracker, I
want a sequencer.  Why the most expensive commercial sequencers on the
market have been trying their hardest to turn into trackers is a mystery
to me.

> I agree that there is no "right" way to design a sequencer. If you want a
> pure midi editor, your approach is the way to go. If you want to support
> other musical concepts too, the flat midi event structure is probably not
> the best foundation for the internal structures of a sequencer.

I've tried Common Music.  I actually don't mind Lisp (heck, I can think in
Forth if I try hard enough), so that's no the problem, but it still always
feels like programming, not composing to me.  Left brain vs. right brain
thing.  I like sequencers on the right.

Div.

From - Fri Aug 27 00:14:52 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA17613
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 00:21:47 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA12343 for linux-audio-dev-list; Thu, 26 Aug 1999 23:47:36 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA12340 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 26 Aug 1999 23:47:34 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id XAA27279
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 26 Aug 1999 23:43:08 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id XAA23040; Thu, 26 Aug 1999 23:43:08 -0400 (EDT)
Date: Thu, 26 Aug 1999 23:43:06 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Good MIDI library?
In-Reply-To: <37C5ACBF.A8A03203@virginia.edu>
Message-ID: <Pine.GSO.4.10.9908262338140.22273-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 48155c4e57a1861f6a691835e1ca6b56

On Thu, 26 Aug 1999, David J. Topper wrote:

> I'm looking for a simple / robust MIDI parser written in C to plug into
> an interface package I'm working on.  I don't need something that does
> polling, I'm using GTK/GDK for that.  So what I really need to be able
> to do is feed the thing some MIDI bytes, then have it tell me what they
> are (eg., NOTE_ON, NOTE_OFF, PITCH_BEND) and so forth.

I'm presuming you mean streaming MIDI messages, rather than SMF files.
I have a little library for this which I used in my MIDI toys
(http://patriot.altavista-software.com/~div/xfr/).  It takes a somewhat
low level (not object oriented) approach, and is not "complete" because it
does not handle sysex events, but it works rather well.  It also has the
advantage of being extremely portable and not relying on anything except
the standard C library.  Plus, it's public domain, so feel free to munge
it up however you like.

Div.

From - Fri Aug 27 00:33:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA19183
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 00:40:27 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA12357 for linux-audio-dev-list; Thu, 26 Aug 1999 23:51:36 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA12354 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 26 Aug 1999 23:51:34 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id XAA27518
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 26 Aug 1999 23:47:58 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id XAA23128; Thu, 26 Aug 1999 23:47:58 -0400 (EDT)
Date: Thu, 26 Aug 1999 23:47:56 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] bytesex (and dynamic loading reference)
In-Reply-To: <19990826234514.29055.qmail@hyperreal.org>
Message-ID: <Pine.GSO.4.10.9908262344540.22273-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b80f755f0d34b8789161e441badfd91f

On Thu, 26 Aug 1999 est@hyperreal.org wrote:

> Also, you were asking about dynamic loading.  See the dlopen(),
> dlsym(), etc man pages.

If my experience in Digital Unix (aka OSF1, Tru64 Unix) translates over to
Linux, then this is a truly nasty thing to have to deal with.  To avoid
problems in all but the simplest of cases, use dlsym() and avoid the
automatically-resolving dlopen()!

Div.

From - Fri Aug 27 00:53:57 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA20137
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 00:53:42 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA12409 for linux-audio-dev-list; Fri, 27 Aug 1999 00:15:37 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA12406 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 00:15:34 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id AAA28730
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 00:11:29 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id AAA23473; Fri, 27 Aug 1999 00:11:29 -0400 (EDT)
Date: Fri, 27 Aug 1999 00:11:27 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Timed Event Editor Framework
In-Reply-To: <199908251552.LAA09184@ginette.musique.umontreal.ca>
Message-ID: <Pine.GSO.4.10.9908262358320.22273-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ba559b0e2b859738044c34ff4282d1aa

On Wed, 25 Aug 1999, Eli Brandt wrote:

> > I take issue with this.  In CSound you specify all parameters for a note a
> > the time that it is fired.  In MIDI, you add or modify parameters over
> > time after the note has been fired.
> 
> That's a conceptual bug in Csound that IMO should be patched over --

Actually, I see advantages in both methods.  The MIDI way is certainly
more appropriate for realtime, but Csound's approach makes many things in
synthesis much easier (or even possible).  For instance, try designing a
MIDI-controlled sound that crescendos linearly from zero volume at note-on
to maximum volume at note-off.  Impossible unless you can predict the
future.  I guess both MIDI and Csound use models that are well-tailored to
their respective original purposes.
 
> CAL is far too badly designed to be used as a warning against any
> particular design approach. :-)  

Good point.  Don't throw out the baby with the bathwater.

> Seems to me it's easier to ignore
> structure than it is to add it in after the fact.  Say something like
> 
> function delay_each_track(merged_tracks) =
>         for each_track in merged_tracks, 
>                 for each event e in each_track,
>                         old_e.time = e.time;  output old_e
>                         old_e = e
> 
>         vs.
> 
> function delay_each_track(merged_tracks) =
>         for each event e in merged_tracks,
>                 old_e[e.track].time = e.time;  output old_e[e.track]
>                 old_e[e.track] = e
> 
> Okay, the difference is not dramatic here, but as I start wanting more
> and more temporal structure, it can either go in the data typing, or
> I the programmer have to write code that parallels and maintains it by
> hand.

I understand what you're saying, but I can't think of an example where the
difference _would_ be dramatic.  It comes out about even each way --
sometimes merged is more useful, sometimes separate.  Please prove me
wrong, so I can make a good decision.

Div.

From - Fri Aug 27 01:14:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA21820
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 01:18:53 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA12437 for linux-audio-dev-list; Fri, 27 Aug 1999 00:41:46 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id AAA12434 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 00:41:44 -0400
From: est@hyperreal.org
Received: (qmail 29265 invoked by uid 162); 27 Aug 1999 04:38:51 -0000
Message-ID: <19990827043851.29264.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] bytesex (and dynamic loading reference)
In-Reply-To: <Pine.GSO.4.10.9908262344540.22273-100000@ux02.CS.Princeton.EDU>
 from David Slomin at "Aug 26, 1999 11:47:56 pm"
To: David Slomin <dgslomin@CS.Princeton.EDU>
Date: Thu, 26 Aug 1999 21:38:51 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 575a0402d87bbd005bb56a9b22af84c2

David Slomin discourseth:
> On Thu, 26 Aug 1999 est@hyperreal.org wrote:
> 
> > Also, you were asking about dynamic loading.  See the dlopen(),
> > dlsym(), etc man pages.
> 
> If my experience in Digital Unix (aka OSF1, Tru64 Unix) translates over to

Hmm..it may not, because..

> Linux, then this is a truly nasty thing to have to deal with.  To avoid
> problems in all but the simplest of cases, use dlsym() and avoid the
> automatically-resolving dlopen()!

..as far as I know you can't use dlsym() on Linux without first using
dlopen().

Eric

From - Fri Aug 27 11:40:05 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA29468
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 10:36:07 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA13163 for linux-audio-dev-list; Fri, 27 Aug 1999 09:53:21 -0400
Received: from sculpcave.localdomain (cvx-1-131.dyn.nic.fi [62.236.97.131]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA13160 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 09:53:17 -0400
Received: (from root@localhost)
	by sculpcave.localdomain (8.8.7/8.8.7) id JAA05591;
	Fri, 27 Aug 1999 09:10:05 +0300
Date: Fri, 27 Aug 1999 09:10:04 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
To: David Olofson <audiality@swipnet.se>
cc: est@hyperreal.org, Guenter Geiger <geiger@epy.co.at>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
In-Reply-To: <37C5F04C.DF25154E@swipnet.se>
Message-ID: <%Vqhx3g0fN@sculpcave>
X-User-Agent: Mana 4.0beta (Linux)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ea4b6ad429720ed293df5366e478f620

On Fri, 27 Aug 1999, David Olofson wrote:

> Hmm... My plans are very different. I don't want parameters in the low
> level plug-in spec at all. There should be only time stamped events and
> data streams. Parameters are realized through an event based interface,
> which means

I've used a simple number_of/name_of/set/get_parameter approach in 
ecasound and it sure is far from perfect. The biggest problem
has been to find a good balance of efficiency, flexibility and precision.
One solution works when parameters are controlled by a GUI knob, 
but when you want to use high-frequency oscillators as controllers,
things change. If you can get all necessary info about supported 
events straight from the plugin object, event based system might 
do the job. 

> IMHO, input and output signal should always be mono, because anything
> else completely breaks the flexibility of free signal routing. Unless
> you automatically throw in split/merge plugs where needed... I don't
> think that's a good idea from the performance perspective.

This is also a difficult decision. I chose to use stereo-signals.
>From musicians standpoint, this is the way to go as many effects 
(reverbs, delays, panning, etc) work best when used in a stereo 
context. And I don't think I'll be doing multi-channel mixes of 
my music any time soon... 

-- 
Kai Vehmanen ----------------------------- CS, University of Turku, Finland
 : email                                 mailto:kaiv@wakkanet.fi
 : audio processing for linux            http://www.wakkanet.fi/ecasound/
 : my music (ambient-idm-rock-...mp3/ra) http://www.wakkanet.fi/sculpscape/


From - Fri Aug 27 11:40:07 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA29490
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 10:36:11 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA13158 for linux-audio-dev-list; Fri, 27 Aug 1999 09:52:12 -0400
Received: from sculpcave.localdomain (cvx-1-131.dyn.nic.fi [62.236.97.131]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA13155 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 09:52:08 -0400
Received: (from root@localhost)
	by sculpcave.localdomain (8.8.7/8.8.7) id JAA05599;
	Fri, 27 Aug 1999 09:18:31 +0300
Date: Fri, 27 Aug 1999 09:18:31 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
To: David Olofson <audiality@swipnet.se>
cc: est@hyperreal.org, linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] we should use gtk objects for our plugins
In-Reply-To: <37C5FE90.22A0AADB@swipnet.se>
Message-ID: <%bvix3g0fO@sculpcave>
X-User-Agent: Mana 4.0beta (Linux)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0589fc691861eb328182185ac3d165ab

On Fri, 27 Aug 1999, David Olofson wrote:

[gtkoject, gtktypeutils]
> Some interesting reading in there, but IMO, it's too complex as a
> foundation for a real time audio plug-in system, while not specific
> enough to help us very much. It's designed to handle the complete object

And hard-realtime or not, this plugin-interface shouldn't get 
too complex. If this happens, the resulting interface won't
be adopted by the majority of application/plugin developers. 

-- 
Kai Vehmanen ----------------------------- CS, University of Turku, Finland
 : email                                 mailto:kaiv@wakkanet.fi
 : audio processing for linux            http://www.wakkanet.fi/ecasound/
 : my music (ambient-idm-rock-...mp3/ra) http://www.wakkanet.fi/sculpscape/


From - Fri Aug 27 11:39:51 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA03325
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 06:32:10 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA12838 for linux-audio-dev-list; Fri, 27 Aug 1999 05:48:01 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA12835 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 05:47:57 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m11KIat-000dyjC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Fri, 27 Aug 1999 11:46:47 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Fri, 27 Aug 1999 11:46:47 +0200 (CEST)
To: est@hyperreal.org
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] we should use gtk objects for our plugins
In-Reply-To: <19990826202543.14078.qmail@hyperreal.org>
References: <19990826194018.6740.qmail@hyperreal.org>
	<19990826202543.14078.qmail@hyperreal.org>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14278.23876.691502.98348@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 5db8a489a5d0662e75ef7e826dc603e7

est@hyperreal.org writes:
 > OK, people..considering I'm now replying to myself replying to myself, I'm
 > probably losing it. :)
 > 
 > est@hyperreal.org discourseth:
 > > est@hyperreal.org discourseth:
 > > >
 > > > * Use uint32_t instead of u_int32_t for POSIX 1.g compatibility.
 > > 
 > > Come to think of it, including glib.h and using guint32 etc might be
 > > even better.
 > 
 > Using the gtk object system for our plugins might be best of all.  It
 > provides a C-based object system with wide use and multi-lingual
 > support.  Note that gtk objects (as opposed to widgets) have nothing
 > X-windows-specific about them.  I'm pretty sure this approach could be
 > Audiality-friendly, for example.
 > 
 > Interested parties should look in particular at gtkobject.[ch],
 > gtktypeutils.[ch] and gtkarg.[ch].  Doesn't it look like a plugin API?
 > :)  We need only make a domain-specific sub-class.
 > 
 > What do you think?

 Actually I rather agree with David in this point. In the first place
I considered using glib too, but I guess it's not too hard to build
the parts we need from scratch, we could snap some ideas from glib, but for a
generally usable API depending on a library that specific is no good IMO.

Guenter

From - Fri Aug 27 11:39:53 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA04031
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 06:45:15 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA12850 for linux-audio-dev-list; Fri, 27 Aug 1999 05:57:12 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA12847 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 05:57:09 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m11KIjy-000dyjC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Fri, 27 Aug 1999 11:56:10 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Date: Fri, 27 Aug 1999 11:56:10 +0200 (CEST)
To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Mix with plugins
In-Reply-To: <19990827010806.B312@cerealbox>
References: <14277.1416.415452.457000@gige>
	<19990827010806.B312@cerealbox>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14278.24635.922050.896294@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id GAA04031
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 687d3241ceb0a8e5b09387494cda2502

reactor/CTPmedia writes:
 >  >% The sources are accessible via anonymous CVS:
 > 
 > can't i simply download 'em somewhere? i don't have any kind of cvs stuff
 > here at home :)

 I planning to create regular snapshots, for the time being
 look at <ftp://iem.mhsg.ac.at/pd/GIGE>
 to download strummin and mix.

 > 
 > and i still can't see how the plugin system could be done through shared
 > libraries. could anyone enlight me about the system calls to read/use
 > shared libraries' functions?
 > 
 > bye!
 >  
 > -- 
 > 
 >   M-Bt Rcz a.k.a. reactor  -  http://linux.gyakg.u-szeged.hu/~reactor/-A
 >    CTP media - since 1995   -  http://ctpmedia.scene.hu/
 > 
 > 

From - Fri Aug 27 11:39:54 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA06940
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 07:32:59 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA12921 for linux-audio-dev-list; Fri, 27 Aug 1999 06:53:08 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA12918 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 06:53:05 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m11KJc4-000dyjC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Fri, 27 Aug 1999 12:52:04 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Fri, 27 Aug 1999 12:52:04 +0200 (CEST)
To: est@hyperreal.org
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
In-Reply-To: <19990826183431.24261.qmail@hyperreal.org>
References: <14277.1416.415452.457000@gige>
	<19990826183431.24261.qmail@hyperreal.org>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14278.24830.37098.474541@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 15b9c163dcb04d66e6b9acf91935ce0f

est@hyperreal.org writes:
 > Guenter Geiger discourseth:
 > Note that these suggestions take the contents of the strummin
 > directory as their context.  Many of my suggestions may be based on
 > ignorance or misunderstandings.
 > 

 Go ahead and beat me ... I like it :) 

 > * The whole thing should move to a class/instance paradigm so I can
 >   instantiate multiple instances of a plugin.  Parameter descriptions
 >   should be in the class and their values in the instance, etc.
 > 

 Agreed, I only realized the problem when I was heavily hacking mix
 again ... as a quick hack I was about to implement a clone()
 function.
 The idea with that was, that the new functions of any plugin sets
 the default values after cloning.
 

 > * The only global defined by a plugin should be a uniquely named
 >   function that returns a plugin class.  The idea here is to make it
 >   possible to use static as well as dynamic linking.
 > 

 .. hmmm seems to make sense .. 

 > * Change properties to a * int32_t to avoid binary compatibility concerns.
 > 
 > * Change sparebytes to a void * for the same reason.

 Yep, dynamic allocation, but then, if we want to access (some later added)
 properties we always have to check if the plugin has allocated memory 
 for them. In the current case we just get back a default value.
 Of course, now we can only extend the properties until we have
 reached MAXPROPERTIES.


 > 
 > * Change the prefix to something other than `st_' which has too much
 >   history in unix.  A three-character prefix would be much safer.
 > 

 Agreed too, stm_ probably, I'm open to better names for the API too, 
 strummin doesn't sound very professional, I just thought it's funny.
 

 > * Use uint32_t instead of u_int32_t for POSIX 1.g compatibility.
 >
 
 changed immediately
 
 > * The param/type field needs some definition and should have an enum
 >   type.
 > 
 > * We want to be able to say that a param must be integral.
 > 
 > * There should be a parameter default value field along with a flag so
 >   say whether it's valid.
 > 
 > * String parameters should be provided for.
 > 
 > * We need a flag to say whether a parameter can be modified in between
 >   any two calls to the process method as opposed to being settable only
 >   for initizlization purposes.
 > 

 We should discuss parameters separetely ....


 > * The number of channels per input and output signal should be a
 >   plugin property vector.  Counts of frames and samples should be
 >   clearly distinguished throughout.
 > 

 Basically I'd like to have each channel on a seperate input.           
 We have to set some restrictions, as through flexibility we 
 will make it harder to write applications for the plugins,
 and introduce too much incompatibility.


 > * The sample rate should be optionally settable at instance creation
 >   time and the input and output buffer sizes should be optionally
 >   settable per call to the process method.  I usually code in a way that
 >   can accomodate this, but I agree that it's important to support less
 >   flexible plugins as well.

 It's possible to set these things whenever you like.
 The plugin programmer can decide which properties can be changed,
 and which not. That's what the virtual verify function is all about.

 > 
 > * To handle resampling, variable output buffer sizes are important.
 >   It's also important that the process method can report how many output
 >   frames it generated (is this the function of the return value of the
 >   process method?).  It may even be important that the plugin can
 >   be queried as to how many output frames *will* be generated to avoid
 >   overruns due to disagreements about fencepost issues.
 > 

 Isn't it enough to have different sizes for input and output buffers ?
 Yes, the return value of process is the number of samples created.
 (Note: I'd like to avoid frames, we could add a data format for
 interleaved stereo data, though). 


 > * The popup method should probably be expanded to a vector of generic
 >   gui methods.
 > 

 As few as possible, but right, we may need more ..... 

 > * Memory allocation hooks are probably desirable.  That way I can get
 >   a plugin to throw bad_alloc even if it know nothing about C++.
 > 

 Generally, I'm open to give write access to the CVS to whomever likes.
 I'm accepting patches too, of course. The first thing we have to
 agree upon is the API itself. Internal concepts can be implemented
 and tested after that.
 

 The application can decide which kind of plugins it will support.
 Audiality may probably only support plugins which claim to be
 realtime, whereas some other applications don't care about that.
 
 The API should be flexible enough for plugin programmers to implement 
 their ideas, but keeping them to certain contraints.
 
 Guenter

 

From - Fri Aug 27 11:39:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA07384
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 07:39:44 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA12927 for linux-audio-dev-list; Fri, 27 Aug 1999 06:54:52 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA12924 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 06:54:49 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m11KJdm-000dyjC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Fri, 27 Aug 1999 12:53:50 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Fri, 27 Aug 1999 12:53:49 +0200 (CEST)
To: "David J. Topper" <topper@virginia.edu>
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Good MIDI library?
In-Reply-To: <37C5ACBF.A8A03203@virginia.edu>
References: <37C5ACBF.A8A03203@virginia.edu>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14278.28139.816685.937488@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 65c7a838931eee4e95df874db3870718

David J. Topper writes:
 > Hi folks,
 > 
 > I'm looking for a simple / robust MIDI parser written in C to plug into
 > an interface package I'm working on.  I don't need something that does
 > polling, I'm using GTK/GDK for that.  So what I really need to be able
 > to do is feed the thing some MIDI bytes, then have it tell me what they
 > are (eg., NOTE_ON, NOTE_OFF, PITCH_BEND) and so forth.
 > 
 > Thanks all,
 > 
 > Dave Topper
 > --
 > Technical Director, Virginia Center for Computer Music
 > http://www.people.virginia.edu/~djt7p
 > 

I'm using Winfried Ritsch's midi library within mix. It provides
callbacks for any messages you like (I need it for MTC there).

Guenter 

From - Fri Aug 27 11:39:58 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id IAA10840
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 08:19:01 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id HAA12997 for linux-audio-dev-list; Fri, 27 Aug 1999 07:31:55 -0400
Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA12994 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 07:31:51 -0400
Received: from hendrix (kenny44.zip.com.au [61.8.18.172])
	by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id VAA05313;
	Fri, 27 Aug 1999 21:17:09 +1000 (EST)
Message-ID: <37C67653.68F376C4@zip.com.au>
Date: Fri, 27 Aug 1999 21:28:19 +1000
From: Erik de Castro Lopo <erikd@zip.com.au>
Organization: Eric Conspiracy Secret Labs
X-Mailer: Mozilla 3.04Gold (X11; I; Linux 2.2.11 i586)
MIME-Version: 1.0
To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] bytesex
References: <19990827011257.C312@cerealbox>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 27f61ac937e0da7b19b59673c3b3aec7

reactor/CTPmedia wrote:
> 
> yo!
> 
> what should we do about bytesex? i want my program to run on every machine
> that has linux, not just on lousy 80x86s.

This has been covered to some extent by others, but I thought I'd
add my $0.02 worth.

My little project (http://www.zip.com.au/~erikd/libsndfile) 
will soon have some publically available functions named 
something along the lines of :

void    sf_sc2s_array  (signed char *buffer, short *ptr, unsigned int count) ;
void    sf_uc2s_array  (unsigned char *buffer, short *ptr, unsigned int count) ;
void    sf_bet2s_array (tribyte *buffer, short *ptr, unsigned int count) ;
void    sf_let2s_array (tribyte *buffer, short *ptr, unsigned int count) ;
void    sf_bei2s_array (int *buffer, unsigned int count, short *ptr, unsigned int count) ;
void    sf_lei2s_array (int *buffer, short *ptr, unsigned int count) ;
void    sf_f2s_array   (float *buffer, short *ptr, unsigned int count) ;
...............
.........
....

Basically, all the bytesex and sample width conversion routines that
are useful within libsndfile will be exposed for general use. I will
also be exposing similar functions for ulaw and Alaw encoded data.

Cheers,
Erik
-- 
+-------------------------------------------------+
     Erik de Castro Lopo     erikd@zip.com.au
+-------------------------------------------------+
A sufficiently advanced programming error is
indistinguishable from the Windows 95 Operating System.

From - Fri Aug 27 11:40:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA30740
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 10:44:38 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA13192 for linux-audio-dev-list; Fri, 27 Aug 1999 10:02:09 -0400
Received: from cygnus.com (runyon.cygnus.com [205.180.230.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA13189 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 10:02:06 -0400
Received: from cygnus.com (thudson1.cygnus.com [205.226.144.45])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id GAA05023;
	Fri, 27 Aug 1999 06:58:51 -0700 (PDT)
Message-ID: <37C6999A.CD6996B@cygnus.com>
Date: Fri, 27 Aug 1999 09:58:50 -0400
From: Thomas Hudson <thudson@cygnus.com>
Organization: Cygnus Solutions
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "David J. Topper" <topper@virginia.edu>
CC: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Good MIDI library?
References: <37C5ACBF.A8A03203@virginia.edu>
Content-Type: multipart/mixed;
 boundary="------------C2929BEDD8D535B61AC766CA"
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 92d53032df8b2217e517e35bd4910a23

This is a multi-part message in MIME format.
--------------C2929BEDD8D535B61AC766CA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"David J. Topper" wrote:
> I'm looking for a simple / robust MIDI parser written in C to plug into
> an interface package I'm working on.  I don't need something that does
> polling, I'm using GTK/GDK for that.  So what I really need to be able
> to do is feed the thing some MIDI bytes, then have it tell me what they
> are (eg., NOTE_ON, NOTE_OFF, PITCH_BEND) and so forth.
> 
Well, it's not in C, but I a class in C++ that could easily be 
converted to C. It does exactly what you want. It handles all
midi messages including SysEx and SysCommon. It is loosely
based on the BeOS midikit. 

Just hack off the OO ;-). Actually, just steal the parseMidi routine.
The start of the routine grabs the next available byte. Within this
routine you will see calls like:

SpraySystemExclusive(...)
SprayNoteOn(...)
etc.

These are the "delivery" routines for each parsed message.
Simply insert functions for the messages you are interested
in.

Thomas
--------------C2929BEDD8D535B61AC766CA
Content-Type: application/x-gzip;
 name="midi-parser.tar.gz"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="midi-parser.tar.gz"

H4sICFeXxjcCA21pZGktcGFyc2VyLnRhcgDtWG1P20gQ5iv+FSNO6iWQg4TXHoHqQhogKnlR
ElShCkWOvU5WtXcj7xrIRfnvN7vr2CYFWtSjUiWv7oqz3pl55pnZ2fW0qEu7dihIuLP2VgP2
y0dHB7AGAEeH+4/+xqMMcHh0WDmo7B1U8Lmyu39QWYODtV8wIiHtEGBNTiJXcPbsuu+9/01H
K41/+rjtOP+njUq5fLgS92z8j3YP0vjvYaKAesD4l/P4v/nY2YS/Nv8CZ2tL/bVgE/8DuCCM
hLZP/yUutJofmzA1eQFXnAviz2BkC3zFGZyRTh8c3xaCiG0tW+fTWUjHEwkFpwijGQwmPLAF
XGr+4CQm8h9nNmaR2HZ48GFpFpdSAdOQj0M7AHz0QkJAcE/e2yGpwoxH4NgMQuJSIUM6iiQB
KsFm7g4PIeAu9WZGE85GzCUhyAkBScJAAPf0j4v29dI/6EYjnzpwRR3CBAFEOVUzYoLOjWJN
SuZc4ejHOOCco2pbUs6qQCi+D+GOhAJ/w+7SSqyyBDw0agq2VPhD4FMlWUTQM/BtmQpvP0tD
6q0LlGn9Ez5FvyaoFD29p74PIwKRIF7kl4wSXA6fm4PLzvUAau0b+Fzr9WrtwU0Vl8sJx7fk
jhhlNJj6FHWjd6HN5AydMDpajV79EoVqZ82r5uAGnYHz5qDd6PfhvNODGnRrvUGzfn1V60H3
utft9BvbAH2ioBGj4gW6PR0zJNQl0qa+SAm4wUALxOi7MLHvCAbcIfQOEdrgYHp9P5RGje1z
Ntbu4vKU0ipQDxiXJbgPKWaQ5N8G2ShII12CJnO2S1imDqCF2Q61Owxu3Q5GIXXH+NiqQXm3
svd3Ca77tdiTHesPyhw/cglsZKrrZCOdPxHS9eloe/IhM0c5xpvYgZq1UsHj4/S5ULQAjmEY
RoxRNh5iFZORKJSLJRiKmSAPQ4G7t3BQ2S2CNQdcHE+PIg9OoRA5EzvcLEJg+z53ChmZYhWs
hWXdcYp7P2NblwA1gabnqE9rAEYeJOpDtO7ZTJJCsYqvkN4CFX0DSa0oKrQAc8tU/J0daHpw
n8QVw4r2JQmUHl/SAPnEtxguhyDVNAhww+NWwcKDWz1VglFjmBBMUhYRE2eV14yHyq0ZCAc3
cuRj3sSRD5CqWDzGqM320OoArS6xrvenoT174l2p3fmMHqYI+kTq3NH0gefbY5VN6kiRIOw7
NAeYPzYWE6nrox7Ex+TP2m88YOAFEpEAGFJmQoLcyjAiWZs1LBxcVx2MAGPElGmTANpQxoy1
PrfWtVRPU60AqcKTWR3rwlrCAOEs/dVFkzJkXcQabDBoIYELAYbHHhO1QPmToC6qGSwEKY2p
i2keloaKm6GDm0wiqyii/l9JaSRA59g7KD945aomHYvhFGuAtyRAi8XP2fVlz6xXJWT5Gn3V
eDO2UcQo7hGB8dQB0y+s9YXmUv2rg4ZrknA+yuhV7+cJJenGgtPTrNWYo7n5A9ltC5unsFtd
efF446qNktm4ms3sHjbCC+1psuRLxvzW1m1MVXXp5mrK1Fw3dVflNarwMFVwDyKdxPlqWBK6
kBPbmSzzAeRsmiH5Jcsm5gL3LooXVmL/mCIH7xzQ7gwaw077eEmO5jgbSmQOxZQP63ECtrkk
HVZYJkgpBVW+zfyo3CrWnsgMnFwszY2Q969JZL7BdX7+amCe98bIPjVuht0eHtnXvcZr0H0i
s26I8YxC8sYI6532oNe5GqqrxsWrMNax9ofcryO68Vuj7PY6F71a6wdQVlZQds3h8xLKn6IP
AbUbVz8U5FVodYPl5UD/FGvNQf1yeNZof3xNXLuqHJwR5r5xTPs3/UEDQ9pptbCmrD+H8CmI
5lir8yDgbLVu4eGT4IZngO++APypQ/BJj8xPl3h25MtjVbPNrZn9KWGMR9nysNMOq6vRyQls
9JcqN9TPFUtVNYfE+wldqrgXKIKj5pykcJLFXIWtLaq4SfTrM+OLVk71xG1iK/Ge3mbsrC9j
8jhSi/T4XVhr+fiF/Z/J2i/s/+weHh1m+j9Hqv9TLu/n/Z+8/5P3f/L+z2/d/3m50aObQh+J
J1RLSH0z4UmOaSvomBH1iYWFSX/u4UGvt1imH2PNLZ2qzrGljnYmZNyQwXtJ40E1YbK9IvX7
joYyQqLMsrRhY051tUB1fDJdHrSKhEniYNodJw2f1ftC+iK+8SQzm5kvT90VwjtE9uKAUyPO
fUi+m9WM+nodyuzHcMZCcn3Yu9UNES2eNJrMIvWtWoQ5OiijkJlPV9ULeI9OLlKZ+OLbMh+s
L8iexH2HjOxqR+N5Ybw3PiOdtJWeFC5o6Q9a+n0R3r2LZ070jFdUCq1FNb8V5SMf+chHPvKR
j3zkIx/5eMX4D55ky8MAKAAA
--------------C2929BEDD8D535B61AC766CA--

From - Fri Aug 27 11:45:16 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA08170
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 11:48:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA13283 for linux-audio-dev-list; Fri, 27 Aug 1999 10:59:02 -0400
Received: from gauss.deltav.hu (gauss.deltav.hu [194.9.64.225]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA13280 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 10:58:53 -0400
Received: from cerealbox (103.dial02.deltav.hu [194.9.64.103])
          by gauss.deltav.hu (Netscape Messaging Server 3.6)  with ESMTP
          id AAA1611 for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Fri, 27 Aug 1999 16:58:57 +0200
Received: from reactor by cerealbox with local (Exim 1.92 #1 (Debian))
	id 11KNVf-00004B-00; Fri, 27 Aug 1999 17:01:43 +0200
Message-ID: <19990827170143.B237@cerealbox>
Date: Fri, 27 Aug 1999 17:01:43 +0200
From: reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] problems with plugins?
Reply-To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.91.2
Organization: CTP media laboratories
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8003
X-Mozilla-Status2: 00000000
X-UIDL: bf5373eea5669413898a64728af63f90

yo!

i just thought about it all. is it even possible to make studio-sounding
very-hi-fi stuff in realtime, with software? just take a look at Cooledit's
reverberation. on my p200, it takes 5 seconds to reverb some 2-second wave.
i know there are 1000 GHz pentium3s nowadays, but but but... :)

and if a realtime reverb plugin doesn't sound like a Lexicon, should we
bother using it? (well, i don't have money for Lexicon, that's why i'm
using pc with soundcards :))

i believe in non-realtime music-making. currently i'm in the final state
of planning my tracker that uses Csound to make the actual sound, and
it would be semi-realtime. i mean, if you pressed "play pattern", it'd
calculate your pattern to a wav and play it :) (actually "csound -odevaudio"
should/will work well, but what if the cpu power is just not enough...)


anyway, "effects" are simply non-realtime plugins? :)

-- 

  Mt Rcz a.k.a. reactor  -  http://linux.gyakg.u-szeged.hu/~reactor/
   CTP media - since 1995   -  http://ctpmedia.scene.hu/

From - Fri Aug 27 12:09:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA11534
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 12:08:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA13316 for linux-audio-dev-list; Fri, 27 Aug 1999 11:05:37 -0400
Received: from gauss.deltav.hu (gauss.deltav.hu [194.9.64.225]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA13313 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 11:05:34 -0400
Received: from cerealbox (107.dial02.deltav.hu [194.9.64.107])
          by gauss.deltav.hu (Netscape Messaging Server 3.6)  with ESMTP
          id AAA1C63 for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Fri, 27 Aug 1999 17:05:49 +0200
Received: from reactor by cerealbox with local (Exim 1.92 #1 (Debian))
	id 11KNcJ-00004Z-00; Fri, 27 Aug 1999 17:08:35 +0200
Message-ID: <19990827170835.C237@cerealbox>
Date: Fri, 27 Aug 1999 17:08:35 +0200
From: reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] ftp problem
Reply-To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.91.2
Organization: CTP media laboratories
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 4a75c66623ad4a717286df9985a90fa4

[17:08:02] [root@cerealbox] [~] lynx ftp://iem.mhsg.ac.at/pd/GIGE

Looking up iem.mhsg.ac.at.
Making FTP connection to iem.mhsg.ac.at.
Can't Access ftp://iem.mhsg.ac.at/pd/GIGE'
...
Alert!: Unable to access document.
lynx: Can't access startfile


so? :)

-- 

  Mt Rcz a.k.a. reactor  -  http://linux.gyakg.u-szeged.hu/~reactor/
   CTP media - since 1995   -  http://ctpmedia.scene.hu/

From - Fri Aug 27 12:49:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA17794
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 12:51:41 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA13366 for linux-audio-dev-list; Fri, 27 Aug 1999 11:53:00 -0400
Received: from cygnus.com (runyon.cygnus.com [205.180.230.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA13363 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 11:52:57 -0400
Received: from cygnus.com (thudson1.cygnus.com [205.226.144.45])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id IAA12398
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 08:50:00 -0700 (PDT)
Message-ID: <37C6B3A7.C2EA8BF8@cygnus.com>
Date: Fri, 27 Aug 1999 11:49:59 -0400
From: Thomas Hudson <thudson@cygnus.com>
Organization: Cygnus Solutions
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] YARTL
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: dcf7d0132dea2d3ded8452a9629a6c2c


I thought I knew about every linux port and realtime linux effort. But
I found a new one called QLinux. This looks promising as the musicians
linux: 

QLinux: A QoS enhanced Linux Kernel for Multimedia Computing 
http://www.cs.umass.edu/~lass/software/qlinux/

--begin quote
QLinux is a Linux kernel that can provide quality of service guarantees. 
QLinux, based on the Linux 2.2.x kernel, combines some of the latest 
innovations in operating systems research. It includes the following features: 

      Hierarchical Start Time Fair Queuing (H-SFQ) CPU scheduler 
      Hierarchical Start Time Fair Queuing (H-SFQ) network packet scheduler 
      Lazy receiver processing (LRP) network subsystem 
      Cello disk scheduling algorithm [not stable yet] 
--end quote

I found it on a page that lists linux ports:
http://www.ctv.es/USERS/xose/linux/linux_ports.html

Thomas

From - Fri Aug 27 12:49:34 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA18118
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 12:53:43 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA13385 for linux-audio-dev-list; Fri, 27 Aug 1999 11:57:13 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA13381 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 11:57:10 -0400
Received: from ulster.net (port82.king.ulster.net [208.242.160.83])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id MAA11645;
	Fri, 27 Aug 1999 12:09:08 -0400
Message-ID: <37C6B648.31F203D3@ulster.net>
Date: Fri, 27 Aug 1999 12:01:12 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
CC: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] problems with plugins?
References: <19990827170143.B237@cerealbox>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 596db7bb20ae20507fd33199dce9ed0e

reactor/CTPmedia wrote:
> 
> yo!
> 
> i just thought about it all. is it even possible to make studio-sounding
> very-hi-fi stuff in realtime, with software? just take a look at Cooledit's
> reverberation. on my p200, it takes 5 seconds to reverb some 2-second wave.

Depends on the algorithm.. Reverbs have traditionally been very
compute-intensive and slow. So you do what csounders have always done...
preview at lower resolution to speed things up, and/or substitute a
faster, simpler (and worse-sounding) effect until final rendering.

And don't discount those 1000MHz P3's... in five years I'll bet they're
pretty cheap. 


----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Fri Aug 27 14:59:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA03921
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 14:59:22 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA13567 for linux-audio-dev-list; Fri, 27 Aug 1999 14:06:01 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id OAA13564 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 14:05:54 -0400
From: est@hyperreal.org
Received: (qmail 2659 invoked by uid 162); 27 Aug 1999 18:02:54 -0000
Message-ID: <19990827180254.2658.qmail@hyperreal.org>
Subject: [linux-audio-dev] My Hopes for an Open Plugin Specification
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Fri, 27 Aug 1999 11:02:54 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 3ef393c0d767c2f90355eba0463cd094

Hello, people,

First of all, I hope more people will participate in the dialog. :)

My personal hopes for an open plugin specification are based on
frustration with the current situation.  There's a *lot* of existing
code out there.  Usually when I want to use a piece of code for my
purposes, I have to hack it up a little.  I'd much rather hack it up
to a common specification so that everyone can use it.  Similarly for
the code I write (or that my programs write :)  I suspect most coders
here can empathize with this.

This means I want a specification that can accomodate most of the code
out there that I'll probably end up using and most of the code that
I'll end up writing.  I hope other people's needs will be accomodated
as well.  This means that the specification should accomodate styles
and paradigms that I don't plan on using and may even find
distasteful.

There's an incredible variety of approaches and concerns with respect
to audio software on this list.  If someone really wants a feature in
the plugin specification, I think it should go in unless the cost for
those who don't use it is overwhelming.  That's how we can build a
consensus specification.  Applications that want to require/exclude
certain types of plugins should have the means to do so.  Plugin
authors that don't want to worry about setting all the
parameters/predicates right should be provided with reasonable
defaults.

Anyhow, I hope this helps explain where I'm coming from as I make my
more technical comments. :)

Now, lets move on to audio world domination!

Eric

From - Fri Aug 27 15:19:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA07183
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 15:23:17 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA13610 for linux-audio-dev-list; Fri, 27 Aug 1999 14:33:12 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id OAA13607 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 14:33:07 -0400
From: est@hyperreal.org
Received: (qmail 24389 invoked by uid 162); 27 Aug 1999 18:30:11 -0000
Message-ID: <19990827183011.24388.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
In-Reply-To: <14278.24830.37098.474541@gige> from Guenter Geiger at "Aug 27,
 1999 12:52:04 pm"
To: Guenter Geiger <geiger@epy.co.at>
Date: Fri, 27 Aug 1999 11:30:11 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: edfcbbec5d345d20d80afdc2ec8156cf

Guenter Geiger discourseth:
> est@hyperreal.org writes:
>  > Many of my suggestions may be based on
>  > ignorance or misunderstandings.
> 
>  Go ahead and beat me ... I like it :) 

Ahh..well, it *can* be fun in the pursuit of a good design, no? :)

>  > * The only global defined by a plugin should be a uniquely named
>  >   function that returns a plugin class.  The idea here is to make it
>  >   possible to use static as well as dynamic linking.
>  > 
> 
>  .. hmmm seems to make sense .. 

I'm not particular about the exact interface, as long as static
linking isn't precluded.

>  > * Change properties to a * int32_t to avoid binary compatibility concerns.
>  > 
>  > * Change sparebytes to a void * for the same reason.
> 
>  Yep, dynamic allocation, but then, if we want to access (some later added)
>  properties we always have to check if the plugin has allocated memory 
>  for them. 

You've got that covered by numproperties.

>  > * Change the prefix to something other than `st_' which has too much
>  >   history in unix.  A three-character prefix would be much safer.
>  > 
> 
>  Agreed too, stm_ probably, I'm open to better names for the API too, 
>  strummin doesn't sound very professional, I just thought it's funny.

Hmm..I still favor my earlier suggestion of `ops', for `Open Plugin
Specification'.  It's pronouncable, appropriate and short enough for a
prefix.

>  > * The number of channels per input and output signal should be a
>  >   plugin property vector.  Counts of frames and samples should be
>  >   clearly distinguished throughout.
>  > 
> 
>  Basically I'd like to have each channel on a seperate input.           
>  We have to set some restrictions, as through flexibility we 
>  will make it harder to write applications for the plugins,
>  and introduce too much incompatibility.

I want multi-channel support pretty badly.  I certainly appreciate the
flexibilty of a mono-channel paradigm, but I think there are
situations where multi-channel makes sense.  For example, scope
plugins will often want stereo input.  Kai has also pointed out some
of his needs in this area.  Further, I've found that stereo data is a
sitting duck for hefty 3dnow acceleration.  It doesn't seem reasonable
to make plugins that want multi-channel input do their own merging
when merging/splitting can be trivial standard plugins.

One restriction that no one might find objectionable is that the input
signals and output signals of a plugin both be homogeneous with
respect to the number of channels.  Then you only need inchannels and
outchannels parameters for the plugin.  If you want mono, just make
sure these are both 1 (which could be the default).

>  > * The sample rate should be optionally settable at instance creation
>  >   time and the input and output buffer sizes should be optionally
>  >   settable per call to the process method.  I usually code in a way that
>  >   can accomodate this, but I agree that it's important to support less
>  >   flexible plugins as well.
> 
>  It's possible to set these things whenever you like.
>  The plugin programmer can decide which properties can be changed,
>  and which not. That's what the virtual verify function is all about.

Hmm..I'm wondering if there should be a harder distinction between
properties and parameters re mutability.

>  > * To handle resampling, variable output buffer sizes are important.
>  >   It's also important that the process method can report how many output
>  >   frames it generated (is this the function of the return value of the
>  >   process method?).  It may even be important that the plugin can
>  >   be queried as to how many output frames *will* be generated to avoid
>  >   overruns due to disagreements about fencepost issues.
> 
>  Isn't it enough to have different sizes for input and output buffers ?

I take back most of this and I think the issue will need some careful
thought, especially considering David Olofson's comments.

>  > * The popup method should probably be expanded to a vector of generic
>  >   gui methods.
>  > 
> 
>  As few as possible, but right, we may need more ..... 

Maybe config_dialog(), show(), hide() and a gui type string?

>  Generally, I'm open to give write access to the CVS to whomever likes.
>  I'm accepting patches too, of course. The first thing we have to
>  agree upon is the API itself. Internal concepts can be implemented
>  and tested after that.

I agree 100%.

Eric

From - Fri Aug 27 15:19:37 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA07195
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 15:23:22 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA13626 for linux-audio-dev-list; Fri, 27 Aug 1999 14:40:10 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id OAA13623 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 14:40:07 -0400
From: est@hyperreal.org
Received: (qmail 970 invoked by uid 162); 27 Aug 1999 18:37:03 -0000
Message-ID: <19990827183703.969.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] we should use gtk objects for our plugins
In-Reply-To: <14278.23876.691502.98348@gige> from Guenter Geiger at "Aug 27,
 1999 11:46:47 am"
To: Guenter Geiger <geiger@epy.co.at>
Date: Fri, 27 Aug 1999 11:37:03 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d5cfcf3bbbe83be93493823664eccf4d

Guenter Geiger discourseth:
> est@hyperreal.org writes:
>  > 
>  > Interested parties should look in particular at gtkobject.[ch],
>  > gtktypeutils.[ch] and gtkarg.[ch].  Doesn't it look like a plugin API?
>  > :)  We need only make a domain-specific sub-class.
>  > 
>  > What do you think?
> 
>  Actually I rather agree with David in this point. In the first place
> I considered using glib too, but I guess it's not too hard to build
> the parts we need from scratch, we could snap some ideas from glib, but for a
> generally usable API depending on a library that specific is no good IMO.

I don't think the core gtk object functionality is specific to much of
anything actually.  However, having looked at it further, I'm
disappointed to see that its otherwise comprehensive `arg' mechanism
doesn't support defaults or range restrictions.  Also, the whole thing
is probably too heavy-weight for audio..at least for some people on
this list. :)

glib, OTOH, is a completely separate question and I'd still recommend
going with it.  It provides great datatype definitions and has seen
heavy use on many platforms.  Coding things from scratch has a lot
less appeal for me than it did when I was younger.  It's always harder
than it seems and there are always more bugs than expected. :)

Eric

From - Fri Aug 27 15:39:34 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA09412
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 15:39:00 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA13657 for linux-audio-dev-list; Fri, 27 Aug 1999 14:50:50 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA13654 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 14:50:45 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m11KR4K-000dyjC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Fri, 27 Aug 1999 20:49:44 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Date: Fri, 27 Aug 1999 20:49:44 +0200 (CEST)
To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] ftp problem
In-Reply-To: <19990827170835.C237@cerealbox>
References: <19990827170835.C237@cerealbox>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14278.56758.638413.373275@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id PAA09412
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: cfaa7af7fc3122e461bbb117df7409c9


fixed, got the permissions wrong ... 

reactor/CTPmedia writes:
 > [17:08:02] [root@cerealbox] [~] lynx ftp://iem.mhsg.ac.at/pd/GIGE
 > 
 > Looking up iem.mhsg.ac.at.
 > Making FTP connection to iem.mhsg.ac.at.
 > Can't Access ftp://iem.mhsg.ac.at/pd/GIGE'
 > ...
 > Alert!: Unable to access document.
 > lynx: Can't access startfile
 > 
 > 
 > so? :)
 > 
 > -- 
 > 
 >   M-Bt Rcz a.k.a. reactor  -  http://linux.gyakg.u-szeged.hu/~reactor/-A
 >    CTP media - since 1995   -  http://ctpmedia.scene.hu/
 > 

From - Fri Aug 27 15:49:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA11216
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 15:49:44 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA13684 for linux-audio-dev-list; Fri, 27 Aug 1999 15:04:20 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA13681 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 15:04:15 -0400
From: est@hyperreal.org
Received: (qmail 26236 invoked by uid 162); 27 Aug 1999 18:58:13 -0000
Message-ID: <19990827185813.26234.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
In-Reply-To: <37C5F04C.DF25154E@swipnet.se> from David Olofson at "Aug 27, 1999
 03:56:28 am"
To: David Olofson <audiality@swipnet.se>
Date: Fri, 27 Aug 1999 11:58:12 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2d2a91feb03a15b0fbc18dc6bf38005d

David Olofson discourseth:
> 
> > * The only global defined by a plugin should be a uniquely named
> >   function that returns a plugin class.  The idea here is to make it
> >   possible to use static as well as dynamic linking.
> 
> Nope. For kernel modules, it only makes sense to export init_module()
> and cleanup_module(), and init_module() has to
> register_plugin(&audioeff_class) to tell the engine about the new class.
> This eliminates name space conflicts, as no symbols are exported. Also,
> a module/library can register multiple plug-in classes this way.

Ah..but that still precludes static linking.

> > * String parameters should be provided for.
> 
> On the contrary, as much as possible of the not directly signal
> processing related stuff should be kept *out* of the DSP part of the
> plug-on spec.

I think this is totally true for many plugins.  However, some plugins
will *be* gui elements.  Some will even use (shhh) files. :O  These are
inappropriate for use in rtlinux, but they represent important audio
processing that many on this list are involved in.

> > * We need a flag to say whether a parameter can be modified in between
> >   any two calls to the process method as opposed to being settable only
> >   for initizlization purposes.
> 
> Hmm... My plans are very different. I don't want parameters in the low
> level plug-in spec at all. There should be only time stamped events and
> data streams. Parameters are realized through an event based interface,
> which means
> 
> 1) Only one interface + subsystem for automation, MIDI-style
>    events and system control events.
> 
> 2) Events and parameter changes are independent of buffer sizes.
> 
> 3) *Everything* can be defined in relation to real time.
>    (A way for plug-ins to tell the engine which events they
>    support, and their real time characteristics is needed.)

Hmm..this sounds interesting but radically different from the approach
Guenter is taking.  Perhaps you should write up a competing proposal?

> > * The number of channels per input and output signal should be a
> >   plugin property vector.  Counts of frames and samples should be
> >   clearly distinguished throughout.
> 
> IMHO, input and output signal should always be mono, because anything
> else completely breaks the flexibility of free signal routing. Unless
> you automatically throw in split/merge plugs where needed... I don't
> think that's a good idea from the performance perspective.
> 
> OTOH, there might be a point in using multichannel bus formats for some
> kinds of plug-ins, so supporting it isn't a bad idea. It can result in
> faster code as long as everything fits nicely together.

Ahh..thanks!  I need support here. :) I  certainly agree that mono is
great for flexibilty.

> The basic rule is that the engine gets to decides what sample rate to
> use. Complex processing nets with plug-ins that have various smart ideas
> about what sample rates to use just becomes a mess of lost quality and
> CPU power...

Sounds good to me.  Does anyone really want sr-specific plugins?
Perhaps for i/o purposes?

> > * To handle resampling, variable output buffer sizes are important.
> >   It's also important that the process method can report how many output
> >   frames it generated (is this the function of the return value of the
> >   process method?).  It may even be important that the plugin can
> >   be queried as to how many output frames *will* be generated to avoid
> >   overruns due to disagreements about fencepost issues.
> 
> DO NOT adapt output buffer size to the inputs!!! It's doing it all
> backwards.

OK, I was on crack when I wrote that.  Honestly, I've always coded to
the give-me-this-many-output-samples paradigm so I have no idea what I
was thinking.

> The algorithm is: "I need X samples. How many input samples do you need
> for each channel?"
> 
> That's what this section of my little draft is for:
> 
>         int look_ahead;         /* Number of extra frames needed
>                                  * after the end of input buffers.
>                                  * Can be negative.
>                                  */
>         int skip_behind;        /* Number of frames skipped
>                                  * at the start of input buffers.
>                                  * (That is, inputs[n]+=look_behind
>                                  * before process_XXX() is called.)
>                                  * Can be negative.
>                                  */

Can you expand on this?  I'm slow. :)

> > * The popup method should probably be expanded to a vector of generic
> >   gui methods.
> 
> Nope. Drop it completely. There's no reason at all to have it in the
> same file as the signal processing code.

Well, audio processing isn't all about core dsp.  I've covered this in
a separate post.  I think that you can be confident that there will be
plenty of pure dsp plugins, however, and I agree that the spec must
provide for such.

> > * Memory allocation hooks are probably desirable.  That way I can get
> >   a plugin to throw bad_alloc even if it know nothing about C++.
> 
> Yes, indeed. Also, it has to be strictly defined *when* you can allocate
> and free memory, as it's not real time operations.

Hmm..what kind of predicates would be useful?  Perhaps
allocs_only_at_init() and alloc_is_param_independent() might help?  I
think those would be true of many, many pure dsp plugins.  They could
default to false for plugin authors who don't think about such things.

> It's possible to
> design a fast, non fragmenting real time memory manager with a locked
> memory pool for those who really need it, but dynamic allocation is
> generally considered a no-no in hard real time systems.

I think many pure dsp plugins would work fine using a no-op free().
Just sequentially allocate all their init stuff in a statically
allocated arena.

A tangential question re fragmentation: isn't there always some in a
malloc()/free() paradigm (assuming your free() does something)?  For
example, what's the minimal safe-for-space factor for a buddy-block
system?

Thanks for being involved, :)

Eric

From - Fri Aug 27 16:09:48 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA13973
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 16:08:17 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA13757 for linux-audio-dev-list; Fri, 27 Aug 1999 15:24:48 -0400
Received: from science.amnh.org (science.amnh.org [205.232.8.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA13754 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 15:24:41 -0400
Received: from amnh.org ([209.2.167.82])
	by science.amnh.org (8.8.8/8.8.8) with ESMTP id PAA21987
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 15:18:19 -0400 (EDT)
Message-ID: <37C6E52E.4C290C6F@amnh.org>
Date: Fri, 27 Aug 1999 15:21:18 -0400
From: Jeff Brown <jeffb@amnh.org>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: "linux-audio-dev@ginette.musique.umontreal.ca" 
 <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Tracker vs. sequencer
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8003
X-Mozilla-Status2: 00000000
X-UIDL: 6b1f2fc3195e75f116b64a10dd7ace7d


> Basically, I don't mind algorithmic music, but I don't want
> a tracker, I want a sequencer.  Why the most expensive 
> commercial sequencers on the market have been trying their 
> hardest to turn into trackers is a mystery to me.

I've never heard the term "tracker" before.  What's the difference? 
What's are a few examples of both?

From - Fri Aug 27 16:49:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA21009
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 16:50:25 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA13819 for linux-audio-dev-list; Fri, 27 Aug 1999 16:06:00 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA13816 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 16:05:56 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m11KSF1-000dyjC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Fri, 27 Aug 1999 22:04:51 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Fri, 27 Aug 1999 22:04:51 +0200 (CEST)
To: est@hyperreal.org
Cc: Guenter Geiger <geiger@epy.co.at>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
In-Reply-To: <19990827183011.24388.qmail@hyperreal.org>
References: <14278.24830.37098.474541@gige>
	<19990827183011.24388.qmail@hyperreal.org>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14278.60272.295078.902229@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: dd81f593bb09c59478ccb0307dc85258

est@hyperreal.org writes:
 > >  It's possible to set these things whenever you like.
 > >  The plugin programmer can decide which properties can be changed,
 > >  and which not. That's what the virtual verify function is all about.
 > 
 > Hmm..I'm wondering if there should be a harder distinction between
 > properties and parameters re mutability.
 > 

 The difference is that properties have to be set for a plugin.
Properties are the way how we can determine if the plugin fits for the 
application or not.


Parameters are values that can be changed during plugin operation.
Parameters are values that are implemented by the plugin programmer
and only accessible through get/setparameter.
 
 > >  > * The popup method should probably be expanded to a vector of generic
 > >  >   gui methods.
 > >  > 
 > > 
 > >  As few as possible, but right, we may need more ..... 
 > 
 > Maybe config_dialog(), show(), hide() and a gui type string?
 > 

 Hide could be done by the plugin itself, show is the same as
 popup.  
 I'm not sure what config dialog means, but if its an additional
 dialog this could be started form the plugin's GUI as well.

 I think we should keep any GUI stuff out of the API as good
 as possible.

 Guenter
  

From - Fri Aug 27 17:09:36 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA24709
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 17:14:17 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA13862 for linux-audio-dev-list; Fri, 27 Aug 1999 16:24:20 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA13859 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 16:24:17 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m11KSWp-000dyjC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Fri, 27 Aug 1999 22:23:15 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Fri, 27 Aug 1999 22:23:15 +0200 (CEST)
To: est@hyperreal.org
Cc: Guenter Geiger <geiger@epy.co.at>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
In-Reply-To: <19990827183011.24388.qmail@hyperreal.org>
References: <14278.24830.37098.474541@gige>
	<19990827183011.24388.qmail@hyperreal.org>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14278.61292.70284.757058@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: fac46127f6aa38cec676c71362c98fee

est@hyperreal.org writes:
 > >  Yep, dynamic allocation, but then, if we want to access (some later added)
 > >  properties we always have to check if the plugin has allocated memory 
 > >  for them. 
 > 
 > You've got that covered by numproperties.
 > 

 Yes, but actually we don't want to expand the number of properties
 (it's surely not something the plugin should be able to do).
 The properties are hardcoded into the spezification, they are just
 like the flags in VST or some variables that have to be set by each
 plugin.
 
 Only in emergency cases (If we find a problem with our plugin API
 or somthing needs a new kind of plugins they will be extended).

 But I'm not completely against dynamic allocation ... just some
 points why it isn't that important here, ...

 > >  > * Change the prefix to something other than `st_' which has too much
 > >  >   history in unix.  A three-character prefix would be much safer.
 > >  > 
 > > 
 > >  Agreed too, stm_ probably, I'm open to better names for the API too, 
 > >  strummin doesn't sound very professional, I just thought it's funny.
 > 
 > Hmm..I still favor my earlier suggestion of `ops', for `Open Plugin
 > Specification'.  It's pronouncable, appropriate and short enough for a
 > prefix.
 > 

 ops sounds cool, but .... well Open Plugin Specification sound rather
  .. not very inventive .. but probably what we need for some people 
 to accept the API.

 > >  > * The number of channels per input and output signal should be a
 > >  >   plugin property vector.  Counts of frames and samples should be
 > >  >   clearly distinguished throughout.
 > >  > 
 > > 
 > >  Basically I'd like to have each channel on a seperate input.           
 > >  We have to set some restrictions, as through flexibility we 
 > >  will make it harder to write applications for the plugins,
 > >  and introduce too much incompatibility.
 > 
 > I want multi-channel support pretty badly.  I certainly appreciate the
 > flexibilty of a mono-channel paradigm, but I think there are
 > situations where multi-channel makes sense.  For example, scope
 > plugins will often want stereo input.  Kai has also pointed out some
 > of his needs in this area.  Further, I've found that stereo data is a
 > sitting duck for hefty 3dnow acceleration.  It doesn't seem reasonable
 > to make plugins that want multi-channel input do their own merging
 > when merging/splitting can be trivial standard plugins.
 > 
 > One restriction that no one might find objectionable is that the input
 > signals and output signals of a plugin both be homogeneous with
 > respect to the number of channels.  Then you only need inchannels and
 > outchannels parameters for the plugin.  If you want mono, just make
 > sure these are both 1 (which could be the default).
 > 

 Ok, if we accept that it's just like adding 

  DATAfloatstereo
  DATAint32stereo
  DATAdoublestereo
 
 to the dataformat enum, which is actually contraproductive.
 We will just get more incompatible plugins.
 Keeping channels separated in different streams is a more
 profesional approach, because sometimes I really do think of
 let's say 4 channel spatialisation .... will this be 2 stereo
 channels, 4 mono channels , or 4 channel interleaved ?

 so, I'm still against it, I'd like to hear other comments too.

 Guenter

From - Fri Aug 27 22:36:28 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA22462
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 21:20:27 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA14254 for linux-audio-dev-list; Fri, 27 Aug 1999 20:43:27 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA14243 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 20:43:19 -0400
Received: from localhost.localdomain (dialup84-1-10.swipnet.se [130.244.84.10]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA00592; 
          Sat, 28 Aug 1999 02:40:13 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Kai Vehmanen <kaiv@wakkanet.fi>
Subject: Re: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
Date: Fri, 27 Aug 1999 22:39:55 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: est@hyperreal.org, Guenter Geiger <geiger@epy.co.at>,
        linux-audio-dev@ginette.musique.umontreal.ca
References: <%Vqhx3g0fN@sculpcave>
MIME-Version: 1.0
Message-Id: <99082723314801.01621@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id CAA00592
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA22462
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0c5fd1cc2e3bb668d4c9f6b5721e7d04

On Fri, 27 Aug 1999, Kai Vehmanen wrote:
> I've used a simple number_of/name_of/set/get_parameter approach in 
> ecasound and it sure is far from perfect. The biggest problem
> has been to find a good balance of efficiency, flexibility and precision.

The classic problem... That's why I want the raw foundation clean and simple,
and based on structures that can be handled with efficient algorithms. Extra
levels of pointer indirection, switches with big skips in the constants (wrecks
the nice jump table optimisation the compiler does otherwise) and that kind of
cycle hogs should be banned from the main paths. Assembly language programming
experience is very valuable here.

> One solution works when parameters are controlled by a GUI knob, 
> but when you want to use high-frequency oscillators as controllers,
> things change. If you can get all necessary info about supported 
> events straight from the plugin object, event based system might 
> do the job. 

I realized that after thinking up many ways of passing this kind of
information. It's easy to think of a few solutions that looks nice in the
plug-in, but eliminates any chance of getting a nice engine implementation. You
always have to keep the entire system in mind.

The event system I have in mind does not use any function calls. It'll be based
on time stamped blocks of events, encoded as sequential binary data. Basically,
you get a buffer with all events you're supposed to process for the buffers
you're about to process or generate, and you get to do the decoding in the most
efficient way. I'm not entirely sure about the output "port", but one way is to
provide a sufficiently sized buffer (*) for the plug-in to use.

(*) This buffer would actually be a huge global ring buffer, used by the
engine as a sort of dynamic memory pool throughout the processing net. You just
pass the (incremented) output pointer returned from one plug-in as the start of
the output buffer for the next one to call.

This method would mean that the event system's transport system is incredibly
simple, and still flexible, so it doesn't have to be hidden in engine function
calls. The event system definition is actually a definition of a streaming data
format. It could be restricted to fixed size structs.

If we realize some events need more space, we can just link events, so that
you get "data events" that can simply be ignored by any code that doesn't know
how to decode the "header event" they belong to. The fixed size simplifies a
lot of things, and eliminates the need to always increment pointers by the size
of the current event in loops. There are a lot of other situations where fixed
size of events will make code simpler, cleaner and faster.

Comments?

> > IMHO, input and output signal should always be mono, because anything
> > else completely breaks the flexibility of free signal routing. Unless
> > you automatically throw in split/merge plugs where needed... I don't
> > think that's a good idea from the performance perspective.
> 
> This is also a difficult decision.

Yes, but I think I have finally found a lot more reason in one than in the
other...

> I chose to use stereo-signals.
> From musicians standpoint, this is the way to go as many effects 
> (reverbs, delays, panning, etc) work best when used in a stereo 
> context.

Yes, but have you ever seen a stand-alone FX box with stereo jacks? Well, they
might exist, but I have yet to see one. And there's a reason for that:
flexibility.

For example, I might want to feed the left output from my reverb
box through a spatializer, and the right one through a soft, slow compressor,
and then pan the results in the usual way; the spatializer's left and right
channels to two mixer inputs, and the compressor ouput to a third.

Another scenario, that's perhaps more likely, is where you have a stereo signal
from some FX box, but want to EQ the channels individually. Now, if you were
using stereo jacks, and a stereo input on the mixer, you'd have to use an
external stereo EQ, rather than the normal mixer board EQs... (Most mixers with
stereo inputs have EQs and other stuff hardwired with left and right in tandem.)

The only real excuse I can see for using multichannel signals is performance.
CPUs like x86 have too few registers to handle multiple pointers efficiently.
I managed to hack 68k code (Amiga) that resampled and mixed three voices at
once by using all registers (8 data regs + 7 address regs, A7 is the stack...),
but you can just forget about that kind of stuff on x86. One voice is enough to
run out of registers if you're not careful. This old crap architecture... *sigh*

> And I don't think I'll be doing multi-channel mixes of 
> my music any time soon... 

Perhaps not, but some people are already doing it. And mixing a movie
soundtrack without surround has been out of the question for long already!


There is one hybrid solution... Include the increment to get to the next sample
with every buffer. That way, you can pass one channel in an n-channel buffer by
sending the address of the first sample belonging to that sample, and
sizeof(sample)*n as increment. In most cases, it won't result in cache
problems, as the buffers are either passed around between plug-ins, or reused
for new signals. It does, however, mean that you can't use the auto
increment/decrement addressing modes some CPUs have.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Aug 27 17:31:48 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA27924
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 17:37:50 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA13912 for linux-audio-dev-list; Fri, 27 Aug 1999 16:53:50 -0400
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id QAA13909 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 16:53:48 -0400
Message-Id: <199908272053.QAA13909@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] plug-in design space
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Fri, 27 Aug 1999 16:50:28 -0400 (EDT)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
In-Reply-To: <37C5F04C.DF25154E@swipnet.se> from "David Olofson" at Aug 27, 99 03:56:28 am
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: b333b56a1ecc86d653f00d6f3c06c3a0

General methodological question: is anybody broadly familiar with
existing plugin APIs, and can say what's good or bad about them?
(I could tell you about DirectShow, but you'd just have nightmares.)
Will a new API be enough better that people will adopt it widely?

How about a couple of larger-scale design questions before we get down
to bits and bytes?  These decisions affect the complexity of the
plug-in architecture by at least an order of magnitude, based on two
audio-processing systems I've worked on.  Oh, make that two orders of
magnitude -- had momentarily suppressed the memory of DirectShow.

 * Is this for real-time streaming, non-real-time editing, or both?

I vote a big "both".  RT streaming pretty much requires the use of
data-pull, walking backwards up the graph:
> The algorithm is: "I need X samples. How many input samples do you need
> for each channel?"
But the answer may be "I dunno, I'll have to see what the values of my
inputs are."  A voltage-controlled time-warper, for example.  This
works fine in non-RT, where it's more natural to do data-push down the
graph.  Support this?

A follow-up question:

 * If non-RT, can output keep running after input has been used up?

And I don't mean just like for the time-warper, where the output may
be longer than the input, but depends directly on it all the way along.
I mean like an echo effect would want to keep generating output until
the echo has dropped to a low enough level.  Or do we just say that
it's the user's responsibility to guess how long the echo tail will
be, and pad the input with zeros?  I have no opinion on this one.

 * Block-synchronous computation?

If all blocks of data cover the same span of time, then each component
gets a complete block at each input and puts a complete block on each
output.  This is pleasant.  But I'm afraid we're going to be compelled
to leave this Eden.

 * What about sampling rates?

Again, life is much easier if there's only one sampling rate.  This
loses efficiency, because some of your signals don't need to run that
fast -- in synthesis applications, a factor of two or three.  

It also loses generality (the loss that'll hurt more five years from
now) because sometimes you need a higher rate.  Upsample - process -
downsample to make EQ work right on the high end, or for distortion
without aliasing.  Or you could, by agreement between components,
flatten overlapped spectral frames into a 4x-rate stream, if you have
no better way to pass this data.

I've seen an arbitrary-sample-rate architecture (Nyquist), and it's
not pretty.  Possible compromise: an audio sampling rate, and support
multiples and submultiples of it.

 * Support multiple sound cards that aren't sample-synchronized?

Without doing full-on windowed-sinc resampling all over the place,
we're not going to be able to mingle data from multiple sound cards.
So be it.  But what about events, parameter updates?  It's simplest if
they're timestamped in terms of sample frames.  Do we care enough
about unsynchronized cards to timestamp events with some global clock
and then deal with conversion?  I, personally, do not, but I do wish
Linux could get more drivers for multi-channel cards.

 * What's static and what's dynamic?

It would be nice to support variable numbers of inputs and outputs: An
n-to-m matrix mixer, for example, where n and m are determined upon
instantiation of the prototype.  Here n and m are probably not
"events" like you'd send to a component-instance.  Interesting
startup-ordering issues.  And do component-prototypes have the
opportunity to specialize the execution loop of each instance?

 * How are feedback loops handled?

If there are no cycles, the flow graph is a DAG and you can just
topologically sort it up-front, or traverse it on demand.  With
cycles, you need to be a bit more clever.  And do you enforce that
loops not be delay-free?  If not, do you let the result vary with
block size, or force block size equal to one sample, or what?  I've
never worked with a system that allowed loops.

 * Is each `wire' mono?

Here's where I stepped in.  My leaning is towards mono wires for
simplicity.  Performance is not clear to me.  Better memory-access
patterns for interleaved channels.  Worse inner loop, the general loop
anyway: "for (int channel = 0; channel < nchannels; ++channel) foo"
where nchannels commonly turns out to be 1 each time.

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Fri Aug 27 17:35:47 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA28308
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 17:39:50 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA13940 for linux-audio-dev-list; Fri, 27 Aug 1999 17:00:09 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id RAA13937 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 17:00:07 -0400
From: est@hyperreal.org
Received: (qmail 10773 invoked by uid 162); 27 Aug 1999 20:55:22 -0000
Message-ID: <19990827205522.10772.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
In-Reply-To: <14278.60272.295078.902229@gige> from Guenter Geiger at "Aug 27,
 1999 10:04:51 pm"
To: Guenter Geiger <geiger@epy.co.at>
Date: Fri, 27 Aug 1999 13:55:22 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 188313611ea582ae429ded9a8ffc3cf4

Guenter Geiger discourseth:
> est@hyperreal.org writes:
>  > >  It's possible to set these things whenever you like.
>  > >  The plugin programmer can decide which properties can be changed,
>  > >  and which not. That's what the virtual verify function is all about.
>  > 
>  > Hmm..I'm wondering if there should be a harder distinction between
>  > properties and parameters re mutability.
> 
>  The difference is that properties have to be set for a plugin.
> Properties are the way how we can determine if the plugin fits for the 
> application or not.
> 
> Parameters are values that can be changed during plugin operation.

..and *some* properties, depending on what the verify() function says,
am I correct?  A lot of this comes back to my questions re
sampling-rate and blocksizes.  Perhaps properties *should* be
immutable throughout.  If a plugin is flexible about sampling-rate
and/or blocksizes, it can use a don't-care value for those properties.
I'd prefer to have those things modified through the setparam()
methods anyhow since they may entail modifying other private data.

>  > >  > * The popup method should probably be expanded to a vector of generic
>  > >  >   gui methods.
>  > >  > 
>  > > 
>  > >  As few as possible, but right, we may need more ..... 
>  > 
>  > Maybe config_dialog(), show(), hide() and a gui type string?
>  > 
> 
>  Hide could be done by the plugin itself, 

Not if the app wants to do it.

> show is the same as popup.  

Yes.

>  I'm not sure what config dialog means, but if its an additional
>  dialog this could be started form the plugin's GUI as well.
> 
>  I think we should keep any GUI stuff out of the API as good
>  as possible.

OK.  Here's a simplifying suggestion.  Two fields: 1) a gui type
string and 2) an opaque gui data pointer.

Eric

From - Fri Aug 27 22:36:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA29918
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 17:51:25 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA13978 for linux-audio-dev-list; Fri, 27 Aug 1999 17:09:56 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id RAA13975 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 17:09:53 -0400
From: est@hyperreal.org
Received: (qmail 26380 invoked by uid 162); 27 Aug 1999 21:06:57 -0000
Message-ID: <19990827210657.26378.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
In-Reply-To: <14278.61292.70284.757058@gige> from Guenter Geiger at "Aug 27,
 1999 10:23:15 pm"
To: Guenter Geiger <geiger@epy.co.at>
Date: Fri, 27 Aug 1999 14:06:57 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 59fd485430f9a35b42d5402c48111f21

Guenter Geiger discourseth:
[re properties]
> 
>  But I'm not completely against dynamic allocation ... just some
>  points why it isn't that important here, ...

Yes, I agree now that I better understand your approach to properties.

>  > Hmm..I still favor my earlier suggestion of `ops', for `Open Plugin
>  > Specification'.  It's pronouncable, appropriate and short enough for a
>  > prefix.
> 
>  ops sounds cool, but .... well Open Plugin Specification sound rather
>   .. not very inventive .. but probably what we need for some people 
>  to accept the API.

Hmm..perhaps we can come up with a colorful alternative expansion of
the acronym.  I'll give it some though.

>  > One restriction that no one might find objectionable is that the input
>  > signals and output signals of a plugin both be homogeneous with
>  > respect to the number of channels.  Then you only need inchannels and
>  > outchannels parameters for the plugin.  If you want mono, just make
>  > sure these are both 1 (which could be the default).
> 
>  Ok, if we accept that it's just like adding 
> 
>   DATAfloatstereo
>   DATAint32stereo
>   DATAdoublestereo
>  
>  to the dataformat enum, 

..for various values of nchannels, yes.

> which is actually contraproductive.
>  We will just get more incompatible plugins.

We'll get incompatible plugins, yes..*and* we'll get more code reuse.

>  Keeping channels separated in different streams is a more
>  profesional approach, because sometimes I really do think of
>  let's say 4 channel spatialisation .... will this be 2 stereo
>  channels, 4 mono channels , or 4 channel interleaved ?

These are certainly real downsides.  Our goals and trade-offs may be
different..and I'd like a spec that accomodates different
goals..especially given the variety of them on this list. :)

Eric

From - Fri Aug 27 22:36:21 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA32021
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 18:06:32 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA14009 for linux-audio-dev-list; Fri, 27 Aug 1999 17:27:33 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA14006 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 17:27:30 -0400
Received: from ulster.net (port82.king.ulster.net [208.242.160.83])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id RAA28186;
	Fri, 27 Aug 1999 17:39:25 -0400
Message-ID: <37C703B3.44A1F7AC@ulster.net>
Date: Fri, 27 Aug 1999 17:31:31 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jeff Brown <jeffb@amnh.org>
CC: "linux-audio-dev@ginette.musique.umontreal.ca" 
 <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Tracker vs. sequencer
References: <37C6E52E.4C290C6F@amnh.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7f9b2872a132824ff7a9979eb58b6486

Jeff Brown wrote:
> I've never heard the term "tracker" before.  What's the difference?
> What's are a few examples of both?

"Trackers" are descendants of the Amiga MOD / "demo" scene. Examples are
ImpulseTracker, FastTracker2, and (on Linux) FunkTracker Gold and some
others I haven't tried. They are sequencers of a sort: they use a
text-based representation of note events, usually organized into
columns. The note events are triggered sound samples. They usually have
little or no processing capability, just play the samples at different
pitches with maybe some envelope control and pitch modulation. Usually
the samples get saved into a single file along with the sequence. I
don't know of any trackers that can be controlled by MIDI; it's all done
at the computer keyboard. 

I briefly played with trackers a year or two ago, but found them
simultaneously too clunky to work with and way too inflexible, a
thoroughly pointless combination IMHO. If I want clunkiness I'll take
Csound, thanks very much. :)

-- 

----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Fri Aug 27 22:36:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA23377
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 21:27:37 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA14250 for linux-audio-dev-list; Fri, 27 Aug 1999 20:43:22 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA14242 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 20:43:19 -0400
Received: from localhost.localdomain (dialup84-1-10.swipnet.se [130.244.84.10]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA00605; 
          Sat, 28 Aug 1999 02:40:16 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Kai Vehmanen <kaiv@wakkanet.fi>
Subject: Re: [linux-audio-dev] we should use gtk objects for our plugins
Date: Fri, 27 Aug 1999 23:32:23 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: est@hyperreal.org, linux-audio-dev@ginette.musique.umontreal.ca
References: <%bvix3g0fO@sculpcave>
MIME-Version: 1.0
Message-Id: <99082723374302.01621@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id CAA00605
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA23377
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3a72244084a110c1a67c76acc358e238

On Fri, 27 Aug 1999, Kai Vehmanen wrote:
> And hard-realtime or not, this plugin-interface shouldn't get 
> too complex. If this happens, the resulting interface won't
> be adopted by the majority of application/plugin developers. 

Exactly! And I think we can beat VST 2.0 in features, while still
getting at least the same performance, and a cleaner interface. VST 2.0 lacks
important features needed for plug-ins to be usable as modules in soft synths,
it's in C++, it has legacy 1.0 stuff, and it has the serious design flaw of
mixing GUI stuff with signal processing...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Aug 27 22:36:23 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA06389
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 18:56:48 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA14083 for linux-audio-dev-list; Fri, 27 Aug 1999 18:09:17 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id SAA14080 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 18:09:14 -0400
From: est@hyperreal.org
Received: (qmail 4599 invoked by uid 162); 27 Aug 1999 22:06:11 -0000
Message-ID: <19990827220611.4598.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] plug-in design space
In-Reply-To: <199908272053.QAA13909@ginette.musique.umontreal.ca> from Eli Brandt
 at "Aug 27, 1999 04:50:28 pm"
To: eli+@cs.cmu.edu
Date: Fri, 27 Aug 1999 15:06:11 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7d72b6eb93c33f067d593b481ffbe50d

Eli Brandt discourseth:
> General methodological question: is anybody broadly familiar with
> existing plugin APIs, and can say what's good or bad about them?

I sure can't claim breadth here.  I'd be excited to see someone reply
with a positive answer to this question.

> Will a new API be enough better that people will adopt it widely?

Great question.  There are lots of APIs out there.  My experience is
that most of them are partial solutions..developed by an individual or
small team for limited purposes.  I just looked at the xmms API..not
bad, but I'd say it shows such limitations.  I'm hoping that an API
developed by drawing on this list's many facets in a consensus process
will be more widely usable.

> How about a couple of larger-scale design questions before we get down
> to bits and bytes?

Basic motivation is a really important question.  In a separate
posting I described mine: frustration with all the wheel re-invention
going on.  That definitely leads to different criteria than Designing
the Right Architecture does.

>  * Is this for real-time streaming, non-real-time editing, or both?
> 
> I vote a big "both".

I second that!  Wide variation along this dimension is central to our
community.

> RT streaming pretty much requires the use of
> data-pull, walking backwards up the graph:
> > The algorithm is: "I need X samples. How many input samples do you need
> > for each channel?"
> But the answer may be "I dunno, I'll have to see what the values of my
> inputs are."  A voltage-controlled time-warper, for example.  This
> works fine in non-RT, where it's more natural to do data-push down the
> graph.  Support this?

I think we need to support both even though both might not be used in
a given app.  My focus is a spec that doesn't get in people's way. :)

>  * If non-RT, can output keep running after input has been used up?

Yeah, we need to specify a drain method.  This could be the same as
the process method with a 0-size inbuf.

>  * What about sampling rates?

Well, I expect we'll have fixed-rate and variable rate plugins.  I
generally code to variable myself.

> I've seen an arbitrary-sample-rate architecture (Nyquist), and it's
> not pretty.

Oooh..details?  I may be getting your terms crossed here though.  I
can see how fixed sampling rate plugins (with different sampling
rates) would require a variable sampling rate architecture..and vice
versa.  It's the `vice versa' that I prefer. :)

>  * What's static and what's dynamic?
> 
> It would be nice to support variable numbers of inputs and outputs: An
> n-to-m matrix mixer, for example, where n and m are determined upon
> instantiation of the prototype.

I'm fond of this sort of thing..but it sure gets complex. :)

>  * How are feedback loops handled?

What I'm hoping for is a spec that will handle a variety of plugins,
not all of which will be appropriate for given architectural decisions
on these sorts of questions.

>  * Is each `wire' mono?
> 
> Here's where I stepped in.  My leaning is towards mono wires for
> simplicity.  Performance is not clear to me.

It can also complicate memory management if all multi-channel code
has to be rewritten to merge its input streams to become a plugin.

Eli, this is one great set of points/questions!  It's posts like this
that will create a good spec. :)

Eric

From - Fri Aug 27 22:36:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA23435
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 21:28:05 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA14253 for linux-audio-dev-list; Fri, 27 Aug 1999 20:43:24 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA14249 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 20:43:21 -0400
Received: from localhost.localdomain (dialup84-1-10.swipnet.se [130.244.84.10]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA00635 for <linux-audio-dev@ginette.musique.umontreal.ca>; 
          Sat, 28 Aug 1999 02:40:23 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] problems with plugins?
Date: Sat, 28 Aug 1999 00:13:12 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <99082800135304.01621@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id CAA00635
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA23435
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 798d2b4cb3fd314a66b829f08d468dea

On Fri, 27 Aug 1999, you wrote:
> yo!
> 
> i just thought about it all. is it even possible to make studio-sounding
> very-hi-fi stuff in realtime, with software?

Depends on what kind of processing you need... A normal mixer with EQs and all
is no problem.

> just take a look at Cooledit's
> reverberation. on my p200, it takes 5 seconds to reverb some 2-second wave.
> i know there are 1000 GHz pentium3s nowadays, but but but... :)

A P-II is about twice as efficient, so your P200 is like a P-II 100 or
something. (There can be more or less difference depending on how the code it
written.)

And AMD K7 beats a P-III hands down on the same rate, and is available at up to
800 MHz (cooled) right now. That 800 MHz box is nearly twice as fast as a P-III
550, which means... some 10 to 15 time what you've got in your box. And that's
just ONE K7. They support SMP up to 8 or 16 CPUs... (Don't remember the
figure.)

And, then there's 3DNow! (SIMD - Single Instruction, Multiple Data, which
means you can process 2 or 4 FP numbers in parallel), which boosts signal
processing performance a lot. MMX enabled speed-ups between 50% and 400% by
converting code from normal integer stuff, and 3DNow! should do at least half
of that improvement for FP. Oh, and AMD added a few special 3DNow! instructions
suitable for signal processing. AFAIK, one is the multiply-and-accumulate
instruction that used to be the reason why DSPs are a lot more efficient than
normal CPUs for signal processing.

Still worried about power? Well, there's always Alpha AXP, but K7 is cathing up
on them...

> and if a realtime reverb plugin doesn't sound like a Lexicon, should we
> bother using it? (well, i don't have money for Lexicon, that's why i'm
> using pc with soundcards :))

Well, if you can't afford a Lexicon, you'll have to chose between a lower
priced stand-alone unit and a software plug-in. The hardware FX box just does
what it's built for, and does it pretty good. While the software plug-in + a
decent computer can do a lot more. And you always have the choice of bumping
the plug-in's density control to max and have a cup of coffie while it's mixing
down you track to disk. You can't do that with a stand-alone box...

> i believe in non-realtime music-making.

Not my thing, really, even though I'm not at all a "live" guy. I usually record
everything played from the MIDI keyboard, and then edit or quantisize some if
necessary. And I always sing in real time, of course... ;-)

> currently i'm in the final state
> of planning my tracker that uses Csound to make the actual sound, and
> it would be semi-realtime.

That sound pretty interesting. Used to like trackers oncy upon a time, for being
integrated and having exact timing... :-)

> i mean, if you pressed "play pattern", it'd
> calculate your pattern to a wav and play it :) (actually "csound -odevaudio"
> should/will work well, but what if the cpu power is just not enough...)

> anyway, "effects" are simply non-realtime plugins? :)

A plug-in could be any kind of extension to an application, actually... So yes,
if the "effects" are dynamically linked and work in non real time, they're non
real time plug-ins. :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Aug 27 22:36:27 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA22461
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 21:20:26 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA14259 for linux-audio-dev-list; Fri, 27 Aug 1999 20:43:38 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA14256 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 20:43:36 -0400
Received: from localhost.localdomain (dialup84-1-10.swipnet.se [130.244.84.10]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA00644; 
          Sat, 28 Aug 1999 02:40:24 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: est@hyperreal.org, linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] My Hopes for an Open Plugin Specification
Date: Sat, 28 Aug 1999 00:24:14 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <19990827180254.2658.qmail@hyperreal.org>
MIME-Version: 1.0
Message-Id: <99082801013605.01621@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id CAA00644
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA22461
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4c8e9ada18987a3b11e75b47abcc04dd

On Fri, 27 Aug 1999, est@hyperreal.org wrote:
> Hello, people,
> 
> First of all, I hope more people will participate in the dialog. :)

So do I. The massive force of our collective skills and experience should make
it possible to get something pretty decent together. Worked for Linux... :-)

In this case, we're actually dealing with Open Design rather than Open
Source... Kind of interesting. Has this been done before in this form?

> My personal hopes for an open plugin specification are based on
> frustration with the current situation.  There's a *lot* of existing
> code out there.  Usually when I want to use a piece of code for my
> purposes, I have to hack it up a little.  I'd much rather hack it up
> to a common specification so that everyone can use it.  Similarly for
> the code I write (or that my programs write :)  I suspect most coders
> here can empathize with this.

Yep. And I'd like to add that there's quite a few hackers from The Dark Side
who are thinking about Converting. But they can't, as long as there's no
plug-in API they can port their DirectX and VST plugs to... Ok, they'll
probably need to get some more understanding of The Source before they decide
to release theirs, but I wouldn't mind seeing shareware Linux binaries. Some of
those plug-ins are pretty decent, and $20 or so isn't much, especially if you
get the whole OS and engine to run them for free with source!

And yeah, I'd pay the full price for plugs from the Big Guys as well, if there
was a system that made them usable. This is currently not the case, except for
ProTools. (Which is a dedicated hardware system; an obsolete design, IMO.)

> This means I want a specification that can accomodate most of the code
> out there that I'll probably end up using and most of the code that
> I'll end up writing.  I hope other people's needs will be accomodated
> as well.  This means that the specification should accomodate styles
> and paradigms that I don't plan on using and may even find
> distasteful.

Agree. Performance first, though. No creeping featurism, because that would kill
our project before it even got stable. I'd rather use an API with a style I
don't agree with, but results in good performance, than one the looks
cool, but doesn't solve the problem due to inherent performance or engine
implementation problems.

Anyway, that's exactly why I decided to go public with Audiality in the design
phase, rather than just hacking away. (Well, "talk is cheap" and all that, so
it's not easy to become popular without cool code on the web...) If there was a
spec to follow, I'd have been better off just shutting up and hack. But as
there's no API to build the engine around yet, this way is probably better.

> There's an incredible variety of approaches and concerns with respect
> to audio software on this list.  If someone really wants a feature in
> the plugin specification, I think it should go in unless the cost for
> those who don't use it is overwhelming. That's how we can build a
> consensus specification.  Applications that want to require/exclude
> certain types of plugins should have the means to do so.  Plugin
> authors that don't want to worry about setting all the
> parameters/predicates right should be provided with reasonable
> defaults.

Limiting the new API's usefulness will hardly make it successful. That's
why I'm still collecting ideas rather than hacking a serious API spec. If I
did, I'd probably have to do it all over again a few times to get the new stuff
in without wrecking the API. I'll let others do the mistakes, while I let the
final API evolve in my mind. ;-)

> Anyhow, I hope this helps explain where I'm coming from as I make my
> more technical comments. :)
> 
> Now, lets move on to audio world domination!

Yep, time to show the Big Guys how to do it! :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Aug 27 22:36:24 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA13322
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 19:58:57 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA14155 for linux-audio-dev-list; Fri, 27 Aug 1999 19:22:39 -0400
Received: from sculpcave.localdomain (cvx-1-20.dyn.nic.fi [62.236.97.20]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA14152 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 19:22:34 -0400
Received: (from root@localhost)
	by sculpcave.localdomain (8.8.7/8.8.7) id BAA02864;
	Sat, 28 Aug 1999 01:40:34 +0300
Date: Sat, 28 Aug 1999 01:40:33 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] we should use gtk objects for our plugins (fwd)
Message-ID: <%5Oxx3QbB0@sculpcave>
X-User-Agent: Mana 4.0beta (Linux)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by sculpcave.localdomain id BAA02864
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA13322
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 35ccabe85f4ca2f7ab7218007527214b

---------- Forwarded message ----------
Date: Fri, 27 Aug 1999 17:08:38 +0200
From: reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>
To: Kai Vehmanen <kaiv@wakkanet.fi>
Subject: Re: [linux-audio-dev] we should use gtk objects for our plugins

 >% > Some interesting reading in there, but IMO, it's too complex as a
 >% > foundation for a real time audio plug-in system, while not specific
 >% > enough to help us very much. It's designed to handle the complete object
 >% 
 >% And hard-realtime or not, this plugin-interface shouldn't get 
 >% too complex. If this happens, the resulting interface won't
 >% be adopted by the majority of application/plugin developers. 

i wanted to write about this.
there are lotsa more clever/diligent people on this list. i just wanna code
the "inner loop" of a plugin. and not more. i don't wanna care about
realtime buffersize-changing, or stuff like that :)
is it possible to hide these kind of things from the "ordinary laymen",
like the "majority of application/plugin developers"?

-- 

  Mt Rcz a.k.a. reactor  -  http://linux.gyakg.u-szeged.hu/~reactor/
   CTP media - since 1995   -  http://ctpmedia.scene.hu/

From - Fri Aug 27 23:16:18 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA03181
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 23:19:06 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA14274 for linux-audio-dev-list; Fri, 27 Aug 1999 20:44:16 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA14271 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 20:44:10 -0400
Received: from localhost.localdomain (dialup84-1-10.swipnet.se [130.244.84.10]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA00653; 
          Sat, 28 Aug 1999 02:40:26 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: est@hyperreal.org, Guenter Geiger <geiger@epy.co.at>
Subject: Re: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
Date: Sat, 28 Aug 1999 01:08:57 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <19990827183011.24388.qmail@hyperreal.org>
MIME-Version: 1.0
Message-Id: <99082802200806.01621@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id CAA00653
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id XAA03181
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 97d7a96ca1690b05e6a7eaa76bffadc7

On Fri, 27 Aug 1999, est@hyperreal.org wrote:
> >  > * The only global defined by a plugin should be a uniquely named
> >  >   function that returns a plugin class.  The idea here is to make it
> >  >   possible to use static as well as dynamic linking.
> >  > 
> > 
> >  .. hmmm seems to make sense .. 
> 
> I'm not particular about the exact interface, as long as static
> linking isn't precluded.

And this is about as far from the main execution paths as we'll ever get, so it
doesn't matter much how it's done, as long as it's nice and does the job well.

> >  > * Change properties to a * int32_t to avoid binary compatibility concerns.
> >  > 
> >  > * Change sparebytes to a void * for the same reason.
> > 
> >  Yep, dynamic allocation, but then, if we want to access (some later added)
> >  properties we always have to check if the plugin has allocated memory 
> >  for them. 
> 
> You've got that covered by numproperties.

With out-of-band events (that is, events with no time stamps - handled by the
reciever ASAP) for requesting and setting properties, this is reduced to a
matter of plug-in implementation. The host just asks for a list of properties,
and can then access them safely through the event system. Bonus: Full
automation for free; just record/playback the interesting event streams...

> >  > * The number of channels per input and output signal should be a
> >  >   plugin property vector.  Counts of frames and samples should be
> >  >   clearly distinguished throughout.
> >  > 
> > 
> >  Basically I'd like to have each channel on a seperate input.           
> >  We have to set some restrictions, as through flexibility we 
> >  will make it harder to write applications for the plugins,
> >  and introduce too much incompatibility.
> 
> I want multi-channel support pretty badly.  I certainly appreciate the
> flexibilty of a mono-channel paradigm, but I think there are
> situations where multi-channel makes sense.  For example, scope
> plugins will often want stereo input.  Kai has also pointed out some
> of his needs in this area.  Further, I've found that stereo data is a
> sitting duck for hefty 3dnow acceleration.

Yeah, doing SIMD in that direction (as opposed to processing multiple
sequential samples at once) eliminates the dependency problems...

> It doesn't seem reasonable
> to make plugins that want multi-channel input do their own merging
> when merging/splitting can be trivial standard plugins.

Point taken. With the bus and memory speeds of modern workstations, the
conversion is pretty low cost. It does mean extra process() function call
overhead, which starts to get significant with very small buffers, but then
again, you could probably use inline code in the engine instead... (Macros in
the host side headers?)

> One restriction that no one might find objectionable is that the input
> signals and output signals of a plugin both be homogeneous with
> respect to the number of channels.  Then you only need inchannels and
> outchannels parameters for the plugin.  If you want mono, just make
> sure these are both 1 (which could be the default).

I can't fully agree here. What about a stereo compressor with a mono
side-chain? And when considering modular synthesizers, there are control
signals as well, and even though most "modules" would be mono + mono control
signals, the control signals should probably be allowed to have lower sample
rates. That is, signal_fs = audio_fs/n, where n is a power of 2. (Nothing else,
as that would only mean slow conversion code in the plug-ins.)

So, I think there might be a point in allowing mixed signal formats, Rather
than forcing inherent stereo plugs to dual mono just because the want some
independent control signals as well.

> >  > * The sample rate should be optionally settable at instance creation
> >  >   time and the input and output buffer sizes should be optionally
> >  >   settable per call to the process method.  I usually code in a way that
> >  >   can accomodate this, but I agree that it's important to support less
> >  >   flexible plugins as well.
> > 
> >  It's possible to set these things whenever you like.
> >  The plugin programmer can decide which properties can be changed,
> >  and which not. That's what the virtual verify function is all about.
> 
> Hmm..I'm wondering if there should be a harder distinction between
> properties and parameters re mutability.

I think there should be. Some things just can't be changed in a sane way without
destructing and re-creating the plug-in instance.

However, I do think the sample rate is one property that should be possible to
change while processing. Plug-ins aren't required to handle it perfectly, but
they should accept it, and recalculate filters and such accordingly.

For this and other similarly brutal events to work properly in a low latency
environment, there should be a way of switching the plug-in out of real time
context until it's done with the recalculations. If you have a plug-in that
needs to do some nice work on a 2048 sample internal buffer, while the
process() buffer size is 16 samples... BANG! Drop-out!

The plug-in should have a way of telling the engine
   "I can't sort this request out in the time it takes to
    process a buffer! Please call function offline_recalculate()
    for me in your lower priority thread, and send me a message
    with it's return code when it returns."
The plug-in should do something sensible in subsequent process() calls, until
it recieves the message after offline_recalculate()'s return.

BTW, do you know how Cakewalk handles this? Well I do: It doesn't. Any time a
plug-in does something like that, or you insert or remove a plug-in, the entire
engine STALLS until the change has been performed! Useless... Stand-alone units
don't do that to the mixer. And games don't do that when enemies appear or die.

> >  > * To handle resampling, variable output buffer sizes are important.
> >  >   It's also important that the process method can report how many output
> >  >   frames it generated (is this the function of the return value of the
> >  >   process method?).  It may even be important that the plugin can
> >  >   be queried as to how many output frames *will* be generated to avoid
> >  >   overruns due to disagreements about fencepost issues.
> > 
> >  Isn't it enough to have different sizes for input and output buffers ?
> 
> I take back most of this and I think the issue will need some careful
> thought, especially considering David Olofson's comments.

I think specifying the number of extra samples required in the input buffers
cover most situations, but it's still limited in that you can't just decide to
change those figures at any time. The engine may need to catch and recalibrate
for inherent plug-in latencies through large parts of the processing net before
the plug-in in question can get those extra samples. Specifying a maximum
look-ahead value, and then not change it seems reasonable in most cases. But it
may add extra latency for no obvious reason in cases where a plug-in may get
very long internal delay to compensate for with some parameter settings.

> >  > * The popup method should probably be expanded to a vector of generic
> >  >   gui methods.
> >  > 
> > 
> >  As few as possible, but right, we may need more ..... 
> 
> Maybe config_dialog(), show(), hide() and a gui type string?

And here I come again with chainsaw running and Doom-style expression on face!
;-)

Put this stuff in a parallel API. Why do you want it in the same file as the
processing code? You're asking for sync problems...

Why? The processing code will most probably not be called from the same thread
as the user interface code, which means any data access *must* be both thread
and SMP safe! That's not nice code to have inside plug-ins... It belongs in OS
kernels and/or IPC libraries. Or what are you expecting to do from within these
GUI functions, actually?

I'd suggest hacking another API for native code GUIs. The GUI should be aware
of plug-in instances, and communicate with the processing code using this event
system I'm raving about all the time.

Cool bonus: You can have a GUI module that's aware of all instances of the
plug-in class, so you could hack a nice VU-meter bridge, or a multichannel
analyze/control tool that can pick up and affect signals all over the
processing net without the user getting lots of little silly windows all over
the screen.

My GUI system will probably be based on HTML-like markup files (possibly
compiled as an alternative for those nervous closed source guys), with custom
widget plug-ins where needed. That is, you get to use custom plug-ins like the
normal components, telling them where to show up from the markup files. Custom
widgets will basically be a platform independent abstraction for a basic canvas
(drawing surface) widget, so that you can do the usual stuff without digging
deep into the current platform's native graphics subsystem. Any suggestions for
a fast and nice canvas widget to rip out and use for this? (Could use X
directly, but there are those other OSes... Although I don't care much for
most of them.)

Finally, separation is a Good Thing (TM). Even when you don't have to face
sync problems or split environment systems, it has many advantages. Why do
everybody seem to want to go elsewhere?


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Aug 27 22:36:31 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA23111
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 21:25:34 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA14264 for linux-audio-dev-list; Fri, 27 Aug 1999 20:44:06 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA14261 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 20:43:53 -0400
Received: from localhost.localdomain (dialup84-1-10.swipnet.se [130.244.84.10]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA00666; 
          Sat, 28 Aug 1999 02:40:29 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: est@hyperreal.org, Guenter Geiger <geiger@epy.co.at>
Subject: Re: [linux-audio-dev] we should use gtk objects for our plugins
Date: Sat, 28 Aug 1999 02:27:05 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <19990827183703.969.qmail@hyperreal.org>
MIME-Version: 1.0
Message-Id: <99082802452907.01621@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id CAA00666
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA23111
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f3aab1e790939bd0f24f162b1c72ebde

On Fri, 27 Aug 1999, est@hyperreal.org wrote:
> glib, OTOH, is a completely separate question and I'd still recommend
> going with it.  It provides great datatype definitions and has seen
> heavy use on many platforms.  Coding things from scratch has a lot
> less appeal for me than it did when I was younger.  It's always harder
> than it seems and there are always more bugs than expected. :)

Hmm... glib is BIG. And it contains LOTS of code that doesn't have anything at
all to do with what we're doing, and isn't even possible to implement in a
real time safe way, even in user space.

As far as I can see, there isn't really that much that's truly useful, except
for in GUI code. (And GUI code still doesn't belong in the same file as the
processing code... :-)

Using the standard glib means that it gets very easy to use stuff that breaks
user space real time, and prevents plug-ins from even loading under Audiality.
For example, some functions in some libraries (most likely applies to glib as
well) will result in system calls which cannot be resolved in a sane way in
kernel space. And you certainly don't want DSP code to printf() and that kind
of things anyway...

What I'm saying is, glib is a lot of real time unsafe code that we have no
control over. Grab the useful stuff and change anything that isn't real time
safe. The ultimate test of the "rt-glib" specification will be the RTLinux port.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Aug 28 00:36:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA10301
	for <slinkp@ulster.net>; Sat, 28 Aug 1999 00:42:46 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA14607 for linux-audio-dev-list; Sat, 28 Aug 1999 00:04:27 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA14598 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 28 Aug 1999 00:04:22 -0400
Received: from localhost.localdomain (dialup84-12-12.swipnet.se [130.244.84.188]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id GAA10402; 
          Sat, 28 Aug 1999 06:01:20 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: est@hyperreal.org
Subject: Re: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
Date: Sat, 28 Aug 1999 02:50:03 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <19990827185813.26234.qmail@hyperreal.org>
MIME-Version: 1.0
Message-Id: <99082804243008.01621@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id GAA10402
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id AAA10301
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3497d3a3dc5b9e94f3de1d39801879b5

On Fri, 27 Aug 1999, est@hyperreal.org wrote:
> David Olofson discourseth:
> > 
> > > * The only global defined by a plugin should be a uniquely named
> > >   function that returns a plugin class.  The idea here is to make it
> > >   possible to use static as well as dynamic linking.
> > 
> > Nope. For kernel modules, it only makes sense to export init_module()
> > and cleanup_module(), and init_module() has to
> > register_plugin(&audioeff_class) to tell the engine about the new class.
> > This eliminates name space conflicts, as no symbols are exported. Also,
> > a module/library can register multiple plug-in classes this way.
> 
> Ah..but that still precludes static linking.

Ok... I didn't think much, obviously.

It is possible to exclude init/cleanup_module(), so that the object files
don't export anything that would cause name space conflicts. (Not sure if
that's really allowed, though...)

But then the kernel space engine will have to find this uniquely named
function in some way... That is, searching the kernel symbols after the module
has been loaded. Not nice, but possible. A kernel hack shouldn't be needed,
AFAIK.

Just one problem with this unique name... How do we keep track of reserved
names? Or what do you do when you want to link in two proprietary binary-only
plugs, and there's a name conflict? Hmm... Hack a file that you link with one
of those .o files to export the function under a different name? Oh, well. As
long as it's possible to work around, it's ok, as long as it doesn't happen
frequently.

> > > * String parameters should be provided for.
> > 
> > On the contrary, as much as possible of the not directly signal
> > processing related stuff should be kept *out* of the DSP part of the
> > plug-on spec.
> 
> I think this is totally true for many plugins.  However, some plugins
> will *be* gui elements.  Some will even use (shhh) files. :O  These are
> inappropriate for use in rtlinux, but they represent important audio
> processing that many on this list are involved in.

Uh oh... Starts to sound like my GUI plans. Perhaps we should define two APIs
that can be used separately, or together, depending on the nature of the
processing code?

> > 1) Only one interface + subsystem for automation, MIDI-style
> >    events and system control events.
> > 
> > 2) Events and parameter changes are independent of buffer sizes.
> > 
> > 3) *Everything* can be defined in relation to real time.
> >    (A way for plug-ins to tell the engine which events they
> >    support, and their real time characteristics is needed.)
> 
> Hmm..this sounds interesting but radically different from the approach
> Guenter is taking.  Perhaps you should write up a competing proposal?

I will, but I have to get this CD project song ready first... (Kind of feel more
like hacking now, but I have to get this over with.)

> > The basic rule is that the engine gets to decides what sample rate to
> > use. Complex processing nets with plug-ins that have various smart ideas
> > about what sample rates to use just becomes a mess of lost quality and
> > CPU power...
> 
> Sounds good to me.  Does anyone really want sr-specific plugins?
> Perhaps for i/o purposes?

Yes, but that really belongs in the engine, and in the drivers. However, I've
had ideas about using an internal, extended version of the plug-in API for that
kind of things. For example, the multichannel disk streamer could be
implemented as a plug-in that communicates with a thread doing the disk access.
That way, you get the interface to the engine for free. :-)

> > > * To handle resampling, variable output buffer sizes are important.
> > >   It's also important that the process method can report how many output
> > >   frames it generated (is this the function of the return value of the
> > >   process method?).  It may even be important that the plugin can
> > >   be queried as to how many output frames *will* be generated to avoid
> > >   overruns due to disagreements about fencepost issues.
> > 
> > DO NOT adapt output buffer size to the inputs!!! It's doing it all
> > backwards.
> 
> OK, I was on crack when I wrote that.  Honestly, I've always coded to
> the give-me-this-many-output-samples paradigm so I have no idea what I
> was thinking.

Well, I actually thought it would be useful for some things upon a time, but
the recursive engine implementations I thought of to sort it out kind of
made me nervous... Why solve a problem when you can avoid getting there in the
first place? *hehe*

> > The algorithm is: "I need X samples. How many input samples do you need
> > for each channel?"
> > 
> > That's what this section of my little draft is for:
> > 
> >         int look_ahead;         /* Number of extra frames needed
> >                                  * after the end of input buffers.
> >                                  * Can be negative.
> >                                  */
> >         int skip_behind;        /* Number of frames skipped
> >                                  * at the start of input buffers.
> >                                  * (That is, inputs[n]+=look_behind
> >                                  * before process_XXX() is called.)
> >                                  * Can be negative.
> >                                  */
> 
> Can you expand on this?  I'm slow. :)

I don't blame you. It wasn't the first solution to cross my mind... :-)

Let's say we have a simple mono FIR filter plug-in. The FIR filter needs a
window, and will have an inherent latency that depends on the size and shape of
that window.

With VST, we would have to use our own internal buffer to provide the input
data it needs to calculate the samples near the start and end of the buffer.
This complicates the code, and adds unwanted latency that the engine doesn't
know of, and can't compensate for.

|<--- buffer_size -->|
|====================|====================|====================|
               |     |                    |
             ->|_-"-_|<--FIR window       |
               |     |                    |
               |==========================|<-(internal buffer)


Now, let's do it my way... :-)

|<--- output_size -->|
                ->|  |<-- -skip_behind  ->|  |<--look_ahead
|=================|==|====================|==|=================|
                  |     |                    |
                ->|_-"-_|<--FIR_size         |
                  |     |                    |
                  |<----- input buffer ----->|

Here we use a skip_behind of -(FIR_size/2) and a look_ahead of
(FIR_size/2). The result is that we can simply run our filter accross the
input buffer (still output_buffer_size frames!), and the result will
automatically be a complete output buffer. An extra bonus is that we get rid of
the filter phase error as well. :-)

So as long as the input and output signal are of the same sample rate,
	skip_behind = output_pos - input_pos
and 
	look_ahead = input_end_pos - output_end_pos


> > Yes, indeed. Also, it has to be strictly defined *when* you can allocate
> > and free memory, as it's not real time operations.
> 
> Hmm..what kind of predicates would be useful?  Perhaps
> allocs_only_at_init() and alloc_is_param_independent() might help?  I
> think those would be true of many, many pure dsp plugins.  They could
> default to false for plugin authors who don't think about such things.

Sounds reasonable. However, consider that offline_recalculate() thing I
mentioned in another post. It could be used for this too... Actually, two
levels would be nice, one that can still run at hard RT priority in order to
get the recalculations over with ASAP, and one that runs on non RT context, so
that you can reallocate buffers and that kind of stuff. Just return from that
function when you're done, and the process() function will get a message with
your return code. The event should make the plug-in start using the new
buffers (or whatever), and request another offline_recalculate() to dealocate
anything not needed any more.

> > It's possible to
> > design a fast, non fragmenting real time memory manager with a locked
> > memory pool for those who really need it, but dynamic allocation is
> > generally considered a no-no in hard real time systems.
> 
> I think many pure dsp plugins would work fine using a no-op free().
> Just sequentially allocate all their init stuff in a statically
> allocated arena.

I'm not thinking about static stuff... free() is *needed*, or you'll run out of
memory in a short while.

> A tangential question re fragmentation: isn't there always some in a
> malloc()/free() paradigm (assuming your free() does something)?  For
> example, what's the minimal safe-for-space factor for a buddy-block
> system?

The solution is to use a pool of fixed sized blocks that are never split.
Take a look at the kmalloc() (in the Kernel) for an example of the kind of MM
I have in mind. IIRC, it's using buffers of size 128k, 64k, 32k a s o, and you
always get a full buffer. If the manager is out of buffers of the "right" size,
it'll check if there's a bigger buffer free.

Oh, I have one written in C++ lying around at work, BTW. (I'm hacking C++ in
the kernel, that is. Kind of cool when the compatibility stuff is sorted, but
I wouldn't recommend it for new projects.)

> Thanks for being involved, :)

Well, thanks, and the same... :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Aug 27 22:36:36 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA30508
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 22:29:35 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA14400 for linux-audio-dev-list; Fri, 27 Aug 1999 21:53:37 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id VAA14397 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 21:53:35 -0400
From: est@hyperreal.org
Received: (qmail 9350 invoked by uid 162); 28 Aug 1999 01:50:38 -0000
Message-ID: <19990828015038.9349.qmail@hyperreal.org>
Subject: [linux-audio-dev] P3 vs K7
In-Reply-To: <99082800135304.01621@localhost.localdomain> from David Olofson
 at "Aug 28, 1999 00:13:12 am"
To: David Olofson <audiality@swipnet.se>
Date: Fri, 27 Aug 1999 18:50:38 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 45539e8cc1c8c12ae053c5e638a5d2c0

David Olofson discourseth:
> 
> And AMD K7 beats a P-III hands down on the same rate, and is available at up to
> 800 MHz (cooled) right now. That 800 MHz box is nearly twice as fast as a P-III
> 550, which means... some 10 to 15 time what you've got in your box. And that's
> just ONE K7. They support SMP up to 8 or 16 CPUs... (Don't remember the
> figure.)

Interested parties should check out:
tomshardware.com/cpu/99q3/990823/
tomshardware.com/cpu/99q3/990809/

> And, then there's 3DNow! (SIMD - Single Instruction, Multiple Data, which
> means you can process 2 or 4 FP numbers in parallel), which boosts signal
> processing performance a lot. MMX enabled speed-ups between 50% and 400% by
> converting code from normal integer stuff, and 3DNow! should do at least half
> of that improvement for FP.

I find that my naive assembly language can often get a 3x speed-up
from 3dnow.  More attention to instruction scheduling edges it closer
to 4.  There are reasons that the speedup may not be as much in the k7
(i'm using a k6-2), but 2x isn't so bad. :)

> Oh, and AMD added a few special 3DNow! instructions
> suitable for signal processing. AFAIK, one is the multiply-and-accumulate
> instruction that used to be the reason why DSPs are a lot more efficient than
> normal CPUs for signal processing.

I'm afraid it's not there.  There are, however, two new accumulation
modes, two float<->int32 instructions and a swapping move.

Eric

From - Fri Aug 27 23:06:17 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA01733
	for <slinkp@ulster.net>; Fri, 27 Aug 1999 23:04:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA14471 for linux-audio-dev-list; Fri, 27 Aug 1999 22:32:09 -0400
Received: from anime.net (anime.net [205.139.105.150]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA14468 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 27 Aug 1999 22:32:06 -0400
Received: from localhost (goemon@localhost)
	by anime.net (8.9.3/8.9.3) with ESMTP id TAA17177;
	Fri, 27 Aug 1999 19:29:04 -0700
Date: Fri, 27 Aug 1999 19:29:04 -0700 (PDT)
From: Dan Hollis <goemon@sasami.anime.net>
X-Sender: goemon@anime.net
To: David Olofson <audiality@swipnet.se>
cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] problems with plugins?
In-Reply-To: <99082800135304.01621@localhost.localdomain>
Message-ID: <Pine.LNX.4.10.9908271928200.17154-100000@anime.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4cadd9da10b033e538f987c441aa1e06

On Sat, 28 Aug 1999, David Olofson wrote:
> Still worried about power? Well, there's always Alpha AXP, but K7 is cathing up
> on them...

For raw performance HP PA-RISC beats them all. Of course, this is not a
CPU typically found in desktop multimedia PCs...

-Dan

From - Sat Aug 28 00:36:24 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA10127
	for <slinkp@ulster.net>; Sat, 28 Aug 1999 00:41:01 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA14611 for linux-audio-dev-list; Sat, 28 Aug 1999 00:04:32 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA14604 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 28 Aug 1999 00:04:24 -0400
Received: from localhost.localdomain (dialup84-12-12.swipnet.se [130.244.84.188]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id GAA10414; 
          Sat, 28 Aug 1999 06:01:22 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Guenter Geiger <geiger@epy.co.at>, est@hyperreal.org
Subject: Re: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
Date: Sat, 28 Aug 1999 04:32:36 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: Guenter Geiger <geiger@epy.co.at>,
        linux-audio-dev@ginette.musique.umontreal.ca
References: <14278.61292.70284.757058@gige>
MIME-Version: 1.0
Message-Id: <99082804574509.01621@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id GAA10414
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id AAA10127
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 41dbc5a765ae4e5dd57f13b5a2f79737

On Fri, 27 Aug 1999, Guenter Geiger wrote:
> est@hyperreal.org writes:
>  > >  Yep, dynamic allocation, but then, if we want to access (some later added)
>  > >  properties we always have to check if the plugin has allocated memory 
>  > >  for them. 
>  > 
>  > You've got that covered by numproperties.
>  > 
> 
>  Yes, but actually we don't want to expand the number of properties
>  (it's surely not something the plugin should be able to do).
>  The properties are hardcoded into the spezification, they are just
>  like the flags in VST or some variables that have to be set by each
>  plugin.
>  
>  Only in emergency cases (If we find a problem with our plugin API
>  or somthing needs a new kind of plugins they will be extended).
> 
>  But I'm not completely against dynamic allocation ... just some
>  points why it isn't that important here, ...

To me it starts to look like 3 levels are needed:

Properties:
	Hardcoded in the plug-in class.

Parameters:
	"Firmcoded" in a plug-in instance.
	Can be changed, but this may result
	in a non real time response.
	(For example, changing the patch
	on a sampler may require that you
	wait for data to load from disk
	before the plug-in handles further
	events.)

Controls:
	Used for real time control, and
	should *always* be real time.
	(That is, a "controller change"
	event shouldn't result in the
	plug-ins requesting to go off-line
	for half a second...)

The bondaries are still a bit vague, so there should probably be some way to
tell the host what will happen when certain parameters and controls are
changed. Or do these categories cover everything? Need to think some more about
this...

>  > >  > * Change the prefix to something other than `st_' which has too much
>  > >  >   history in unix.  A three-character prefix would be much safer.
>  > >  > 
>  > > 
>  > >  Agreed too, stm_ probably, I'm open to better names for the API too, 
>  > >  strummin doesn't sound very professional, I just thought it's funny.
>  > 
>  > Hmm..I still favor my earlier suggestion of `ops', for `Open Plugin
>  > Specification'.  It's pronouncable, appropriate and short enough for a
>  > prefix.
>  > 
> 
>  ops sounds cool, but .... well Open Plugin Specification sound rather
>   .. not very inventive .. but probably what we need for some people 
>  to accept the API.

OMPIS... Open Multimedia Plug-In Specification. *hehe*

No, seriously, should we try to give a hint as to what the main use of the
standard is, or not? Open Plugin Specification is perhaps a bit too
non-specific, but OpAPS, Open Audio Plug-in Specification probably doesn't
cover all areas where it can be used... Kind of a marketing decision.

>  Ok, if we accept that it's just like adding 
> 
>   DATAfloatstereo
>   DATAint32stereo
>   DATAdoublestereo
>  
>  to the dataformat enum, which is actually contraproductive.
>  We will just get more incompatible plugins.
>  Keeping channels separated in different streams is a more
>  profesional approach, because sometimes I really do think of
>  let's say 4 channel spatialisation .... will this be 2 stereo
>  channels, 4 mono channels , or 4 channel interleaved ?
> 
>  so, I'm still against it, I'd like to hear other comments too.

See my comment on SIMD processing and the cost of splitting/merging... I don't
think it's all that bad really, but my opinion is still that mono signals
make everything more flexible without the complexity. One point to the mono
signal team.

SIMD instructions are cool, though, and organizing the data in the engine
might have some advantages over doing it in the plug-ins. And, as I think I've
stated before (perhaps not here, though), complexity - if it cannot be avoided
altogether - should be in the engine and not in the plug-ins. So that's one
point to the multichannel signal side...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Aug 28 00:36:18 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA10141
	for <slinkp@ulster.net>; Sat, 28 Aug 1999 00:41:04 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA14608 for linux-audio-dev-list; Sat, 28 Aug 1999 00:04:28 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA14603 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 28 Aug 1999 00:04:24 -0400
Received: from localhost.localdomain (dialup84-12-12.swipnet.se [130.244.84.188]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id GAA10425; 
          Sat, 28 Aug 1999 06:01:25 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Kai Vehmanen <kaiv@wakkanet.fi>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] we should use gtk objects for our plugins (fwd)
Date: Sat, 28 Aug 1999 05:00:28 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <%5Oxx3QbB0@sculpcave>
MIME-Version: 1.0
Message-Id: <9908280511440A.01621@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id GAA10425
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id AAA10141
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ee87a13536953e9a4e2fea86bd6b62cf

On Sat, 28 Aug 1999, Kai Vehmanen wrote:
>  >% And hard-realtime or not, this plugin-interface shouldn't get 
>  >% too complex. If this happens, the resulting interface won't
>  >% be adopted by the majority of application/plugin developers. 
> 
> i wanted to write about this.
> there are lotsa more clever/diligent people on this list. i just wanna code
> the "inner loop" of a plugin. and not more. i don't wanna care about
> realtime buffersize-changing, or stuff like that :)

Hard to avoid in some cases... Imagine the evil user wants to use your plug-in
inside a feedback loop in a modular synth. With Audiality, there would have
to be at least one plug-in with delay, as I'm planning on compensating for all
unwanted inherent latencies. If the user decides it would be fun to control the
resonance frequency of that feedback loop with a MIDI controller, you're in for
some fun: the engine may decide to change the buffer size within the loop...

However, this *can* be done in other ways. As long as your buffer size is
smaller than the feedback loop period minus the sum of all inherent latency
compensation, you're fine, so you could actually demand to fix the buffer size
without breaking the engine.

> is it possible to hide these kind of things from the "ordinary laymen",
> like the "majority of application/plugin developers"?

You could specify minimum size, size granularity and other rules for the buffer
size, so that the engine knows what options there are when it tries to get the
net together.

I think it is essential that the API supports this, as there are algorithms
that are just pointless trying to implement on anything but power-of-2 sized
buffers and that kind of things.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Aug 28 00:36:20 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA10128
	for <slinkp@ulster.net>; Sat, 28 Aug 1999 00:41:01 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA14616 for linux-audio-dev-list; Sat, 28 Aug 1999 00:04:37 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA14613 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 28 Aug 1999 00:04:34 -0400
Received: from localhost.localdomain (dialup84-12-12.swipnet.se [130.244.84.188]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id GAA10471; 
          Sat, 28 Aug 1999 06:01:26 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: est@hyperreal.org, eli+@cs.cmu.edu
Subject: Re: [linux-audio-dev] plug-in design space
Date: Sat, 28 Aug 1999 05:17:36 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <19990827220611.4598.qmail@hyperreal.org>
MIME-Version: 1.0
Message-Id: <9908280606370B.01621@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id GAA10471
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id AAA10128
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e823b92d341c6f3fe07809df205e1658

On Sat, 28 Aug 1999, est@hyperreal.org wrote:
> Eli Brandt discourseth:
> > How about a couple of larger-scale design questions before we get down
> > to bits and bytes?
> 
> Basic motivation is a really important question.  In a separate
> posting I described mine: frustration with all the wheel re-invention
> going on.  That definitely leads to different criteria than Designing
> the Right Architecture does.

Yep, prioritizing design over finding out what is actually needed results in
nice solutions addressing non-issues... Everything must be kept in mind at all
times during the design phase.

> >  * Is this for real-time streaming, non-real-time editing, or both?
> > 
> > I vote a big "both".
> 
> I second that!  Wide variation along this dimension is central to our
> community.

Both. And it shouldn't be all that hard taking a pseudo real time system (*)
down to non real time. It's doing it the other way around that's hard or
impossible; yet, people are trying over and over again...

(*) By pseudo real time, I mean that we're not working with the full time
resolution, not even with Audiality/RTLinux. (Well, you *could*, but... what a
waste of CPU cycles!) That is, we're not going to catch one sample, process it,
and then output it. We're dealing with buffers, which means events need time
stamps so that we can tell exactly where they belong. The positive side effect
of this is that timing is moved to the data stream position domain. Non real
time processing comes for free, that is.

> > RT streaming pretty much requires the use of
> > data-pull, walking backwards up the graph:
> > > The algorithm is: "I need X samples. How many input samples do you need
> > > for each channel?"
> > But the answer may be "I dunno, I'll have to see what the values of my
> > inputs are."  A voltage-controlled time-warper, for example.  This
> > works fine in non-RT, where it's more natural to do data-push down the
> > graph.  Support this?

Yep. As long as you can specify how far off the "now" position you'll get,
there's no problem.

The next step is using data streamer that supports bidirectional streaming as
your data source. As long as your plug-in can tell the streamer what to load in
time, the data will be there.

Time travelling isn't planned, though. ;-)

> I think we need to support both even though both might not be used in
> a given app.  My focus is a spec that doesn't get in people's way. :)

And I don't think it will. My skip_behind/look_ahead idea should make quite a
few tricks possible, but you can just ignore those parameters if you're happy
with the VST style approach.

> >  * If non-RT, can output keep running after input has been used up?
> 
> Yeah, we need to specify a drain method.  This could be the same as
> the process method with a 0-size inbuf.

My event system again: Send an event to the plug-in, telling it to say when
it's internal state is drained, and the output will remain silent. The plug-in
will just keep this in mind, and send a reply event when it decides it has
nothing more to output.

> >  * What about sampling rates?
> 
> Well, I expect we'll have fixed-rate and variable rate plugins.  I
> generally code to variable myself.

It's pretty useful in some cases. For example, if all plug-ins used supports
variable sample rate, you can have a system adjust the sample rate after the
CPU load. That is, you'll get a slight treble drop instead of stuttering,
freeze, and emergency engine shutdown if you overload.

> >  * What's static and what's dynamic?
> > 
> > It would be nice to support variable numbers of inputs and outputs: An
> > n-to-m matrix mixer, for example, where n and m are determined upon
> > instantiation of the prototype.
> 
> I'm fond of this sort of thing..but it sure gets complex. :)

The engine would have to change the size of the buffer pointer arrays passed
to the process() function. It would probably be easiest of you can only change
the number of channels - not their order. I think the most complex parts will be
modifying the processing net, and keeping track of things like "the channel
removed was NOT the last one in the list."

> >  * How are feedback loops handled?

See my other post on that. Perhaps I should expand on the engine's part in it as
well...?

> >  * Is each `wire' mono?
> > 
> > Here's where I stepped in.  My leaning is towards mono wires for
> > simplicity.  Performance is not clear to me.
> 
> It can also complicate memory management if all multi-channel code
> has to be rewritten to merge its input streams to become a plugin.

I think supporting both is a good idea for that reason. (And about only that;
mono is the way to go from the design perspective, IMO.) So, the rule is that
you should design your plug-ins as with mono signals, but if you need other
formats for performance reasons (SIMD code for example), you should have the
engine do the conversions for you.

A few point with this...

* The engine need not do any conversion if the
  plug-ins connected happen to fit together.

* Conversion can be optimized in the engine.

* Complexity is moved away from the plug-ins.

> Eli, this is one great set of points/questions!  It's posts like this
> that will create a good spec. :)

Agree! This is exactly what I wanted. :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Aug 28 00:16:18 1999
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id AAA08602
	for <slinkp@ulster.net>; Sat, 28 Aug 1999 00:20:43 -0400
Received: from localhost.localdomain (dialup84-12-12.swipnet.se [130.244.84.188]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id GAA28902; 
          Sat, 28 Aug 1999 06:05:34 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Winkler <slinkp@ulster.net>, Jeff Brown <jeffb@amnh.org>
Subject: Re: [linux-audio-dev] Tracker vs. sequencer
Date: Sat, 28 Aug 1999 06:08:49 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: "linux-audio-dev@ginette.musique.umontreal.ca" <linux-audio-dev@ginette.musique.umontreal.ca>
References: <37C703B3.44A1F7AC@ulster.net>
MIME-Version: 1.0
Message-Id: <9908280610520C.01621@localhost.localdomain>
Content-Transfer-Encoding: 8bit
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d183a07f6dad80d9fd771168c0728d21

On Fri, 27 Aug 1999, Paul Winkler wrote:
> I don't know of any trackers that can be controlled by MIDI; it's all done
> at the computer keyboard. 

Back then, I used some Amiga trackers with MIDI, both input and output. :-)

> I briefly played with trackers a year or two ago, but found them
> simultaneously too clunky to work with and way too inflexible, a
> thoroughly pointless combination IMHO. If I want clunkiness I'll take
> Csound, thanks very much. :)

That's why I got tired of them and started thinking about new ways of doing
it...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Aug 28 00:56:18 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA11328
	for <slinkp@ulster.net>; Sat, 28 Aug 1999 00:58:15 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA14690 for linux-audio-dev-list; Sat, 28 Aug 1999 00:24:29 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA14687 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 28 Aug 1999 00:24:26 -0400
Received: from localhost.localdomain (dialup84-12-12.swipnet.se [130.244.84.188]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id GAA27990; 
          Sat, 28 Aug 1999 06:21:25 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: est@hyperreal.org, Guenter Geiger <geiger@epy.co.at>
Subject: Re: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
Date: Sat, 28 Aug 1999 06:12:44 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <19990827210657.26378.qmail@hyperreal.org>
MIME-Version: 1.0
Message-Id: <9908280626420D.01621@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id GAA27990
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id AAA11328
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f83cfad647a1f097c3461f08388d62aa

On Fri, 27 Aug 1999, est@hyperreal.org wrote:
(...)
> >  Ok, if we accept that it's just like adding 
> > 
> >   DATAfloatstereo
> >   DATAint32stereo
> >   DATAdoublestereo
> >  
> >  to the dataformat enum, 
> 
> ..for various values of nchannels, yes.

I'd like to see that specified as an integer in some kind of data
format descriptor instead....

> > which is actually contraproductive.
> >  We will just get more incompatible plugins.
> 
> We'll get incompatible plugins, yes..*and* we'll get more code reuse.

Don't overestimate this problem! It's not all that expensive to merge/split
channels... But it is a bit more expensive to convert between different sample
formats.

> >  Keeping channels separated in different streams is a more
> >  profesional approach, because sometimes I really do think of
> >  let's say 4 channel spatialisation .... will this be 2 stereo
> >  channels, 4 mono channels , or 4 channel interleaved ?
> 
> These are certainly real downsides.  Our goals and trade-offs may be
> different..and I'd like a spec that accomodates different
> goals..especially given the variety of them on this list. :)

Well, we can always *recommend* developers to use certain formats, while still
supporting nonstandard stuff for those who need it. And conversion is possible
(and should be handled by the *engine*), so if you really want to use a low
quality 16 bit integer games music synth together with your $500 proprietary
plug-ins, go ahead... :-)

I think making it possible to use the same API for as much as possible is a
very good idea (I'm interested in games development as well...), as long as it
doesn't mess up the API and engine implementations too much, or get in the way
of performance in scenarios that *should* be optimal. The possibility of mixing
plug-ins that would otherwise use 150% incomaptible APIs could be a real
strength, even if it means the engine will have to shuffle some bits'n'bytes.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Aug 28 01:02:07 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA11746
	for <slinkp@ulster.net>; Sat, 28 Aug 1999 01:04:32 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA14721 for linux-audio-dev-list; Sat, 28 Aug 1999 00:30:03 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA14718 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 28 Aug 1999 00:30:00 -0400
Received: from localhost.localdomain (dialup84-12-12.swipnet.se [130.244.84.188]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id GAA04462; 
          Sat, 28 Aug 1999 06:26:57 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Dan Hollis <goemon@sasami.anime.net>
Subject: Re: [linux-audio-dev] problems with plugins?
Date: Sat, 28 Aug 1999 06:31:29 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
References: <Pine.LNX.4.10.9908271928200.17154-100000@anime.net>
MIME-Version: 1.0
Message-Id: <9908280632140E.01621@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id GAA04462
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id BAA11746
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c568417318634f57cc2ffcd516ace920

On Sat, 28 Aug 1999, Dan Hollis wrote:
> For raw performance HP PA-RISC beats them all. Of course, this is not a
> CPU typically found in desktop multimedia PCs...

That's the problem... What does that do to the price/performance ratio?


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Aug 28 01:16:18 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA12495
	for <slinkp@ulster.net>; Sat, 28 Aug 1999 01:15:33 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA14744 for linux-audio-dev-list; Sat, 28 Aug 1999 00:43:55 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id AAA14740 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 28 Aug 1999 00:43:52 -0400
From: est@hyperreal.org
Received: (qmail 28345 invoked by uid 162); 28 Aug 1999 04:40:55 -0000
Message-ID: <19990828044055.28344.qmail@hyperreal.org>
Subject: [linux-audio-dev] real-life 3dnow! results
To: audiality@swipnet.se, linux-audio-dev@ginette.musique.umontreal.ca
Date: Fri, 27 Aug 1999 21:40:55 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: ed5ebab37aa5c7de434a00357da6153d

How well does 3dnow measure up to its theoretical speedups?

Here's a real-life measure of application impact.

I took one of the loops I use in oolaboola to convert float data to
little-endian 16-bit data and wrote a 3dnow function to do the same.
Neither of the loops do clipping.

The little-endian-specific C++ loop (compiled with g++ -O2
-funroll-loops -ffast-math) was taking 12-13.5% of some profiling runs
I was doing on my k6-2/350.  The 3dnow version takes 1.12-1.9%.

This may be a commentary on gcc's floating point abilities.  However,
gcc is a tool most of us use.  I think it may also be a commentary on
how horrible the regular x86 fp architecture is.

The fact the 3dnow is fun enough to code that this lisper wrote x86
assembly for the first time in his life this month is also an
important datum. :)

The C++ loop is as follows:

  for (size_t i = 0; i < nfloats; i++)
    *out16++ = static_cast<int16_t>(*in++ * 32766);

I've appended the 3dnow routine.  It took under half-an-hour to get
into its present shape (I'd put down the 3dnow for a couple of weeks
:)

Note that the routine hasn't had any loop-interleaving or instruction
scheduling done on it.  That would probably speed it up.  Also note
that the same approach will work well for conversion to 24 and 32 bit
quantities.

Clipping should be easy to add since 3dnow has parallel max and min
operations. :)

I'd like experienced x86 asm hackers to help me with two things: 1)
Improve the existing code and 2) Provide me with a pure x86 fp
equivalent to test it against.

Once I find/write an autoconf test for 3dnow, things like this could
perhaps go into Erik's library. :)

Digital filters now take over half oola's cycles and seem like a
worthy target for the future.

Eric

.bss
.data
        .align 4
fint16: .single 32766,32766

.text
        .align 32
# this converts 4xn floats (in range -1.0..1.0) to le16 values
# extern "C" convert2_3dnow(const float *in, size_t n, int16_t *out);
.globl convert2_3dnow
convert2_3dnow:
        pushl %ebp
        pushl %eax
        pushl %ecx
        pushl %ebx

        movl 20(%esp),%eax
        movl 24(%esp),%ecx
        movl 28(%esp),%ebp

        # grab some scratch space
        subl $8,%esp

        femms

        movq fint16,%mm2
myloop:
        movq (%eax),%mm0
        pfmul %mm2,%mm0
        pf2id %mm0,%mm1
        movq %mm1,(%esp)
        movw (%esp),%ebx
        movw %ebx,(%ebp)
        movw 4(%esp),%ebx
        movw %ebx,2(%ebp)
        addl $4,%ebp
        addl $8,%eax

        # for now, just do this once more
        # later, interleave and schedule
        movq (%eax),%mm0
        pfmul %mm2,%mm0
        pf2id %mm0,%mm1
        movq %mm1,(%esp)
        movw (%esp),%ebx
        movw %ebx,(%ebp)
        movw 4(%esp),%ebx
        movw %ebx,2(%ebp)
        addl $4,%ebp
        addl $8,%eax

        loop myloop

        femms

        addl $8,%esp

        popl %ebx
        popl %ecx
        popl %eax
        popl %ebp

        ret

From - Sat Aug 28 10:50:36 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id CAA17191
	for <slinkp@ulster.net>; Sat, 28 Aug 1999 02:37:36 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id CAA14845 for linux-audio-dev-list; Sat, 28 Aug 1999 02:02:31 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id CAA14842 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 28 Aug 1999 02:02:28 -0400
From: est@hyperreal.org
Received: (qmail 3747 invoked by uid 162); 28 Aug 1999 05:59:31 -0000
Message-ID: <19990828055931.3746.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] real-life 3dnow! results
In-Reply-To: <19990828044055.28344.qmail@hyperreal.org> from "est@hyperreal.org"
 at "Aug 27, 1999 09:40:55 pm"
To: est@hyperreal.org
Date: Fri, 27 Aug 1999 22:59:31 -0700 (PDT)
CC: audiality@swipnet.se, linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7e111bbb12a6b0a1c53d1f451d4c5e66

I'm continuing in my grand tradition of replying to myself. :)

I looked at Intel's online mmx manual and found an instruction that
cleans up my code a lot.  It doesn't seem to speed things up much, but
it *does* add clipping.  It also makes other code optimizations easier.

Simply replace the following code chunk (which appears twice):

>         movq %mm1,(%esp)
>         movw (%esp),%ebx
>         movw %ebx,(%ebp)
>         movw 4(%esp),%ebx
>         movw %ebx,2(%ebp)

with:

        packssdw %mm1,%mm1
        movd %mm1,(%ebp)

The scratch space on the stack is no longer needed.

Eric

From - Sat Aug 28 10:50:40 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id CAA17854
	for <slinkp@ulster.net>; Sat, 28 Aug 1999 02:53:52 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id CAA14890 for linux-audio-dev-list; Sat, 28 Aug 1999 02:21:19 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id CAA14887 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 28 Aug 1999 02:21:14 -0400
From: est@hyperreal.org
Received: (qmail 15153 invoked by uid 162); 28 Aug 1999 06:18:16 -0000
Message-ID: <19990828061816.15152.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] real-life 3dnow! results
In-Reply-To: <19990828055931.3746.qmail@hyperreal.org> from "est@hyperreal.org"
 at "Aug 27, 1999 10:59:31 pm"
To: est@hyperreal.org
Date: Fri, 27 Aug 1999 23:18:16 -0700 (PDT)
CC: audiality@swipnet.se, linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0dd0265fa13805f58508829dfb87ec96

est@hyperreal.org discourseth:
> 
> I looked at Intel's online mmx manual and found an instruction that
> cleans up my code a lot.  It doesn't seem to speed things up much, but
> it *does* add clipping.  It also makes other code optimizations easier.

Such as gaining a further 1.5- to 2-fold speedup by morphing the inner
loop into:

myloop:
        movq (%eax),%mm0
        pfmul %mm2,%mm0
        movq 8(%eax),%mm3
        pf2id %mm0,%mm1
        pfmul %mm2,%mm3
        packssdw %mm1,%mm1
        pf2id %mm3,%mm4
        movd %mm1,(%ebp)
        packssdw %mm4,%mm4
        addl $16,%eax
        movd %mm4,4(%ebp)
        addl $8,%ebp

        loop myloop

Further streamlining is possible..and scary. :)

Eric

From - Sat Aug 28 10:50:44 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA27208
	for <slinkp@ulster.net>; Sat, 28 Aug 1999 07:21:48 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA15293 for linux-audio-dev-list; Sat, 28 Aug 1999 06:43:35 -0400
Received: from epy.co.at (epy.co.at [62.116.9.24]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA15290 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 28 Aug 1999 06:43:31 -0400
Received: from localhost (geiger@localhost)
	by epy.co.at (8.9.3/8.9.3) with ESMTP id MAA06211;
	Sat, 28 Aug 1999 12:39:47 +0200
Date: Sat, 28 Aug 1999 12:39:47 +0200 (CEST)
From: guenter geiger <geiger@epy.co.at>
To: David Olofson <audiality@swipnet.se>
cc: Kai Vehmanen <kaiv@wakkanet.fi>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] we should use gtk objects for our plugins
 (fwd)
In-Reply-To: <9908280511440A.01621@localhost.localdomain>
Message-ID: <Pine.LNX.4.03.9908281217350.5905-100000@epy.co.at>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 89eb2bb35ca4fc1a5f9f9fd67536569b



On Sat, 28 Aug 1999, David Olofson wrote:
> Hard to avoid in some cases... Imagine the evil user wants to use your plug-in
> inside a feedback loop in a modular synth. With Audiality, there would have

My point is, that feedback loops belong into the plugins process routine
and should not be created using multiple plugins. 

> You could specify minimum size, size granularity and other rules for the buffer
> size, so that the engine knows what options there are when it tries to get the
> net together.
> 
> I think it is essential that the API supports this, as there are algorithms
> that are just pointless trying to implement on anything but power-of-2 sized
> buffers and that kind of things.
> 

My idea about this was, to make this range checking a plugin feature.
The application just asks for a buffer size via the virtual "verify"
function.

There is a default function ion the plugin which implements a standard
behaviour.
e.g samplerate can always be changed, buffersize too, Dataformat 
never, number of inputs, outputs never.

If I write a plugin which only accepts 2^n samples buffersize, I have to
add a check for that property to the verify function.

If I want to support 1,2,3,n channels, I can add this to the verify
function.

This is easy for both parts. The plugin developer can check whatever he
likes (The concept is valid for every property actually), so supporting
only three samplerates is easy as well as supporting a range from 32000
upwards.

The application doesn't have to check against minimal and maximal and
subdivision values, we don't have to define extra variables for that ...

Properties are values which every plugin has.
The way I see it, properties should never be changed during operation,
though.

Maybe there's a way to implement it, but I don't actually see the point
why someone wants to change for example the samplerate during operation.

Parameters (in my implementation) are equivalent to what David calls
controls (e.g not every plugin will have a delay line length control,
but the echo effect does).

I see that the implementation of the controls is rather limited (it's the
same as in VST), so I would like to discuss that further, probably I will
understand how this will work with the events system.


Guenter

From - Sat Aug 28 10:50:48 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id IAA00495
	for <slinkp@ulster.net>; Sat, 28 Aug 1999 08:53:10 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA15397 for linux-audio-dev-list; Sat, 28 Aug 1999 08:13:30 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA15394 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 28 Aug 1999 08:13:27 -0400
Received: from localhost.localdomain (dialup85-5-12.swipnet.se [130.244.85.76]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id OAA20832; 
          Sat, 28 Aug 1999 14:10:18 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: guenter geiger <geiger@epy.co.at>
Subject: Re: [linux-audio-dev] we should use gtk objects for our plugins (fwd)
Date: Sat, 28 Aug 1999 13:53:09 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: Kai Vehmanen <kaiv@wakkanet.fi>,
        linux-audio-dev@ginette.musique.umontreal.ca
References: <Pine.LNX.4.03.9908281217350.5905-100000@epy.co.at>
MIME-Version: 1.0
Message-Id: <99082814153800.00438@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id OAA20832
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id IAA00495
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: bc72c665459271c714c62ef015e0839d

On Sat, 28 Aug 1999, guenter geiger wrote:
> On Sat, 28 Aug 1999, David Olofson wrote:
> > Hard to avoid in some cases... Imagine the evil user wants to use your plug-in
> > inside a feedback loop in a modular synth. With Audiality, there would have
> 
> My point is, that feedback loops belong into the plugins process routine
> and should not be created using multiple plugins. 

So, how would you build a modular synthesizer application? Another custom
plug-in system? No thanks, that's exactly what I'm trying to avoid.

True, it's a waste of CPU power connecting the modules at run time, but many
users are NOT going to hack their own plug-ins. And being able to do it runtime
gives you a great prototyping tool.

> > You could specify minimum size, size granularity and other rules for the buffer
> > size, so that the engine knows what options there are when it tries to get the
> > net together.
> > 
> > I think it is essential that the API supports this, as there are algorithms
> > that are just pointless trying to implement on anything but power-of-2 sized
> > buffers and that kind of things.
> > 
> 
> My idea about this was, to make this range checking a plugin feature.
> The application just asks for a buffer size via the virtual "verify"
> function.

Yep, that's one way to do it. However, it means extra function calls if the
engine wants to change buffer size frequently (minor problem)... And whay
happens if the plug-in refuses to accept the new buffer size? What should the
engine do next?

The verify mechanism must be able to accept more descriptive requests than just
a number, and it should reply with the best supported alternative according to
the request. That is, if the engine wants a certain buffer size, it should be
able to specify that "this is the maximum/minimum size", that "the size must
be a power of 2" and so on. The best alternative, or an error code should be
returned.

> There is a default function ion the plugin which implements a standard
> behaviour.
> e.g samplerate can always be changed, buffersize too, Dataformat 
> never, number of inputs, outputs never.
> 
> If I write a plugin which only accepts 2^n samples buffersize, I have to
> add a check for that property to the verify function.
> 
> If I want to support 1,2,3,n channels, I can add this to the verify
> function.
> 
> This is easy for both parts. The plugin developer can check whatever he
> likes (The concept is valid for every property actually), so supporting
> only three samplerates is easy as well as supporting a range from 32000
> upwards.

Yep, but the engine must be do something sensible of verify fails... Guessing
again is not an option.

> The application doesn't have to check against minimal and maximal and
> subdivision values, we don't have to define extra variables for that ...

No, that should be handled by the plug-in. A lot more flexible.

> Properties are values which every plugin has.
> The way I see it, properties should never be changed during operation,
> though.
> 
> Maybe there's a way to implement it, but I don't actually see the point
> why someone wants to change for example the samplerate during operation.

I gave an example of that, right? That's being done on many old samplers, BTW.
GUS does it too... Nice alternative to fiddling with the engine configuration
over and ofer again, just to listen to this project you created on a faster
computer.

> Parameters (in my implementation) are equivalent to what David calls
> controls (e.g not every plugin will have a delay line length control,
> but the echo effect does).
> 
> I see that the implementation of the controls is rather limited (it's the
> same as in VST), so I would like to discuss that further, probably I will
> understand how this will work with the events system.

Will expand futher on that, and hack some declarations.

Anyway, there's one big advantage with events over "direct access controls";
well defined timing. You can send trigger events, as well as events that just
change a control. It covers everything from starting one-shot actions inside
plug-ins through to implementing low frequency control signals. (That's where
low frequency signals should take over from the event system, so that audio
processing plugs can be used to process control signals.)

BTW, one thing that comes with the event system; plug-ins with no inputs or
outputs become a valid and useful. MIDI effects, sequencers, event routers etc,
using the very same API. :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Mon Aug 30 18:41:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA11320
	for <slinkp@ulster.net>; Sat, 28 Aug 1999 16:19:48 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA15932 for linux-audio-dev-list; Sat, 28 Aug 1999 15:44:45 -0400
Received: from sculpcave.localdomain (cvx-1-62.dyn.nic.fi [62.236.97.62]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA15929 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 28 Aug 1999 15:44:40 -0400
Received: (from root@localhost)
	by sculpcave.localdomain (8.8.7/8.8.7) id QAA01232;
	Sat, 28 Aug 1999 16:10:22 +0300
Date: Sat, 28 Aug 1999 16:10:22 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
To: est@hyperreal.org
cc: Guenter Geiger <geiger@epy.co.at>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
In-Reply-To: <19990827205522.10772.qmail@hyperreal.org>
Message-ID: <%q19x341A7@sculpcave>
X-User-Agent: Mana 4.0beta (Linux)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 75af6466e63bd04ada23be55b70a8158

On Fri, 27 Aug 1999, est@hyperreal.org wrote:

>>  I think we should keep any GUI stuff out of the API as good
>>  as possible.
> OK.  Here's a simplifying suggestion.  Two fields: 1) a gui type
> string and 2) an opaque gui data pointer.

In ecasound, all effects must implement functions for getting and
setting parameters, getting number of parameters and getting parameter
names (+ effect name of course). This info is all I need for building 
a effect-GUI (= widget that show all effect params, their names, etc.).

-- 
Kai Vehmanen ----------------------------- CS, University of Turku, Finland
 : email                                 mailto:kaiv@wakkanet.fi
 : audio processing for linux            http://www.wakkanet.fi/ecasound/
 : my music (ambient-idm-rock-...mp3/ra) http://www.wakkanet.fi/sculpscape/


From - Mon Aug 30 18:41:36 1999
Received: from sculpcave.localdomain (IDENT:root@cvx-1-62.dyn.nic.fi [62.236.97.62])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id PAA08862
	for <slinkp@ulster.net>; Sat, 28 Aug 1999 15:57:20 -0400
Received: (from root@localhost)
	by sculpcave.localdomain (8.8.7/8.8.7) id QAA01269;
	Sat, 28 Aug 1999 16:37:53 +0300
Date: Sat, 28 Aug 1999 16:37:53 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
To: Paul Winkler <slinkp@ulster.net>
cc: Jeff Brown <jeffb@amnh.org>,
        "linux-audio-dev@ginette.musique.umontreal.ca" <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Tracker vs. sequencer
In-Reply-To: <37C703B3.44A1F7AC@ulster.net>
Message-ID: <%k-9x341A8@sculpcave>
X-User-Agent: Mana 4.0beta (Linux)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: bb2d291f417f77a4aa24e32e2d3a2a85

On Fri, 27 Aug 1999, Paul Winkler wrote:

> Jeff Brown wrote:
>> I've never heard the term "tracker" before.  What's the difference?
>> What's are a few examples of both?
> "Trackers" are descendants of the Amiga MOD / "demo" scene. Examples are
> ImpulseTracker, FastTracker2, and (on Linux) FunkTracker Gold and

If you want to try one, definitely try out Michael Krause's
SoundTracker for Linux (named after the original Amiga program that
started the whole tracker scene). I've used trackers since the
original Amiga version of ST and this new Linux version of
SoundTracker is _really_ good. 

> columns. The note events are triggered sound samples. They usually have
> little or no processing capability, just play the samples at different
> pitches with maybe some envelope control and pitch modulation.

All modern trackers support multi-sample instruments with amplitude
and pan envelopes. Newer ones also have more DSP processing capability.

> don't know of any trackers that can be controlled by MIDI; it's all done
> at the computer keyboard. 

At least FastTracker2 offered MIDI-control. I didn't have any
MIDI-gear when I had a Amiga, but at least OktaMed offered advanced 
features by combining MIDI/tracker -sequencer functionality. 
SoundTracker/Linux doesn't offer this yet, but I'll have a go at it 
if I get the time...

> I briefly played with trackers a year or two ago, but found them
> simultaneously too clunky to work with and way too inflexible, a
> thoroughly pointless combination IMHO. If I want clunkiness I'll take

Here I have to disagree. When you want to do _creative_ work with 
computers, interface is always the biggest problem. Even with a good
interface, it always takes a lot of time to get used to it. Tracker
intercace is clunky, yes, but it has become a standard. Once I learn
to use one, I can use them all. 

-- 
Kai Vehmanen ----------------------------- CS, University of Turku, Finland
 : email                                 mailto:kaiv@wakkanet.fi
 : audio processing for linux            http://www.wakkanet.fi/ecasound/
 : my music (ambient-idm-rock-...mp3/ra) http://www.wakkanet.fi/sculpscape/



From - Sat Aug 28 12:58:07 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA23831
	for <slinkp@ulster.net>; Sat, 28 Aug 1999 12:56:48 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA15671 for linux-audio-dev-list; Sat, 28 Aug 1999 12:17:03 -0400
Received: from chekov.Belgium.EU.net (chekov.belgium.eu.net [193.74.208.161]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA15668 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 28 Aug 1999 12:16:59 -0400
Received: from (adial159.liege.eunet.be [195.207.174.159])
	by chekov.Belgium.EU.net  with SMTP id SAA05282 
	for <linux-audio-dev@ginette.musique.umontreal.ca>;
	Sat, 28 Aug 1999 18:13:51 +0200 (MET DST)
From: "Benjamin GOLINVAUX" <golinvaux@benjamin.net>
To: <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] audio card for linux (and audiality ?)
Date: Sat, 28 Aug 1999 18:12:56 +0200
Message-ID: <NDBBINHOEMHEFBPJLABAOEKHCAAA.golinvaux@benjamin.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <99082814153800.00438@localhost.localdomain>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8003
X-Mozilla-Status2: 00000000
X-UIDL: 0fc28586fecbaf67f608c1a857f4da02

Hi,

I've been following mith much attention these discussions about plug-ins
interfaces and in particular, audiality.

I'd like to break in to ask a _very_ silly question :

although it would be very nice to have a good architecture for low-latency
plugins, do you know of a _single_ good audio card running under Linux to
use them professionnaly ?

What I'd like to have is a very straightforward direct-to-disk application
with the same kind of reliability found on early direct to disk systems
running on ST (that is, a very elementary system)...

The purpose of this is to record (and process real-time with some fancy
effects I'd like to write) audio and play it back, possibly during live
performances...

To achieve that, what I need is a stable OS (with low latency if I want to
do processing in addition of basic recording/playing).

stable : Linux
low latency : RTLinux (audiality ?)

the problem is : on which device am I going to record and play sound ?

You guys seem to be deeply involved in Linux audio... Do I understand you
are working with game devices such as SB PCI 128 or Opti931 ?

Well... don't get me wrong : one doesn't need a zillion dB SNR do make good
stuff... but I'd really like to have sync'ed multitrack (that is, not
putting more than one clock for ADC and DAC in my system <-> ONE card) with
pro quality and connectors (24 bits with sym. XLR or adat/spdif).

If no good card is supported, does someone know of a _single_ good card (all
digital is ok) with specs released somewhere ? (zefiro ZA2 ?).

OSS commercial promises support for some cards but not a single good card is
supported, am I wrong ? (sonorus audi/o : any clue ?)

ALSA does not support good cards either (although ALSA people have made
great work)

This is why I'm hacking with BeOS at the moment (promised driver for Echo
Layla)... but the soft-real time caps don't suit me (furthermore, although
the OS is stable, the audio server is not that stable)...

I have another question that's still more stupid (Don't flame me, being
given I'm not _at all_ a driver programmer)... Would it be theoretically AND
practically possible to use BINARY DirectSound, Multimedia (Wave) or ASIO
drivers under linux with some compatibility layer ? I've heard David saying
that his audiality engine can use oss commercial binary drivers provided it
uses a restricted set of commands... Could it be possible ? (with the
windows DDK manual)

Thanks for reading.





From - Mon Aug 30 18:41:34 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA00905
	for <slinkp@ulster.net>; Sat, 28 Aug 1999 14:32:07 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA15782 for linux-audio-dev-list; Sat, 28 Aug 1999 14:00:09 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA15779 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 28 Aug 1999 14:00:07 -0400
Received: from ulster.net (annex3-port5.ulster.net [208.133.194.5])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id OAA31606;
	Sat, 28 Aug 1999 14:12:09 -0400
Message-ID: <37C82498.B7DE7429@ulster.net>
Date: Sat, 28 Aug 1999 14:04:08 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Benjamin GOLINVAUX <golinvaux@benjamin.net>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] audio card for linux (and audiality ?)
References: <NDBBINHOEMHEFBPJLABAOEKHCAAA.golinvaux@benjamin.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ecd3a527b2b5688a39e5144c1d0b275d

Benjamin GOLINVAUX wrote:
> 
> Hi,
> 
> I've been following mith much attention these discussions about plug-ins
> interfaces and in particular, audiality.
> 
> I'd like to break in to ask a _very_ silly question :
> 
> although it would be very nice to have a good architecture for low-latency
> plugins, do you know of a _single_ good audio card running under Linux to
> use them professionnaly ?

I _wish_ this was a silly question.

All information I currently have about this is here:
http://www.ulster.net/~abigoo/pw_linux/Audio-Quality-HOWTO.html

There are some supported cards with digital outs, and a very few with
digital ins. I know of _nothing_ with multitrack inputs and hardly
anything with multitrack outs.

Anyone with any more information is encouraged to send it to me for
inclusion in the HOWTO (though I've been lax about updating it this
month).

----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Mon Aug 30 18:41:42 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA17936
	for <slinkp@ulster.net>; Sat, 28 Aug 1999 17:33:00 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA16062 for linux-audio-dev-list; Sat, 28 Aug 1999 16:55:11 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA16059 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 28 Aug 1999 16:55:08 -0400
Received: from localhost.localdomain (dialup88-11-10.swipnet.se [130.244.88.170]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id WAA17267; 
          Sat, 28 Aug 1999 22:52:02 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: "Benjamin GOLINVAUX" <golinvaux@benjamin.net>,
        <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] audio card for linux (and audiality ?)
Date: Sat, 28 Aug 1999 21:56:28 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <NDBBINHOEMHEFBPJLABAOEKHCAAA.golinvaux@benjamin.net>
MIME-Version: 1.0
Message-Id: <99082822572101.00620@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id WAA17267
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id RAA17936
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b5ce858b6dda7f7ea772c9a1089c84ed

On Sat, 28 Aug 1999, Benjamin GOLINVAUX wrote:
> To achieve that, what I need is a stable OS (with low latency if I want to
> do processing in addition of basic recording/playing).
> 
> stable : Linux
> low latency : RTLinux (audiality ?)

It seems that Linux will soon be able to provide "very firm" hard real time in
user space, with Mingo's patches. (The ones Benno Senoner is testing.) The
performance seems very reliable so far (*never* a scheduling latency peak higher
than the occasional 2.9 ms one!), so if you can do with some 4-7 ms of latency
(depending on how much CPU power you need to use), you won't need RTLinux.

WITH RTLinux, however, jitter is reduced to incredibly low values (peak 25 us
on a heavily stressed P120 according to Zentropix [www.zentropix.com], around 5
us on Celeron and P-II boxes according to users on the RTL list), so the only
obstacle when trying to get lower latency is the sound card hardware: Many
cards cannot DMA less than 32 bytes at a time and similar figures...

I'm a bit short of time ATM (due to a song I must get recorded and mixed this
weekend), but after that, I'll go back to Audiality hacking (the Driver
Programming Interface layer first of all) and do some real contributing to this
plug-in API.

I'll do some benchmarking on the RTL AudioPCI driver, and I'll also try other,
non-PCI cards, as they usually don't have the DMA burst size limitation.

Latest figures with AudioPCI:
             fragment size: 32 bytes (DMA burst limit)
               sample rate: 44100 Hz
             sample format: 16 bit stereo
         read/write buffer: 36 bytes

 resulting in->out latency: 64 bytes; around .4 ms.

I stressed the disk and X some, and as expected, this had no effect on the real
time code. Rock solid. I'll do more thorugh testing and also measure the total
analog -> analog latency of the card. (I'd like to know how much the
converters and digital filters add...)

> the problem is : on which device am I going to record and play sound ?
> 
> You guys seem to be deeply involved in Linux audio... Do I understand you
> are working with game devices such as SB PCI 128 or Opti931 ?

Well, I am, as I need drivers with source, or audio cards with specs... I have
a Layla for my music, and I'd *really* like to see some specs, or at least a
binary driver.

We hope that our efforts for getting better multimedia performance out of Linux,
and uniting UNIX audio software through the new plug-in API, will make Linux a
more interesting to hardware and software developers in the near future. Some
of the Big Guys are porting to BeOS, but many don't like BeOS because of it's
proprietary nature, and the risk of it ending up like all other high quality
products: killed by FUD and crap software. Why should they not consider Linux
at the time we can provide far superior performance and a flexible plug-in API
with Open Source plug-ins and engines to look at?

> OSS commercial promises support for some cards but not a single good card is
> supported, am I wrong ? (sonorus audi/o : any clue ?)

Some old pro cards are supported by commercial OSS, but I haven't heard much
about it. I think you should be able to get something together, but there's not
many cards to chose from...

> This is why I'm hacking with BeOS at the moment (promised driver for Echo
> Layla)... but the soft-real time caps don't suit me (furthermore, although
> the OS is stable, the audio server is not that stable)...

Do you have any scheduling jitter benchmark data? We're very interested in
getting some real facts. "3 ms latency with Layla" sounds good, but I would
like to know if it's reliable, if you can load the CPU in the real time thread,
if it's input -> output, or just thread -> output etc... In short: Is it a real
figure, or are they cheating like everyone else? (Except for us; we don't need
to cheat. We just fix the problem. :-)

> I have another question that's still more stupid (Don't flame me, being
> given I'm not _at all_ a driver programmer)... Would it be theoretically AND
> practically possible to use BINARY DirectSound, Multimedia (Wave) or ASIO
> drivers under linux with some compatibility layer ?

Possibly ASIO; the others are so incredibly Windoze specific, as anything else
that's designed by M$. In any case, none of those would fit very well with
the UNIX driver architecture we use around here, so it wouldn't become too
popular...

> I've heard David saying
> that his audiality engine can use oss commercial binary drivers provided it
> uses a restricted set of commands... Could it be possible ? (with the
> windows DDK manual)

The reason why non-RTLinux drivers can still be used for hard real time I/O is
mmap(). And the card + driver really *has* to map a real DMA or direct access
buffer into the system's address space, or it will be pointless. Hardware that
requires the driver to do something to read or write every buffer is limited
to the buffer rate the driver can handle. It needs to be ported to RTLinux for
RTLinux performance. If non-Linux binary drivers could be used, the same
applies. Most consumer level cards should be able to mmap() correctly, but the
high end cards tend to use higher level protocols involving DSPs (with
downloaded firmware), which is NOT good in this case...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Mon Aug 30 18:41:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA12616
	for <slinkp@ulster.net>; Sat, 28 Aug 1999 16:34:01 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA15979 for linux-audio-dev-list; Sat, 28 Aug 1999 16:00:49 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA15976 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 28 Aug 1999 16:00:46 -0400
Received: from localhost.localdomain (dialup105-5-13.swipnet.se [130.244.105.77]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id VAA05434 for <linux-audio-dev@ginette.musique.umontreal.ca>; 
          Sat, 28 Aug 1999 21:57:44 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Fwd: Low-latency patches working GREAT (<2.9ms audio latency), see testresults ,but ISDN troubles
Date: Sat, 28 Aug 1999 22:01:14 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <99082822030300.00620@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id VAA05434
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id QAA12616
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 92ed3dd1e899d14448669136d1225cd0

Benno Senoner's latest post to various lists... :-)


//David


----------  Forwarded Message  ----------
Subject: Low-latency patches working GREAT (<2.9ms audio latency), see testresults ,but ISDN troubles
Date: Sat, 28 Aug 1999 22:40:57 +0200
From: Benno Senoner <sbenno@gardena.net>


Hi,

I benchmarked Mingo's latest low-latency patches (2.2.10-N6 a bit modified)

The patches give me excellent results with sporadic very 2.9ms peaks !

See the testresults here:
http://www.gardena.net/benno/linux/audio/2.2.10-n6b/index.html

You can get the patch here:
http://www.gardena.net/benno/linux/audio/patches/lowlatency-2.2.10-N6B.patch

More details on my audio page.

Unfortunately the patch has still some problems , not latency-related:

- The ISDN hisax driver (my card is a Fritz classic) crashes the kernel at
modprobe hisax.o
(does not happen on an unpatched 2.2.10 kernel)   
Can someone of the ISDN maintainers please reproduce/fix this ?
(maybe a race at module initialization ?) 

- The disk performance decreases by 10-25% when I increase the CPU load in
the "latencytest" bench.
(On light CPU load there are no disk performance differences,
maybe this is related to higher scheduling overhead)

I think most of us want to have these "low-latency" features in the upcoming
2.4 kernel since it will make Linux a very good _MULTIMEDIA_OS_.

With Mingo's patches the Linux low-latency performance comes very close
to BEOS, and is much much better (3-4 times) Windows on the same hardware.
It's now time to stress audio-software vendors to port their cool apps to Linux.

comments ?


PS: To Microsoft's Anti-Linux team: just download the patch and compare the
performance with your crappy DirectX API :-)

regards,
Benno.


--
Benno Senoner
E-Mail: sbenno@gardena.net
Linux scheduling latency benchmarks
http://www.gardena.net/benno/linux/audio



 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Mon Aug 30 18:41:50 1999
Received: from anime.net (IDENT:root@anime.net [205.139.105.150])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id VAA03807
	for <slinkp@ulster.net>; Sat, 28 Aug 1999 21:06:54 -0400
Received: from localhost (goemon@localhost)
	by anime.net (8.9.3/8.9.3) with ESMTP id RAA23552;
	Sat, 28 Aug 1999 17:51:34 -0700
Date: Sat, 28 Aug 1999 17:51:34 -0700 (PDT)
From: Dan Hollis <goemon@sasami.anime.net>
X-Sender: goemon@anime.net
To: Paul Winkler <slinkp@ulster.net>
cc: Benjamin GOLINVAUX <golinvaux@benjamin.net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] audio card for linux (and audiality ?)
In-Reply-To: <37C82498.B7DE7429@ulster.net>
Message-ID: <Pine.LNX.4.10.9908281748440.23524-100000@anime.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 44ae2b935d589bc89725d31ba9c6b9da

On Sat, 28 Aug 1999, Paul Winkler wrote:
> All information I currently have about this is here:
> http://www.ulster.net/~abigoo/pw_linux/Audio-Quality-HOWTO.html
> There are some supported cards with digital outs, and a very few with
> digital ins. I know of _nothing_ with multitrack inputs and hardly
> anything with multitrack outs.

Correction to the Hoontech 4dwave entry: it only has S/PDIF out - not in.

-Dan

From - Mon Aug 30 18:41:53 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA23116
	for <slinkp@ulster.net>; Sun, 29 Aug 1999 00:40:34 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA16547 for linux-audio-dev-list; Sat, 28 Aug 1999 23:56:09 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA16544 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 28 Aug 1999 23:56:07 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id XAA22164
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 28 Aug 1999 23:52:08 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id XAA06396; Sat, 28 Aug 1999 23:52:09 -0400 (EDT)
Date: Sat, 28 Aug 1999 23:52:02 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Tracker vs. sequencer
In-Reply-To: <37C6E52E.4C290C6F@amnh.org>
Message-ID: <Pine.GSO.4.10.9908282336590.6176-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 030d56c33c34cf779517c9727bb28748

On Fri, 27 Aug 1999, Jeff Brown wrote:

> I've never heard the term "tracker" before.  What's the difference? 
> What's are a few examples of both?

A tracker is the type of program used to create MOD files (rather than
MIDI).  They started out on the Amiga and later moved to DOS.  Like a MIDI
sequencer, a tracker lets you create a song by saying what events happen
when.  The difference (at least the one to which I was referring)  is that
in a sequencer, a song is made up of events, but in a tracker, a song is
made up of patterns, which in turn are made up of events.  A pattern is
basically a phrase, although it could be used to represent a whole verse.

This relatively inflexible, single level of structure is, I believe, 
singlehandedly responsible for the fact that 90% of the music created with
trackers falls in the techno genre.  The pattern structure just seems best
suited to techno.  (I have heard a few very nice non-techno MODs along the
way, but they're a tiny minority.)

The two sequencers with which I've worked most are Cakewalk and Master
Tracks Pro, neither of which is (or at least originally was, in Cakewalk's
case) pattern-based, like a tracker.  They do not impose any structure on
the music that isn't inherent in the MIDI standard (like channels and
tracks).  However, Cubase, Vision, Logic, and more recent versions of
Cakewalk all do their best to add pattern-based structure on top of the
flat MIDI paradigm.  

Take a look at the MOD section under Dave's soundapps page, and especially
the link to SoundTracker for more information about trackers and pattern
sequencing.

Div.

From - Mon Aug 30 18:41:55 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA23986
	for <slinkp@ulster.net>; Sun, 29 Aug 1999 00:53:49 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA16576 for linux-audio-dev-list; Sun, 29 Aug 1999 00:14:09 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA16573 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 29 Aug 1999 00:14:07 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id AAA22966
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 29 Aug 1999 00:09:07 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id AAA06644; Sun, 29 Aug 1999 00:09:08 -0400 (EDT)
Date: Sun, 29 Aug 1999 00:09:06 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] problems with plugins?
In-Reply-To: <Pine.LNX.4.10.9908271928200.17154-100000@anime.net>
Message-ID: <Pine.GSO.4.10.9908290000210.6176-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: dbdaf08e7fcf327f2771a29fd4237b10

On Fri, 27 Aug 1999, Dan Hollis wrote:

> On Sat, 28 Aug 1999, David Olofson wrote:
> > Still worried about power? Well, there's always Alpha AXP, but K7 is cathing up
> > on them...
> 
> For raw performance HP PA-RISC beats them all. Of course, this is not a
> CPU typically found in desktop multimedia PCs...

Now we're way out of LAD territory, but I felt compelled to ask... Since
I've been working at Digital/Compaq, I've been using Alphas quite a bit,
but I've never thought they were particularly special when compared with
any other RISC system.  This opinion, however, is not based on benchmarks,
but rather based on general knowledge of how RISC compares to CISC.  (My
group was just spun off, so I have no particular reason to be blindly
loyal.)

Does anybody know how the various RISC chips really stack up?  There are
quite a few of them -- DEC Alpha, Sun UltraSparc, Motorola/IBM PowerPC,
SGI MIPS, and HP PA-RISC -- and Linux runs on all of them.  (Yes, I know
that x86's since the PPro have been RISC at the core, but there's no way
to bypass thier CISC-emulating microcode, so let's ignore them for now.)

Which is really fastest at the same Megahertz (and who currently has the
fastest overall)?

Just curious.
Div.

From - Mon Aug 30 18:42:01 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA11504
	for <slinkp@ulster.net>; Sun, 29 Aug 1999 06:48:15 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA16899 for linux-audio-dev-list; Sun, 29 Aug 1999 06:07:35 -0400
Received: from chekov.Belgium.EU.net (chekov.belgium.eu.net [193.74.208.161]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA16896 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 29 Aug 1999 06:07:31 -0400
Received: from (adial078.liege.eunet.be [195.207.174.78])
	by chekov.Belgium.EU.net  with SMTP id MAA24420 
	for <linux-audio-dev@ginette.musique.umontreal.ca>;
	Sun, 29 Aug 1999 12:04:22 +0200 (MET DST)
From: "Benjamin GOLINVAUX" <golinvaux@benjamin.net>
To: <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: RE: [linux-audio-dev] audio card for linux (and audiality ?)
Date: Sun, 29 Aug 1999 12:03:23 +0200
Message-ID: <NDBBINHOEMHEFBPJLABAOEKKCAAA.golinvaux@benjamin.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <Pine.LNX.4.10.9908281748440.23524-100000@anime.net>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2f8ebdc51cb4bf76b61bbbbeab9c826b

Well... this is a _really_ good day....

It seems I found my dream audio card for Linux...

The RME Hammerfall (http://www.rme-audio.com/english/digi96/hammer.htm)
card.

An ALSA driver is being developed.. NO ! it doesn't seem to be vaporware...
a native driver is already running and the ALSA interface has to be wrapped
around it, from what I've understood on alsa-devel.

I really think I'm going to buy this one.

Benjamin



From - Mon Aug 30 18:42:05 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id IAA17001
	for <slinkp@ulster.net>; Sun, 29 Aug 1999 08:18:38 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id HAA16972 for linux-audio-dev-list; Sun, 29 Aug 1999 07:41:06 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA16969 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 29 Aug 1999 07:41:03 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m11L3JM-000dyjC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Sun, 29 Aug 1999 13:39:48 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Sun, 29 Aug 1999 13:39:48 +0200 (CEST)
To: Kai Vehmanen <kaiv@wakkanet.fi>
Cc: est@hyperreal.org, Guenter Geiger <geiger@epy.co.at>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
In-Reply-To: <%q19x341A7@sculpcave>
References: <19990827205522.10772.qmail@hyperreal.org>
	<%q19x341A7@sculpcave>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14281.4694.852394.847284@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e86e375fe35a5a412a96b364b47ed531

Kai Vehmanen writes:
 > On Fri, 27 Aug 1999, est@hyperreal.org wrote:
 > 
 > >>  I think we should keep any GUI stuff out of the API as good
 > >>  as possible.
 > > OK.  Here's a simplifying suggestion.  Two fields: 1) a gui type
 > > string and 2) an opaque gui data pointer.
 > 
 > In ecasound, all effects must implement functions for getting and
 > setting parameters, getting number of parameters and getting parameter
 > names (+ effect name of course). This info is all I need for building 
 > a effect-GUI (= widget that show all effect params, their names, etc.).
 > 

 That's the common way to do it, however this is not enough for all
 plugins. 
 
 Combining Eric's and Davids proposal we only need a pointer that
 tells us about the gui.
 
 This will be the hook which is used for a GUI plugin. 
 The hook will be a pointer of known type, which has some virtual
 functions and different other things which we will define as a
 separate GUI class for plugins.
 
 The effect itself and it's GUI are seperated this way.
 
 Can you tell us more about the design of ecasound plugins ?
 I guess ecasound uses plugins for a longer time. Can you post
 the header of the plugin base class ?

 Guenter 



From - Mon Aug 30 18:42:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA28197
	for <slinkp@ulster.net>; Sun, 29 Aug 1999 10:54:07 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA17124 for linux-audio-dev-list; Sun, 29 Aug 1999 10:15:14 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA17121 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 29 Aug 1999 10:15:11 -0400
Received: from localhost.localdomain (dialup89-4-7.swipnet.se [130.244.89.55]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id QAA18787; 
          Sun, 29 Aug 1999 16:12:04 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>,
        Benno Senoner <sbenno@gardena.net>
Subject: [linux-audio-dev] Plug-in API design decisions; please consider
Date: Sun, 29 Aug 1999 14:26:20 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <99082916172602.00444@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id QAA18787
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id KAA28197
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 5498cd576897a71497f015e5d6d9ebc2

Hi!

Had a few thoughts, but I don't have much time today, as I *really* need to get
this darn song together. (Sometimes, I just don't love music all that much...)

.-------
| Are we concentrating fully on audio-only, or
| should we take other forms of data into account?
`-------

I think this is very important to think about. There's more places than auido
processing where you could use a standard streaming plug-in API. The most
obvious one is probably video, and IMO, it seems pretty similar to audio
processing if you define one frame as a video frame, instead of an audio sample.

What about defining data format descriptors as a small structure or bit
pattern, rather than a single dimension list of constants? This would separate
the low level details from the physical format that transport layers need to
know about, and means that an engine could stream data that it doesn't
understand, as long as plug-ins to translate are available. "Stream video along
with your audio data in any audio sequencer - no video support needed. Use the
system's multimedia viewer plug-in." Cool or pointless?

What I'd want in a format code is
	Low level:
		Format ID
		Version/details/flags...?
	High level:
		Channels (per frame)
		Frame size (in bytes)

Further, a way of implementing variable buffer sizes would be very useful in
some cases. (Compressed data...) Setting frame size to FRAMESIZE_VARIABLE and
starting each frame with an unsigned long specifying the size would be a simple
interface for engines to handle. The engine doesn't have to know what's being
streamed - it just feeds the data between plug-ins. The engine's interface to
the outside world is the only place where data formats really matter.

Sidenote: Why do I like this?
Well, not only does it mean that host application developers have less stuff to
support - they could actually support *everything* by just implementing a basic
generic data streaming engine and using plug-ins for the actual work; it also
means that the client/server architecture I'll use for Audiality will become a
lot more usable. The engine doesn't need to understand the data all plug-ins
are using. It could handle (split/merge/convert...) the most frequenctly used
formats internally for performance reasons, but doesn't need to, as plug-ins
can take care of it, as long as the data can be streamed correctly.

I never liked the host application approach. Engine plug-ins should be a
shared system resource, and there are many reasons for that.

* It makes it a lot easier for applications to share hardware
  resources in an efficient way. Important if   multiple
  applications want to stream from/to disk at once.

* Synchronization is done through the engine, more or less
  for free.

* The engine takes care of synchronizing multiple cards and
  other tricky stuff. With sub-sample precision if you have
  an RTLinux engine in the system.

* Engine optimizations and bugfixes benefit to all client
  applications.

* Any application will be able to take advantage of SMP and
  clustering as it becomes supported by the engine.

* A crashing application doesn't kill the engine.

* Developing an application becomes a matter of building a
  nice user interface, rather than implementing yet another
  plug-in host, solving the multi-file disk streaming
  problems all over again and so on... (You *can* still do
  that if you like or need to!)

That's what I could think of right now... There are a few disadvantages as
well, but most of them become non-issues with decent plug-in and client/server
APIs. Frankly, I can't think of any obvious problem right now... Off-line
processing? Engine service. Just pipe that data through the engine, and it will
run your net in a non-real time thread. You want to do some processing right in
your application code? Fine, throw in virtual insert jacks in the processing
net, and just stream through your application. Trivial thing to implement in
the client/server API, and it works accross networks as well, if you can take
the latency. (Oh, the engine will measure and/or control the exact latency for
you.)

Tell me what I missed, and I'll solve it! ;-)


And so for this buffer size issue...

Ok, drop frame, samples or whatever from the process() call. Use an event to
specify the size of input and output buffers.

Plug-ins should get the first buffer sizes before the first call to process(),
through a new invention of mine, init(). init() basically does everything that
process() does, except for processing any data (it doesn't get any buffer
pointers). It should be called in non-real time context, so it can safely
allocate memory and take as long to execute as it needs.

The similarity? It handles events. Takes events, sets things up and tells
the engine about any non-standard stuff by returning events. (I intend to have
an event addressing system that allows replying to events. It will be needed
for controllers as well, as you'll want to be able to read them.)

The "buffer size" event should have a channel argument, so that you can set the
size for buffers individually, if the plug-in allows it. Most audio plug-ins
would just say "Homogenous buffer size, please!" (defualt), and accept only
CHANNEL_ALL as the channel argument.

And this system should apply to buffer formats, sample rates and so on...
Everything without lots of binary compatibility breaking stuff in the plug-in
class or instance structs, or even requiring the lazy plug-in hacker to know
about it.

This means that a plug-in can tell the engine wether it supports changing
buffer size/format(weird!)/sample rate/... during operation or not, it can
specify the relations between inputs and output, support mixed buffer size/...
and so on. If you want the default, everything will look like strummin, except
that the properties goes away from the struct.


Oh, events... Quick outline:


#define EV_MAXARGS	2	/* What do we need, really?  */

/* For efficient decoding, events are grouped as
 * system, control, gui, custom etc... (Custom is
 * a group that's reserved for private talk between
 * GUI and process() code, and should *not* be used
 * for anything that could make sense to use standard
 * events for.)
 *
 * The EV_FLAGS field is used for telling requsts
 * from replies and that kind of things.
 *
 * EV_KIND is the actual event code. Event kinds
 * should be declared as sequential enums for good
 * optimization posibilities in switch() decoding.
 * (That's why there's a CLASS field.)
 */
typedef undigned long event_code_t;
#define EV_CLASS_MASK	0xff000000 /* TIMING, SYSTEM, CONTROL,... */
#define EV_FLAGS_MASK	0x00ff0000 /* EVENT, REQUEST, REPLY... */
#define EV_KIND_MASK	0x0000ffff /* Exactly what event is this? */

/* This is for addressing events, and for knowing
 * who to reply to, if the event is a request.
 *
 * Not sure yet, but I think addressed should be
 * a system resource. That is, you allocate as
 * many addresses as you need, and tell the engine
 * where they are for in some way. So, they are
 * basically handlers (opaque data type).
 */
typedef undigned long event_address_t;

/* Timestamps in the event? Nope: EV_CLASS_TIMING.
 */
typedef struct {
	event_code_t	code;		/* What is this? */
	event_address_t	address;	/* Who is this from/to? */
	int		arg[EV_MAXARGS];
} event_t;


So, timing is done by sending an EV_CLASS_TIMING_TIME (or whatever) event,
specifying how many subsequent events will be affected, followed by those
events. Events that are not covered by a _TIME event are out-of-band, and will
bypass the event scheduler WRT scheduled time. (That is, if the event goes to a
MIDI device, it'll be sent ASAP, as opposed to a timed event, which will be
sent as close to the scheduled time as possible.)

Note: If you're in a real hurry, sending out-of-band events using an engine
function call could make sense. (Otherwise you'll just nicely have to finish
your processing and wait until the engine sees your out-of-band events in the
event ouput buffer you return.)

Events can be handled by some nice macros at the plug-in source level... I
think that would be a nice way to make it all look even simple, and to avoid
some bugs. For example, timed events could be handled something like this:

start_timed_event_block(<event_code>, <event_address>, <time>);
event_t *evp;

evp = new_event(<event_code>, <event_address>);
evp->arg[0] = <...>;
evp->arg[1] = <...>;

evp = new_event(<event_code>, <event_address>);
evp->arg[0] = <...>;
evp->arg[1] = <...>;

...

end_timed_event_block();

Of course, the low level stuff of the event system should *not* change, since
that would break binary compatibility!


Comment? Will men with white clothes come to help me soon? ;-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Mon Aug 30 18:42:12 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA29736
	for <slinkp@ulster.net>; Sun, 29 Aug 1999 11:13:31 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA17144 for linux-audio-dev-list; Sun, 29 Aug 1999 10:36:47 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA17141 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 29 Aug 1999 10:36:45 -0400
Received: from localhost.localdomain (dialup89-4-7.swipnet.se [130.244.89.55]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id QAA27469; 
          Sun, 29 Aug 1999 16:33:33 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: David Slomin <dgslomin@CS.Princeton.EDU>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Tracker vs. sequencer
Date: Sun, 29 Aug 1999 16:34:02 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <Pine.GSO.4.10.9908282336590.6176-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Message-Id: <99082916385505.00444@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id QAA27469
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id LAA29736
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4c3747a011a1e27e9b201f90a9e3dd46

On Sun, 29 Aug 1999, David Slomin wrote:
(...)
> made up of patterns, which in turn are made up of events.  A pattern is
> basically a phrase, although it could be used to represent a whole verse.

There used to be a few tracker-style programs that used single track patterns
form more flexibility, but I never found one that I liked... (For various other
reasons.) Any trackers of that kind still around?

> The two sequencers with which I've worked most are Cakewalk and Master
> Tracks Pro, neither of which is (or at least originally was, in Cakewalk's
> case) pattern-based, like a tracker.  They do not impose any structure on
> the music that isn't inherent in the MIDI standard (like channels and
> tracks).  However, Cubase, Vision, Logic, and more recent versions of
> Cakewalk all do their best to add pattern-based structure on top of the
> flat MIDI paradigm.

That's more like the trackers I'm thinking about, but of course, the user
interface is very different. Anyway, I find the tracks + clips system the
sequencers use a pretty efficient compromise. It's not perfect, but it's simple
and works.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Mon Aug 30 18:42:14 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA30518
	for <slinkp@ulster.net>; Sun, 29 Aug 1999 11:22:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA17160 for linux-audio-dev-list; Sun, 29 Aug 1999 10:42:57 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA17157 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 29 Aug 1999 10:42:55 -0400
Received: from localhost.localdomain (dialup89-4-7.swipnet.se [130.244.89.55]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id QAA10926; 
          Sun, 29 Aug 1999 16:39:43 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: David Slomin <dgslomin@CS.Princeton.EDU>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] problems with plugins?
Date: Sun, 29 Aug 1999 16:40:26 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <Pine.GSO.4.10.9908290000210.6176-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Message-Id: <99082916450506.00444@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id QAA10926
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id LAA30518
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 9005f039cff28051d2af0791c3a3d8f5

On Sun, 29 Aug 1999, David Slomin wrote:
(...)
> Does anybody know how the various RISC chips really stack up?  There are
> quite a few of them -- DEC Alpha, Sun UltraSparc, Motorola/IBM PowerPC,
> SGI MIPS, and HP PA-RISC -- and Linux runs on all of them.  (Yes, I know
> that x86's since the PPro have been RISC at the core, but there's no way
> to bypass thier CISC-emulating microcode, so let's ignore them for now.)
> 
> Which is really fastest at the same Megahertz (and who currently has the
> fastest overall)?

And how do they scale to SMP? I think that's getting more and more important
for what we're doing, and it'll probably be the way to get good
price/performance ratios for quite some time... This clock frequency hysteria
doesn't bring performance increase fast enough to rule out SMP, and it means
+power, +heat and -$,$$$.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Mon Aug 30 18:42:17 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA31968
	for <slinkp@ulster.net>; Sun, 29 Aug 1999 11:38:22 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA17190 for linux-audio-dev-list; Sun, 29 Aug 1999 11:01:27 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA17187 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 29 Aug 1999 11:01:24 -0400
Received: from localhost.localdomain (dialup89-4-7.swipnet.se [130.244.89.55]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id QAA15426; 
          Sun, 29 Aug 1999 16:58:16 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: "Benjamin GOLINVAUX" <golinvaux@benjamin.net>,
        <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: RE: [linux-audio-dev] audio card for linux (and audiality ?)
Date: Sun, 29 Aug 1999 17:00:15 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <NDBBINHOEMHEFBPJLABAOEKKCAAA.golinvaux@benjamin.net>
MIME-Version: 1.0
Message-Id: <99082917033807.00444@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id QAA15426
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id LAA31968
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: eb7ba0d70375be25435f179375c59136

On Sun, 29 Aug 1999, Benjamin GOLINVAUX wrote:
> The RME Hammerfall (http://www.rme-audio.com/english/digi96/hammer.htm)
> card.

Looks very nice... :-)

I don't like the 1.5 ms minimum latency (which will result in a total latency
of at least 3 ms through a software engine - still good, though), but it's
still a nice card, especially if it's *usable*! (That is; has Linux drivers. :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Mon Aug 30 18:42:18 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA00997
	for <slinkp@ulster.net>; Sun, 29 Aug 1999 11:52:01 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA17211 for linux-audio-dev-list; Sun, 29 Aug 1999 11:11:12 -0400
Received: from gauss.deltav.hu (gauss.deltav.hu [194.9.64.225]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA17208 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 29 Aug 1999 11:11:09 -0400
Received: from cerealbox (107.dial02.deltav.hu [194.9.64.107])
          by gauss.deltav.hu (Netscape Messaging Server 3.6)  with ESMTP
          id AAA5733 for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Sun, 29 Aug 1999 17:11:13 +0200
Received: from reactor by cerealbox with local (Exim 1.92 #1 (Debian))
	id 11L6ef-00003m-00; Sun, 29 Aug 1999 17:14:01 +0200
Message-ID: <19990829171401.A223@cerealbox>
Date: Sun, 29 Aug 1999 17:14:01 +0200
From: reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Tracker vs. sequencer
Reply-To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
References: <37C6E52E.4C290C6F@amnh.org> <Pine.GSO.4.10.9908282336590.6176-100000@ux02.CS.Princeton.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.91.2
In-Reply-To: <Pine.GSO.4.10.9908282336590.6176-100000@ux02.CS.Princeton.EDU>; from David Slomin on Sat, Aug 28, 1999 at 11:52:02PM -0400
Organization: CTP media laboratories
X-Mutt-References: <Pine.GSO.4.10.9908282336590.6176-100000@ux02.CS.Princeton.EDU>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 041dbf7cdd7308362f01917b6da41179

 >% This relatively inflexible, single level of structure is, I believe, 
 >% singlehandedly responsible for the fact that 90% of the music created with
 >% trackers falls in the techno genre.  The pattern structure just seems best
 >% suited to techno.  (I have heard a few very nice non-techno MODs along the
 >% way, but they're a tiny minority.)

if you think about the tracker as a multichannel stepsequencer, it's
obvious, why it is used to make mostly techno music.

the tracker concept may seem inflexible, but you can achieve great things
with it. the only thing you can do with a sequencer but not with a tracker
is to make chords easily. in a tracker you have to split your chord, and
put each note to a separate channel. i wanna get around this, but i haven't
found the right idea to avoid this. maybe "piano-roll view" would be the
best solution. please, tell me your ideas!

bye!

-- 

  Mt Rcz a.k.a. reactor  -  http://linux.gyakg.u-szeged.hu/~reactor/
   CTP media - since 1995   -  http://ctpmedia.scene.hu/

From - Mon Aug 30 18:42:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA02437
	for <slinkp@ulster.net>; Sun, 29 Aug 1999 12:07:03 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA17270 for linux-audio-dev-list; Sun, 29 Aug 1999 11:28:14 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA17267 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 29 Aug 1999 11:28:12 -0400
Received: from localhost.localdomain (dialup89-4-7.swipnet.se [130.244.89.55]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id RAA26600; 
          Sun, 29 Aug 1999 17:25:03 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Tracker vs. sequencer
Date: Sun, 29 Aug 1999 17:19:06 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <19990829171401.A223@cerealbox>
MIME-Version: 1.0
Message-Id: <99082917302508.00444@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id RAA26600
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id MAA02437
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 9a9c4c20a9c47349165536a60e005c16

On Sun, 29 Aug 1999, reactor/CTPmedia wrote:
> the only thing you can do with a sequencer but not with a tracker
> is to make chords easily. in a tracker you have to split your chord, and
> put each note to a separate channel. i wanna get around this, but i haven't
> found the right idea to avoid this. maybe "piano-roll view" would be the
> best solution. please, tell me your ideas!

I've used trackers that handle this, and even though the implementations were
quite limited, it did work pretty well. The trick was to have switch
"polyphonic edit" that enabled note events (key donwns) to insert a note and
then move on to the next track. IIRC, the tracker I saw it on had a setting
"polyphonic edit tracks" that let you set how many tracks should be used for
the cycling.

I'd do it in a similar, but more flexible way: Allow the user to select what
tracks to enable for recording. Possibly, a smart channel allocator could be
used as an alternative to the "insert note; next channel;" approach. This would
still work in real time record mode as well as step time. The algorithm would
searchback the enabled tracks to the last safe point and then scan forward,
taking effects, instruments and pitches in account, until it finds out which
track is best to steal for the particular note to insert.

Another solution is to enable mapping of tracks to multiple channels
(polyphonic tracks), but that more or less breaks the entire tracker concept...
OTOH, perhaps having full control over every single channel isn't all that
important these days? Back when I started designing my own tracker, I couldn't
get more than 8-12 quality channels out of my Amiga. And that was a 25 MHz 68030
box... 4 tracks was the only viable format for games and demos. We have a few
more cycles to play with these days... :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Mon Aug 30 18:42:24 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA16612
	for <slinkp@ulster.net>; Sun, 29 Aug 1999 14:44:08 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA17535 for linux-audio-dev-list; Sun, 29 Aug 1999 14:04:46 -0400
Received: from bashir.belgium.eu.net (bashir.Belgium.EU.net [193.74.208.147]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA17532 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 29 Aug 1999 14:04:43 -0400
Received: from (adial091.liege.eunet.be [195.207.174.91])
	by bashir.belgium.eu.net  with SMTP id UAA16912 
	for <linux-audio-dev@ginette.musique.umontreal.ca>;
	Sun, 29 Aug 1999 20:01:37 +0200 (MET DST)
From: "Benjamin GOLINVAUX" <golinvaux@benjamin.net>
To: <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: RE: [linux-audio-dev] audio card for linux (and audiality ?) + question about filtering
Date: Sun, 29 Aug 1999 20:00:29 +0200
Message-ID: <NDBBINHOEMHEFBPJLABAKEKMCAAA.golinvaux@benjamin.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <99082917033807.00444@localhost.localdomain>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
X-MIME-Autoconverted: from 8bit to quoted-printable by bashir.belgium.eu.net id UAA16912
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id OAA16612
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f157b7c20bad627550199fb72eac77f0

>On Sun, 29 Aug 1999, Benjamin GOLINVAUX wrote:
>> The RME Hammerfall (http://www.rme-audio.com/english/digi96/hammer.htm)
>> card.

>Looks very nice... :-)

especially when the price is around 500 ($500)... add a 250 ADI-1 AD/DA
from the same companyt and you have a very serious system for... well... a
pretty amount of money but that's really a good card (and I have spared for
a linux audio card for 2 years now)

>I don't like the 1.5 ms minimum latency (which will result in a total
latency
>of at least 3 ms through a software engine - still good, though), but it's
>still a nice card, especially if it's *usable*! (That is; has Linux
drivers. :-)

I would say that a command->action of 3ms is beyond the perception of many
people except very good drummers... (that's the midi latency of a typical
synth)... Someone disagrees ?

However... something that has worried me for some time is that problem :

being given an audio fx engine for, let's say, vocals...

Someone sings : his/her voice has a direct path to the ears AND an indirect
path thru the fx box (be it hardware or audiality for that matter ;-)

So... the direct and indirect signals gets added with a delay of 3ms...

Let's compute the z-transform... you see what I mean ?

Every wave whose half period is 3ms (that is, T=6ms <-> f=166Hz) is delayed
by 180 which leads to total cancelling of these waves... So we get a huge
hole around 166Hz...

Am I correct ?

Furthermore, to move that hole out of the audible range, one has to have a
f=20KHz <-> T=50s <-> latency = 25s !!!!!!!!!

So... do we have to avoid mixing dry and wet or am I wrong somewhere ???


Thanks for some kind of explanation...

Benjamin-


From - Mon Aug 30 18:42:27 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA28061
	for <slinkp@ulster.net>; Sun, 29 Aug 1999 16:57:23 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA17695 for linux-audio-dev-list; Sun, 29 Aug 1999 16:15:04 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id QAA17692 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 29 Aug 1999 16:15:00 -0400
From: est@hyperreal.org
Received: (qmail 3715 invoked by uid 162); 29 Aug 1999 20:11:54 -0000
Message-ID: <19990829201154.3714.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] Re: sequencing..Symbolic Control Protocol
In-Reply-To: <Pine.LNX.4.10.9908300049200.346-100000@avix.localnet> from Andreas
 Voss at "Aug 30, 1999 00:53:10 am"
To: Andreas Voss <andreas@avix.rhein-neckar.de>
Date: Sun, 29 Aug 1999 13:11:54 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3b07f5c8e22c1435256ca08b9cffc63e

Andreas Voss discourseth:
> > The existing parsers don't seem very useful for handling streaming
> > control input (it just doesn't seem to fit the xml paradigm), though I
> > could very well be wrong about that.
> 
> Most parsers support the SAX API which informs the application about tags
> during the parse process. 

Cool.  I'm definitely interested in XML possibilities.  Can you
recommend a good parser with a good license?

Also, any luck coming up with editor recommendations?  I couldn't find
*any* on freshmeat. :|

Eric

From - Mon Aug 30 18:42:34 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA32010
	for <slinkp@ulster.net>; Sun, 29 Aug 1999 17:39:04 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA17759 for linux-audio-dev-list; Sun, 29 Aug 1999 16:53:04 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id QAA17756 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 29 Aug 1999 16:53:01 -0400
From: est@hyperreal.org
Received: (qmail 24433 invoked by uid 162); 29 Aug 1999 20:49:56 -0000
Message-ID: <19990829204956.24432.qmail@hyperreal.org>
Subject: [linux-audio-dev] streaming xml
In-Reply-To: <19990829201154.3714.qmail@hyperreal.org> from "est@hyperreal.org"
 at "Aug 29, 1999 01:11:54 pm"
To: est@hyperreal.org
Date: Sun, 29 Aug 1999 13:49:56 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: b988e5f511c8a64044c16ca048b1bcc7

est@hyperreal.org discourseth:
> Andreas Voss discourseth:
> > > The existing parsers don't seem very useful for handling streaming
> > > control input (it just doesn't seem to fit the xml paradigm), though I
> > > could very well be wrong about that.
> > 
> > Most parsers support the SAX API which informs the application about tags
> > during the parse process. 

Hmm..could SAX stand for `semantic actions'?  I'm a yaccer from way back. :)

> Cool.  I'm definitely interested in XML possibilities.  Can you
> recommend a good parser with a good license?

I've been looking at libxml.  It seems to have entry points to parse
an in-memory document and a file..but I don't know if the latter will
handle streaming data.  Documentation that starts "parser -- one line
description goes here" is a little disappointing. :)

Eric

From - Mon Aug 30 18:42:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA27607
	for <slinkp@ulster.net>; Mon, 30 Aug 1999 07:04:06 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA17877 for linux-audio-dev-list; Sun, 29 Aug 1999 18:20:42 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA17874 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 29 Aug 1999 18:20:38 -0400
Received: from localhost.localdomain (d212-151-38-90.swipnet.se [212.151.38.90]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA12317; 
          Mon, 30 Aug 1999 00:17:26 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: "Benjamin GOLINVAUX" <golinvaux@benjamin.net>,
        <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: RE: [linux-audio-dev] audio card for linux (and audiality ?) + question about filtering
Date: Mon, 30 Aug 1999 00:01:00 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <NDBBINHOEMHEFBPJLABAKEKMCAAA.golinvaux@benjamin.net>
MIME-Version: 1.0
Message-Id: <99083000224901.00463@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id AAA12317
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id HAA27607
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e451428256920fb56356b962159abb15

On Sun, 29 Aug 1999, Benjamin GOLINVAUX wrote:
> >I don't like the 1.5 ms minimum latency (which will result in a total
> latency
> >of at least 3 ms through a software engine - still good, though), but it's
> >still a nice card, especially if it's *usable*! (That is; has Linux
> drivers. :-)
> 
> I would say that a command->action of 3ms is beyond the perception of many
> people except very good drummers... (that's the midi latency of a typical
> synth)... Someone disagrees ?

That's pretty correct. Actually, only the fastest synths react in 3 ms or less.
(Analog synths are a lot faster, but that's another story.) Latencies of 10 ms,
exponentially increasing with the number of channels to trigger wasn't unusual
a few years ago! That kind of latency is even noticable for the average
keyboardist...

> However... something that has worried me for some time is that problem :
> 
> being given an audio fx engine for, let's say, vocals...
> 
> Someone sings : his/her voice has a direct path to the ears AND an indirect
> path thru the fx box (be it hardware or audiality for that matter ;-)
> 
> So... the direct and indirect signals gets added with a delay of 3ms...

You've done something that's wrong and quite pointless here...

> Let's compute the z-transform... you see what I mean ?
> 
> Every wave whose half period is 3ms (that is, T=6ms <-> f=166Hz) is delayed
> by 180 which leads to total cancelling of these waves... So we get a huge
> hole around 166Hz...
> 
> Am I correct ?

Yep, but the problem is a non-issue in most cases, as you have no reason to mix
two dry signals. You shouldn't even do that with analog systems, as analog
filters have latencies as well.

> Furthermore, to move that hole out of the audible range, one has to have a
> f=20KHz <-> T=50s <-> latency = 25s !!!!!!!!!

The hole is out of the audible range... but you'll have complete cancelation at
fs/2, and it will still have effect down in the audible range. You get a treble
fall-off...

NO LATENCY AT ALL is acceptable, or you'll do strange things to the mixed
result. True, if you get down to some single s, the effect won't be noticable,
but how would you do oversampling in the AD/DA? Or digital filtering, or for
that matter, analog filtering?

> So... do we have to avoid mixing dry and wet or am I wrong somewhere ???

Yep, you missed one thing. Why would we ever want to mix a dry analog signal
with the "same" dry signal that has passed through a digital system?

The solution:

Either we mix the analog dry signal with the processed signal *only* - no dry
signal should get through the digital system - or we don't mix at all in the
analog domain, but do it all digital. This is how many external FX boxes do it;
the bypass of those that seem to have zero latency is actually analog. The
others do everything digital, and the phenomenon you mentioned *will* occur if
you run them in "dry + processed" mode and mix with an analog bypass.

With a latency of less than 5 ms, the later method works pretty well, and with
less than 1 ms, you're not human if you notice any difference, even with
headphones. 1 ms is only 30 cm of sound travel in air...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Mon Aug 30 18:42:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA28068
	for <slinkp@ulster.net>; Sun, 29 Aug 1999 16:57:25 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA17663 for linux-audio-dev-list; Sun, 29 Aug 1999 16:01:01 -0400
Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA17660 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 29 Aug 1999 16:00:52 -0400
Received: (from uucp@localhost)
	by news-ma.rhein-neckar.de (8.8.8/8.8.8) with UUCP id VAA03594;
	Sun, 29 Aug 1999 21:56:51 +0200 (CEST)
	(envelope-from andreas@avix.rhein-neckar.de)
Received: from localhost (andreas@localhost [127.0.0.1])
	by avix.localnet (8.9.3/8.9.3) with ESMTP id AAA00371;
	Mon, 30 Aug 1999 00:53:10 +0200
Date: Mon, 30 Aug 1999 00:53:10 +0200 (MEST)
From: Andreas Voss <andreas@avix.rhein-neckar.de>
X-Sender: andreas@avix.localnet
To: est@hyperreal.org
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: sequencing..Symbolic Control Protocol
In-Reply-To: <19990826203930.5118.qmail@hyperreal.org>
Message-ID: <Pine.LNX.4.10.9908300049200.346-100000@avix.localnet>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ef3db4dc0edc0f0ba0302bf681dd63f8

> The existing parsers don't seem very useful for handling streaming
> control input (it just doesn't seem to fit the xml paradigm), though I
> could very well be wrong about that.

Most parsers support the SAX API which informs the application about tags
during the parse process. 

Andreas


From - Wed Sep  1 23:45:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id FAA23943
	for <slinkp@ulster.net>; Wed, 1 Sep 1999 05:53:33 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA25428 for linux-audio-dev-list; Wed, 1 Sep 1999 05:03:34 -0400
Received: from pluto.nic.fi (nic.fi [193.209.220.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA25425 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Sep 1999 05:03:27 -0400
Received: from sculpcave (IDENT:root@cvx-1-19.dyn.nic.fi [62.236.97.19])
	by pluto.nic.fi (8.9.3/8.9.3) with ESMTP id XAA18845
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 30 Aug 1999 23:58:39 +0300 (EET DST)
Date: Mon, 30 Aug 1999 23:40:23 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
To: Guenter Geiger <geiger@epy.co.at>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
In-Reply-To: <14281.4694.852394.847284@gige>
Message-ID: <%cdty3olBb@sculpcave>
X-User-Agent: Mana 4.0beta (Linux)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 412f1fe8e994bf0861ec66afdd23f9c0

On Sun, 29 Aug 1999, Guenter Geiger wrote:

>  Can you tell us more about the design of ecasound plugins ?
>  I guess ecasound uses plugins for a longer time. Can you post
>  the header of the plugin base class ?

Well I should first clear some issues. First of all, currently
ecasound is not a very efficient program. Before switching to 
C++, ecasound was written in C and in a traditional
performance-centered style. After switching to C++ (and a lot
of coding in Eiffel :)) I noticed that concentrating on clean
and simple design makes so many things easier. And what's extremely 
important for me, this makes it fast&easy to continue with 
a project after a longer break. But I understand that most
areas of audio programming require the performance that you get
by optimizing your code. So ecasound effect API won't suit this 
open plugin project...

However, I think that some design aspects of ecasound's effect-API
might be good to keep in mind. First, writing a new effect for ecasound
is really simple... Here's a few header lines...:

--cut--
class CHAIN_OPERATOR {
[...]
  virtual void set_parameter(int param, double value);
  virtual double get_parameter(int param);
  virtual string status(void);
  virtual int number_of_params(void) const;

  virtual string label(void) = 0;
  virtual string id_string(void) { return(""); }

  virtual void process(SAMPLE_BUFFER* sbuf);
  virtual void process(SAMPLE_BUFFER::sample_type *);
--cut--

Implementing [sg]et_parameter enables realtime control. 
Status() is meant for simple non-continuous messages. 
Number_of_params() is, well, self-explanatory. Label() 
is a informative name for the effect while id_string() 
is a ecasound-specific name (used in the user interface). And what's
left is to implement one version of process()... First one takes a
whole buffer while the other takes a pointer to a single sample.
SAMPLE_BUFFER class offers all the info needed about the sample
parameters and a a bunch of useful routines for handling sample data.

So you don't really need to do much. There are some other
functions you might want to implement (effect name, etc), but
they are all trivial to implement. Now the effect is ready
for MIDI/oscillator control and it can be combined with other 
effects in serial and in parallel. 

This approach is too simple for a general plugin-API, but 
I still like the interface very much. This is why I hope that 
OPA/whatever's API doesn't get too complex.

-- 
Kai Vehmanen ----------------------------- CS, University of Turku, Finland
 : email                                 mailto:kaiv@wakkanet.fi
 : audio processing for linux            http://www.wakkanet.fi/ecasound/
 : my music (ambient-idm-rock-...mp3/ra) http://www.wakkanet.fi/sculpscape/



From - Wed Sep  1 23:46:01 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA26935
	for <slinkp@ulster.net>; Wed, 1 Sep 1999 06:49:02 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA25597 for linux-audio-dev-list; Wed, 1 Sep 1999 05:54:44 -0400
Received: from gauss.deltav.hu (gauss.deltav.hu [194.9.64.225]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA25594 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Sep 1999 05:54:40 -0400
Received: from cerealbox (101.dial02.deltav.hu [194.9.64.101])
          by gauss.deltav.hu (Netscape Messaging Server 3.6)  with ESMTP
          id AAA6E2F for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Tue, 31 Aug 1999 00:08:27 +0200
Received: from reactor by cerealbox with local (Exim 1.92 #1 (Debian))
	id 11LZc4-00006C-00; Tue, 31 Aug 1999 00:09:16 +0200
Message-ID: <19990831000916.B162@cerealbox>
Date: Tue, 31 Aug 1999 00:09:16 +0200
From: reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [dlphilp@bright.net: Re: [linux-audio-dev] Tracker vs. sequencer]
Reply-To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.91.2
Organization: CTP media laboratories
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 03a4c6c823bd4d89a295886b9fc17e52

----- Forwarded message from Dave Phillips <dlphilp@bright.net> -----

Greetings:

  Just a quick note to mention that I've added some more pieces to my
MP3 page at:

	http://www.bright.net/~dlphilp/dp_mp3.html

One of the pieces (Time Wasted) was created using Michael Krause's
SoundTracker.

  Btw, SoundTracker has been consistently developed by its author and
has just reached version 0.3.1.

  IMO, a tracker is simply one kind of audio sequencer. Paul W, if
you're reading this you might want to take another look at modern
trackers. I think it's possible to do many things quite beyond the
original design basis, although the design biases are indeed apparent.
Trackers really are great for many sorts of dance music, and with
variable track length per pattern I think there are some rather
interesting rhythmic possibilities.

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

----- End forwarded message -----

-- 

  Mt Rcz a.k.a. reactor  -  http://linux.gyakg.u-szeged.hu/~reactor/
   CTP media - since 1995   -  http://ctpmedia.scene.hu/

From - Wed Sep  1 23:45:59 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA25091
	for <slinkp@ulster.net>; Wed, 1 Sep 1999 06:17:51 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA25513 for linux-audio-dev-list; Wed, 1 Sep 1999 05:23:59 -0400
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id FAA25494 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Sep 1999 05:23:56 -0400
Message-Id: <199909010923.FAA25494@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Timed Event Editor Framework
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Mon, 30 Aug 1999 18:21:29 -0400 (EDT)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
In-Reply-To: <Pine.GSO.4.10.9908262358320.22273-100000@ux02.CS.Princeton.EDU> from "David Slomin" at Aug 27, 99 00:11:27 am
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 079ab97db5d37d50786a591ea390bd92

David Slomin wrote:
> > > I take issue with this.  In CSound you specify all parameters for a note a
> > > the time that it is fired.  In MIDI, you add or modify parameters over
> > > time after the note has been fired.
> > 
> > That's a conceptual bug in Csound that IMO should be patched over --
> 
> Actually, I see advantages in both methods.  The MIDI way is certainly
> more appropriate for realtime, but Csound's approach makes many things in
> synthesis much easier (or even possible).  For instance, try designing a
> MIDI-controlled sound that crescendos linearly from zero volume at note-on
> to maximum volume at note-off.

Orthogonal issues, I think:
1) is note length known at the time of note-on?
2) can notes be modulated while they are playing?

Even in Csound you _can_ do (2); you just have to bypass the pfield
mechanism.

> > Seems to me it's easier to ignore
> > structure than it is to add it in after the fact.  Say something like
> > 
> > function delay_each_track(merged_tracks) =
> >         for each_track in merged_tracks, 
> >                 for each event e in each_track,
> >                         old_e.time = e.time;  output old_e
> >                         old_e = e
> > 
> >         vs.
> > 
> > function delay_each_track(merged_tracks) =
> >         for each event e in merged_tracks,
> >                 old_e[e.track].time = e.time;  output old_e[e.track]
> >                 old_e[e.track] = e
> > 
> > Okay, the difference is not dramatic here, but as I start wanting more
> > and more temporal structure, it can either go in the data typing, or
> > I the programmer have to write code that parallels and maintains it by
> > hand.
> 
> I understand what you're saying, but I can't think of an example where the
> difference _would_ be dramatic.

How about escalating the structure's tree-depth?  The first version
gets more for-each levels but the inner loop stays clean:

        for each_group in merged_groups
                for each_track in each_group
                        old_e.time = e.time;  output old_e
                        old_e = e

 vs.

        for each event e in flattened_all_groups_in_tracks
                this_old_e = (old_e[e.track])[e.group]
                this_old_e.time = e.time;  output this_old_e
                (old_e[e.track])[e.group] = e

And with a more-involved structure the second loop involves things like
(((old_e[e.level1index])[e.level2index])[e.level3index])[e.level4index]
(and that isn't a one-piece multidimensional array).

Other sorts of scenarios: apply a function to some part of a musical
structure -- call it on that part of the data structure, or grovel
through all the data elements determining whether they're in the part?
(Is speed a concern?)  Rearrange a musical structure -- twiddle
pointers at the top level, or grovel again munging all the data
elements' tags?

If you've got structure in the language you can always forgo it and
work with tagged flattened data.  Just seems to me you'll only want to
do that at the very end, for shipping to the output device.

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Wed Sep  1 23:46:10 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id IAA03823
	for <slinkp@ulster.net>; Wed, 1 Sep 1999 08:37:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id HAA25845 for linux-audio-dev-list; Wed, 1 Sep 1999 07:34:09 -0400
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id HAA25842 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Sep 1999 07:34:07 -0400
Message-Id: <199909011134.HAA25842@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] plug-in design space
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Mon, 30 Aug 1999 18:44:55 -0400 (EDT)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
In-Reply-To: <19990827220611.4598.qmail@hyperreal.org> from "est@hyperreal.org" at Aug 27, 99 03:06:11 pm
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2e524697e62922c96fd174163c24a01f

est@hyperreal.org wrote:
> > I've seen an arbitrary-sample-rate architecture (Nyquist), and it's
> > not pretty.
> 
> Oooh..details?  I may be getting your terms crossed here though.  I
> can see how fixed sampling rate plugins (with different sampling
> rates) would require a variable sampling rate architecture..and vice
> versa.  It's the `vice versa' that I prefer. :)

Nyquist is a computer-music language that is quite general.
(http://www.cs.cmu.edu/afs/cs/project/music/web/music.software.html)
You can mingle arbitrary sampling rates, vary block lengths on the
fly, make every parameter constant or voltage-controlled or audio-
modulated as you choose -- from the user's perspective it all Just
Works.

The price is that component code is pretty scary, and has to be
elaborated by a special Lisp program from a core written by the
programmer.  The handling of ugly details like partial blocks is not
sufficiently hidden.  I have to re-read David Olofson's look_ahead /
skip_behind mechanism to see if it can help here, but let's just say I
think there's a reason why most computer-music languages do
synchronous blocks.

(Full disclosure: Nyquist's designer is my advisor.)

> >  * How are feedback loops handled?
> 
> What I'm hoping for is a spec that will handle a variety of plugins,
> not all of which will be appropriate for given architectural decisions
> on these sorts of questions.

Ah, that sounds like a Solomonic solution.  I'll have to think about
what this boils down to for plugins.

> Eli, this is one great set of points/questions!

Hey, thanks.

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Wed Sep  1 23:46:08 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA30155
	for <slinkp@ulster.net>; Wed, 1 Sep 1999 07:35:31 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA25732 for linux-audio-dev-list; Wed, 1 Sep 1999 06:43:11 -0400
Received: from sculpcave.localdomain (cvx-2-148.dyn.nic.fi [62.236.99.148]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA25729 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Sep 1999 06:42:50 -0400
Received: (from root@localhost)
	by sculpcave.localdomain (8.8.7/8.8.7) id LAA02239;
	Tue, 31 Aug 1999 11:09:00 +0300
Date: Tue, 31 Aug 1999 11:09:00 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
To: alsa-devel@alsa-project.org
cc: linux-sound@vger.rutgers.edu, linux-audio-dev@ginette.musique.umontreal.ca,
        alsa-user@alsa-project.org
Subject: [linux-audio-dev] loopback in action!
Message-ID: <%mk4y30sB5@sculpcave>
X-User-Agent: Mana 4.0beta (Linux)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: e4ea2cf12fef0881575141d0db7af148

ALSA kicks ass! :) Seriously, I'm currently writing a ALSA plugin 
for Michael Krause's soundtracker. It's still in early beta (output
only, scopes aren't working, etc), but simple module playback works
nicely. Anyway, I decided to finally do some real testing with ALSA
pcm-loopback and it proved to work amazingly well...

First, configured sountracker to use ALSA card 0 and device 0. Then 
started playing some mod file and on to another console...:

 ecasound -i alsalb,0,0 -o alsa,1,0 -etr:40,0,60

A reverbed version of the module comes from my speakers! :) And...

 ecasound -i alsalb,0,0 -o alsa,1,0 -efl:2000 -kos:1,200,4000,0.2

A lowpass filtered version with a 0.2Hz sine oscillator controlling
the filter cutoff! Don't know how useful this is, but this sure put 
a big smile on my face. ;) 

Software versions used were ALSA 0.4.0, SoundTracker 0.3.1 (w/ patched 
ALSA support) and ecasound 1.5.6r5.

PS The biggest problem was that if I tried to capture output from 
   my AWE64G, the capturing program sometimes exited with a 
   "Interrupted system call" error...

-- 
Kai Vehmanen ----------------------------- CS, University of Turku, Finland
 : email                                 mailto:kaiv@wakkanet.fi
 : audio processing for linux            http://www.wakkanet.fi/ecasound/
 : my music (ambient-idm-rock-...mp3/ra) http://www.wakkanet.fi/sculpscape/


From - Wed Sep  1 23:45:58 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA24483
	for <slinkp@ulster.net>; Wed, 1 Sep 1999 06:04:52 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA25420 for linux-audio-dev-list; Wed, 1 Sep 1999 05:02:12 -0400
Received: from mail-gw6.pacbell.net (mail-gw6.pacbell.net [206.13.28.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA25417 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Sep 1999 05:02:08 -0400
Received: from wiliweld.com (adsl-63-193-247-201.dsl.snfc21.pacbell.net [63.193.247.201])
	by mail-gw6.pacbell.net (8.9.3/8.9.3) with ESMTP id FAA05387;
	Tue, 31 Aug 1999 05:05:07 -0700 (PDT)
Message-ID: <37CBC741.3469FC92@wiliweld.com>
Date: Tue, 31 Aug 1999 05:14:57 -0700
From: Bill <Bill@wiliweld.com>
Reply-To: Bill@BillSchoolcraft.com
Organization: Proudly running  LINUX   >>>   Kernel 2.2.9-19
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.9-19mdk i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Kai Vehmanen <kaiv@wakkanet.fi>
CC: alsa-devel@alsa-project.org, linux-sound@vger.rutgers.edu,
        linux-audio-dev@ginette.musique.umontreal.ca,
        alsa-user@alsa-project.org
Subject: [linux-audio-dev] Re: loopback in action!
References: <%mk4y30sB5@sculpcave>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 5b0cff499e6a675b6fa32bc725d1038d

Kai Vehmanen wrote:
> 
> ALSA kicks ass! :) Seriously, I'm currently writing a ALSA plugin
> for Michael Krause's soundtracker. It's still in early beta (output
> only, scopes aren't working, etc), but simple module playback works
> nicely. Anyway, I decided to finally do some real testing with ALSA
> pcm-loopback and it proved to work amazingly well...

Kai,

	I recently had a customer who has a hearing disability and uses
voice emulation and we were in need of driver that would eliminate
the POP that he was experiencing during .wav, .au, and .voc files,
not .midi though.

	He has an on-board Crystal Sound chip set. I can't recall the exact
chip but it was mentioned on the ALSA page, in the howto's. We ended
up using OSS. Any input on this would be appreciated for you seem to
be doing some good work from what I read. Thanks.

-- 


                     " vivit post funera virtus "
                                 
                  Linuxcare, At the center of Linux.
                      http://www.linuxcare.com                    
                                                     
             Bill Schoolcraft    http://www.wiliweld.com

From - Wed Sep  1 23:46:02 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA28809
	for <slinkp@ulster.net>; Wed, 1 Sep 1999 07:16:00 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA25682 for linux-audio-dev-list; Wed, 1 Sep 1999 06:18:18 -0400
Received: from proxy3.ba.best.com (proxy3.ba.best.com [206.184.139.14]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA25679 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Sep 1999 06:18:15 -0400
Received: from julius (dynamic3.pm04.mv.best.com [209.24.240.195])
	by proxy3.ba.best.com (8.9.3/8.9.2/best.out) with SMTP id KAA10968;
	Tue, 31 Aug 1999 10:53:38 -0700 (PDT)
Message-Id: <199908311753.KAA10968@proxy3.ba.best.com>
X-Sender: julius@shell16.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Tue, 31 Aug 1999 10:57:04 -0700
To: Benno Senoner <sbenno@gardena.net>
From: Julius Smith <jos@w3k.org>
Subject: [linux-audio-dev] Re: Bandlimited interpolation suitable for realtime audio
  generation (multi-voice) ?
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>,
        David Olofson <audiality@swipnet.se>, Paul Barton-Davis <pbd@op.net>,
        jos@ccrma.Stanford.EDU
In-Reply-To: <99083119222702.00821@linuxhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id HAA28809
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: e78d15a6135f69901f74470730734e87

Hi Benno,

Your analysis of bandlimited interpolation requirements is correct, and your appraisal of the general trade-offs appears fairly complete.  

We normally use bandlimited interpolation for offline sampling-rate conversion.  For real-time work, we generally use either linear-interpolation + oversampled wavetables, or highly optimized conversion filters for certain fixed sampling-rate ratios.  

Emu  (now part of Creative Labs)  samplers have been doing bandlimited interpolation in VLSI for many years.  Other samplers lacking special interpolation hardware tend to use simple linear interpolation, and they might also cross-fade from one table to another as the conversion ratio goes beyond a certain point.  (Have a separate table for each octave, say, and oversample by a factor of 2.)

The NeXT computer had optimized filters for real-time conversion among the various sampling rates supported in the hardware (8, 22, and 44 kHz).  Having a DSP56001 signal processing chip on every motherboard made this very smooth, but when it was busy, the 68040 was able to do real-time conversions without too much trouble most of the time.  However, there was no explicit support for real-time operation in the '040. 

For a Linux real-time environment on the PC, I think I would recommend the use of oversampled wavetables and linear interpolation.  It can be surprising how good simple linear interpolation sounds with an oversampling factor of two or more.  Your proposal for polynomial interpolation, oversampling by 2, and limiting to one octave is a higher quality version of what I'm suggesting.

As processors get more powerful, it might make sense to introduce an option for turning on bandlimited interpolation at various compute levels for real-time use.  What I've always wanted was to be able to say to the audio service "keep audio processing less than or equal to x% of total bandwidth", and have the system allocate compute-power up to that limit.  Thus, during a solo passage, some heavy-duty interpolation might be running, while during multivoiced "pads", the system might only be able to afford linear interpolation for that many voices under the current bandwidth budget.  A similar "budget" system could be applied to memory usage.  I've worked with some game designers, for example, who have requested that audio consume no more than 10% of the processor bandwidth, since they want the rest for graphics.  A budget-based approach is just what they wanted.  Of course, the musicians among us might want to devote almost 100% of the processor to audio, and they should be able to shoot for that and get the best results they can.

Cheers,
Julius

At 06:21 PM 8/31/99 +0200, Benno Senoner wrote:
>Hello,
>I went on Julius Smith's Digital Audio Resampling page
>http://ccrma-www.stanford.edu/~jos/resample/
>
>I must say the bandlimited interpolation sounds very good even after a +/-2
>octave transposition.
>I studied the PDF a bit, and it seems that the algorithm needs
>a number of multiply-adds of 
>(2* Nz +1)* max { Fs,Fs'}
>Nz is set to 13 in the example ,
>Fs is the original sample frequency and Fs'  the target sample freq.
>This means about
>27 * max { Fs,Fs'} 
>playing a sample at the half pitch (ie. Fs'= 88100  Fs=44100)
>has a cost of about 54 multiply-adds per sample.
>playing at 1/4 of the original pitch ( -2 octaves transposition), will result
>in 108 multiply-adds per sample.
>
>Now my question is:
>is this resampling method suitable for software based realtime samplers
>implemented on a PC ?
>
>The main problem of simple interpolations like linear,cubic etc. is that
>if you play the sample at higher pitches, you enter into the aliasing area,
>which could result in disturbing noise, if the sample contains high-freq
>components.
>
>I bencharked the "resample-1.4" example , and converting a
>4 min 44Khz 16bit stereo wav, took about 3 min on my PII400.
>This would mean not more than 5 voices, which is not acceptable
>for a software based sampler, since we need at least 20-30
>voices ( let's say on a PII400) for decent playback.
>(Of course we need spare CPU cycle to perform all kind of other operations)
>
>Another solution could be to allow (or guarantee no aliasing noise) a max
>upwards transposition of 1 octave, using a polinomial interpolation,
>and render the audio internally at twice the output frequency
>(let's say 88200 instead of 44100), and then apply a lowpass filter at 20khz
>to the sum of all voices.
>The drawback would be that all internal processing stages must run at twice
>the sampling rate or alternatively modules which are known not to run into the
>aliasing area, could output 2 equal samples, but the needed memory bandwidth
>would still be twice as normal.
>
>Does anyone know how hardware samplers solve these problems ?
>( to keep audioquality high , and processing usage low)
>
>If we should chose standard interpolation methods (for efficiency reasons),
>which interpolation method is the one which has the best price/audioquality
>ratio ?
>( cubic / spline ? )
>Any good URLs out there ?
>
>comments ?
>
>regards,
>Benno.
>
>--
>Benno Senoner
>E-Mail: sbenno@gardena.net
>Linux low-latency audio  / scheduling latency benchmarks
>http://www.gardena.net/benno/linux/audio
> 

From - Wed Sep  1 23:46:05 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA29324
	for <slinkp@ulster.net>; Wed, 1 Sep 1999 07:22:33 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA25688 for linux-audio-dev-list; Wed, 1 Sep 1999 06:20:30 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA25685 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Sep 1999 06:20:25 -0400
Received: (from sbenno@localhost)
	by em.gardena.net (8.9.1/8.9.0) id MAA12855;
	Wed, 1 Sep 1999 12:16:35 +0200
From: Benno Senoner <sbenno@em.gardena.net>
Message-Id: <199909011016.MAA12855@em.gardena.net>
Subject: [linux-audio-dev] Re: Bandlimited interpolation suitable for realtime audio
To: jos@w3k.org (Julius Smith)
Date: Wed, 1 Sep 1999 12:16:35 +0200 (MET DST)
Cc: sbenno@gardena.net, linux-audio-dev@ginette.musique.umontreal.ca,
        audiality@swipnet.se, pbd@op.net, jos@ccrma.Stanford.EDU
In-Reply-To: <199908311753.KAA10968@proxy3.ba.best.com> from "Julius Smith" at Aug 31, 99 10:57:04 am
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: f10c9568b071512f3c3060d7155aa8eb

Hello Julius, thank you for your very useful responses !

> 
> Hi Benno,
> 
> Your analysis of bandlimited interpolation requirements is correct, and your
> appraisal of the general trade-offs appears fairly complete.  
> We normally use bandlimited interpolation for offline sampling-rate 
> conversion.  For real-time work, we generally use either linear-interpolation
> + oversampled wavetables, or highly optimized conversion filters for certain
> fixed sampling-rate ratios.  

We want to create a free, flexible high- perf. audio engine for Linux
see: http://www.angelfire.com/or/audiality/audiality.html

and it will provide a sample-playback engine with flexible modulation
possibilities, that means we must allow dynamic pitch change during
playback, therefore we can't use conversion filters.

> 
> Emu  (now part of Creative Labs)  samplers have been doing bandlimited
> interpolation in VLSI for many years.  Other samplers lacking special
> interpolation hardware tend to use simple linear interpolation,
> and they might also cross-fade from one table to another as the conversion
> ratio goes beyond a certain point.  (Have a separate table for each octave,
> say, and oversample by a factor of 2.)

Just for curiousity: Is the transposition range of the Emu samplers limited (downwards),
since bandlimited interpolation CPU usage is determined by the resampling
rate ? ( -2, -3 octaves ?)

> 
> For a Linux real-time environment on the PC,
> I think I would recommend the use of oversampled wavetables and linear
> interpolation.  It can be surprising how good simple linear interpolation
> sounds with an oversampling factor of two or more.
>  Your proposal for polynomial interpolation, oversampling by 2,
> and limiting to one octave is a higher quality version of what
> I'm suggesting.

Yes, but my concern is that if we oversample by 2,
since we allow to sample-playback modules to be routed through various
modules like FX-processors , filters etc, we have to run the entire engine
at twice the samplefrequency, and this means twice the CPU load,
Is there no other way to allow flexible voicerouting AND avoiding
to run the entire engine at twice the samplefrequency ?

I think the overhead between linear and higher order polinomial
interpolation is not very big compared to using bandlimited interpolation,
(5-6 mulitiplications per sample is not very much)

therefore I'm thinking about which polinomial-order to use to have
the best tradeoff between quality and CPU usage.

Linear interpolation may work well for playing the sample data at higher
pitches, but for extreme downwards transpositions (-2 octaves) , the
signal has too many edges IMHO.

Has the Spline approach ( 4th order) some signal quality advantages
(worst/best in terms of dB) over let's say quatratic/cubic interpolation ?
(assuming a max transposition range of -2 octaves / +1 octave).

> 
> As processors get more powerful, it might make sense to introduce an option
> for turning on bandlimited interpolation at various compute levels
> for real-time use.  What I've always wanted was to be able to say to the
> audio service "keep audio processing less than or equal to x% of total
> bandwidth", and have the system allocate compute-power up to that limit.
> Thus, during a solo passage, some heavy-duty interpolation might be running,
> while during multivoiced "pads", the system might only be able to afford
> linear interpolation for that many voices under the current bandwidth budget.

Yes, that would be very nice, the goal of Audiality is to give the user
the choice of various interpolation methods, by using pluggable resampling
modules, therefore implementing your dynamic interpolation-method algorithm,
would not be too difficult, since if the user sets a CPU upper limit of
70% the engine could measure CPU usage, and when the CPU is idle or lightly
loaded, the engine could switch interpolation algorithm on the fly (by using
function pointers) , for the loudest voices. (or these with the most sensible
sample material,but this would be hard/impossible to determine automatically).

> A similar "budget" system could be applied to memory usage.
> I've worked with some game designers, for example, who have requested
> that audio consume no more than 10% of the processor bandwidth, since they
> want the rest for graphics.  A budget-based approach is just what they
> wanted.  Of course, the musicians among us might want to devote almost 100%
> of the processor to audio, and they should be able to shoot for that and
> get the best results they can.

Yes, leave the choice to the user if he wants low CPU consumption or
high audio quality.

regards,
Benno.

From - Wed Sep  1 23:46:11 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA09406
	for <slinkp@ulster.net>; Wed, 1 Sep 1999 09:22:25 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA25912 for linux-audio-dev-list; Wed, 1 Sep 1999 08:23:34 -0400
Received: from sculpcave.localdomain (cvx-1-52.dyn.nic.fi [62.236.97.52]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA25909 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Sep 1999 08:23:26 -0400
Received: (from root@localhost)
	by sculpcave.localdomain (8.8.7/8.8.7) id PAA03297;
	Wed, 1 Sep 1999 15:00:34 +0300
Date: Wed, 1 Sep 1999 15:00:33 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
To: Bill@BillSchoolcraft.com
cc: alsa-devel@alsa-project.org, linux-sound@vger.rutgers.edu,
        linux-audio-dev@ginette.musique.umontreal.ca,
        alsa-user@alsa-project.org
Subject: Re: [linux-audio-dev] Re: loopback in action!
In-Reply-To: <37CBC741.3469FC92@wiliweld.com>
Message-ID: <%1RRz383AI@sculpcave>
X-User-Agent: Mana 4.0beta (Linux)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 376c16985970ae8916127f6a99984532

Hello,

On Tue, 31 Aug 1999, Bill wrote:

> 	I recently had a customer who has a hearing disability and uses
> voice emulation and we were in need of driver that would eliminate
> the POP that he was experiencing during .wav, .au, and .voc files,
> not .midi though.
[...]
> 	He has an on-board Crystal Sound chip set. I can't recall the exact
> chip but it was mentioned on the ALSA page, in the howto's. We ended
> up using OSS. Any input on this would be appreciated for you seem to
> be doing some good work from what I read. Thanks.

If problems appeared when starting to play audio and not during 
actual playback, if might be caused by ALSA buffering 
parameters. Raising the minimum fragments value for ALSA playback
should help in this case.

-- 
Kai Vehmanen ----------------------------- CS, University of Turku, Finland
 : email                                 mailto:kaiv@wakkanet.fi
 : audio processing for linux            http://www.wakkanet.fi/ecasound/
 : my music (ambient-idm-rock-...mp3/ra) http://www.wakkanet.fi/sculpscape/


From - Wed Sep  1 23:46:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA28622
	for <slinkp@ulster.net>; Wed, 1 Sep 1999 18:39:24 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA01819 for linux-audio-dev-list; Wed, 1 Sep 1999 17:58:12 -0400
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id RAA01816 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Sep 1999 17:58:10 -0400
Message-Id: <199909012158.RAA01816@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Timed Event Editor Framework
To: Andreas Voss <andreas@avix.rhein-neckar.de>
Date: Wed, 1 Sep 1999 17:54:00 -0400 (EDT)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
In-Reply-To: <Pine.LNX.4.10.9909012346540.420-100000@avix.localnet> from "Andreas Voss" at Sep 1, 99 11:57:02 pm
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: cfbfed2a0a28fdbac63e674f69590131

Andreas Voss wrote:
> There is a well known design pattern called 'iterator', that you will find
> in all object oriented collection classes. Such classes can encapsulate
> the physical (nested) structure of the events. Lets complicate the example
> further, lets assume we want to process only note events in a given time
> range. Without the iterator, this would look like
> 
>         for each_group in merged_groups
>           for each_track in each_group
>             if e.type == note
>               if e.time >= start_time
>                 if e.time < stop_time
>                   // process e
> 
> You can encapsulate all this in an Iterator object, e.g.
> 
>         Iterator it = new Iterator();
>         it.setType(note);
>         it.setTimeRange(start_time, stop_time);
>         while (it.hasNext()) {
>           e = it.getNext();
>           // process e
>         }

Or if the language has higher-order functions, you can do this by
composing the ones you're using to get a new one.  So something like
   map (fn group => 
        map (fn track =>
             map_if (fn e => e.time >= start_time && 
                             e.time < stop.time) 
                     process_e
                     track)
            group)
        merged_groups

or then name that functional gunk:
var my_so_called_iterator = 
   map (fn group => 
        map (fn track =>
             map_if (fn e => e.time >= start_time && 
                             e.time < stop.time) 
                     process_e
                     track)
            group)

my_so_called_iterator merged_groups

(Nothing personal, but iterators make me itch.)

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Wed Sep  1 23:46:18 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA03473
	for <slinkp@ulster.net>; Wed, 1 Sep 1999 15:48:47 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA01352 for linux-audio-dev-list; Wed, 1 Sep 1999 15:01:40 -0400
Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA01349 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Sep 1999 15:01:35 -0400
Received: (from uucp@localhost)
	by news-ma.rhein-neckar.de (8.8.8/8.8.8) with UUCP id UAA16199;
	Wed, 1 Sep 1999 20:56:40 +0200 (CEST)
	(envelope-from andreas@avix.rhein-neckar.de)
Received: from localhost (andreas@localhost [127.0.0.1])
	by avix.localnet (8.9.3/8.9.3) with ESMTP id XAA00696;
	Wed, 1 Sep 1999 23:57:02 +0200
Date: Wed, 1 Sep 1999 23:57:02 +0200 (MEST)
From: Andreas Voss <andreas@avix.rhein-neckar.de>
X-Sender: andreas@avix.localnet
To: eli+@cs.cmu.edu
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Timed Event Editor Framework
In-Reply-To: <199909010923.FAA25494@ginette.musique.umontreal.ca>
Message-ID: <Pine.LNX.4.10.9909012346540.420-100000@avix.localnet>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ce62f4ae46a13616658a021edae86afb

On Mon, 30 Aug 1999, Eli Brandt wrote:

> How about escalating the structure's tree-depth?  The first version
> gets more for-each levels but the inner loop stays clean:
> 
>         for each_group in merged_groups
>                 for each_track in each_group
>                         old_e.time = e.time;  output old_e
>                         old_e = e

There is a well known design pattern called 'iterator', that you will find
in all object oriented collection classes. Such classes can encapsulate
the physical (nested) structure of the events. Lets complicate the example
further, lets assume we want to process only note events in a given time
range. Without the iterator, this would look like

        for each_group in merged_groups
          for each_track in each_group
            if e.type == note
              if e.time >= start_time
                if e.time < stop_time
                  // process e

You can encapsulate all this in an Iterator object, e.g.

        Iterator it = new Iterator();
        it.setType(note);
        it.setTimeRange(start_time, stop_time);
        while (it.hasNext()) {
          e = it.getNext();
          // process e
        }

One big advantage of this approach is, that you can reuse the logic of the
iterator in other situations.

Andreas

From - Wed Sep  1 23:46:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA13180
	for <slinkp@ulster.net>; Wed, 1 Sep 1999 16:53:28 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA01558 for linux-audio-dev-list; Wed, 1 Sep 1999 16:04:53 -0400
Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA01554 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Sep 1999 16:04:43 -0400
Received: (from uucp@localhost)
	by news-ma.rhein-neckar.de (8.8.8/8.8.8) with UUCP id VAA20045;
	Wed, 1 Sep 1999 21:43:07 +0200 (CEST)
	(envelope-from andreas@avix.rhein-neckar.de)
Received: from localhost (andreas@localhost [127.0.0.1])
	by avix.localnet (8.9.3/8.9.3) with ESMTP id AAA00983;
	Thu, 2 Sep 1999 00:28:18 +0200
Date: Thu, 2 Sep 1999 00:28:18 +0200 (MEST)
From: Andreas Voss <andreas@avix.rhein-neckar.de>
X-Sender: andreas@avix.localnet
To: est@hyperreal.org
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] streaming xml
In-Reply-To: <19990829204956.24432.qmail@hyperreal.org>
Message-ID: <Pine.LNX.4.10.9909020009230.420-100000@avix.localnet>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f3b8acd9f1a7add03ced072614deea30

On Sun, 29 Aug 1999 est@hyperreal.org wrote:

> Hmm..could SAX stand for `semantic actions'?  I'm a yaccer from way
> back. :)

No, it stands for `Simple API for XML' and is some kind of standard in the
java world. The parser informs the application thru event handlers
(callback functions) whenever it finished parsing a useful information
unit (e.g. a complete tag like <event pitch="72" velocity="45">). This
notification happens `in real time' during the parsing process and
probably could be used for streaming. Compared to yacc its a low level
API.

Andreas


From - Wed Sep  1 23:46:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA08035
	for <slinkp@ulster.net>; Wed, 1 Sep 1999 20:07:25 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA01970 for linux-audio-dev-list; Wed, 1 Sep 1999 19:32:23 -0400
Received: from proxy4.ba.best.com (proxy4.ba.best.com [206.184.139.15]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA01967 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Sep 1999 19:32:20 -0400
Received: from julius (dynamic39.pm06.mv.best.com [209.24.241.103])
	by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with SMTP id QAA23083;
	Wed, 1 Sep 1999 16:26:04 -0700 (PDT)
Message-Id: <199909012326.QAA23083@proxy4.ba.best.com>
X-Sender: julius@shell16.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Wed, 01 Sep 1999 16:29:29 -0700
To: Benno Senoner <sbenno@em.gardena.net>
From: Julius Smith <jos@w3k.org>
Subject: [linux-audio-dev] Re: Bandlimited interpolation suitable for realtime audio
Cc: sbenno@gardena.net, linux-audio-dev@ginette.musique.umontreal.ca,
        audiality@swipnet.se, pbd@op.net, jos@ccrma.Stanford.EDU
In-Reply-To: <199909011016.MAA12855@em.gardena.net>
References: <199908311753.KAA10968@proxy3.ba.best.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA08035
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 23d2420401010c285f9f4d6278a8c3d3

Hi again,

>We want to create a free, flexible high- perf. audio engine for Linux
>see: http://www.angelfire.com/or/audiality/audiality.html ...

Excellent!  This is really needed.  I have a Linux system at home and it's my first choice for all my research related work.

>and it will provide a sample-playback engine with flexible modulation
>possibilities, that means we must allow dynamic pitch change during
>playback, therefore we can't use conversion filters.

I assume you mean _fixed_ conversion filters.

>Just for curiousity: Is the transposition range of the Emu samplers limited (downwards),
>since bandlimited interpolation CPU usage is determined by the resampling
>rate ? ( -2, -3 octaves ?)

I don't know.  I don't own any Emu hardware myself at the moment, so I can't check it.   However, I think I heard a demo taking a middling pitch all the way down to deep bass.  What I would do if I were them is simply truncate the filter at some maximum length.   The way the filter gets longer when going down is very simple: it merely "dilates" by the conversion ratio.  This is implemented by scaling the step-size through the filter table by the inverse of this ratio.  When the table starts stretching outrageously, one can simply end the table traversal when a prescribed number of samples has been returned.  In the limit of driving the pitch all the way down to dc, the step-size goes to zero, and the returned filter becomes a simple "boxcar" moving-average filter at some maximum length set by the system --- not a great filter, but reasonable, and what else can you do that's better and less expensive?  The ideal lowpass filter really is a constant impulse response, only infinitely long.

>... my concern is that if we oversample by 2,
>since we allow to sample-playback modules to be routed through various
>modules like FX-processors , filters etc, we have to run the entire engine
>at twice the samplefrequency, and this means twice the CPU load,
>Is there no other way to allow flexible voicerouting AND avoiding
>to run the entire engine at twice the samplefrequency ?

The oversampling need only affect the wavetables themselves.  It just means doubling the memory over what you would have had.  Consider, for example, how it would work if you somehow encoded the wavetables as exact continuous functions.  In principle, they would be oversampled by infinity.  However, the playback oscillator just asks for them at intervals of the current sampling period (which can change to any value at any time, without regard for the "phase alignment" of the sampling points).

>I think the overhead between linear and higher order polinomial
>interpolation is not very big compared to using bandlimited interpolation,
>(5-6 mulitiplications per sample is not very much)

Ok, but if you compare, I think you'll find that quadratic interpolation is not nearly as big of an improvement over linear as linear interpolation is over no interpolation.    The reason is that if the wavetable is very "smooth" (which can always be provided by densely sampling the original bandlimited audio), then the exact "Taylor series expansion" (infinite-order polynomial interpolation, if you will), has coefficients which rapidly decrease with order.  In other words, linear interpolation will nail it to the last LSB if your table is oversampled enough, so that there's no reason to waste multiply-adds on higher-order interpolation.  (You may need a few guard bits below.)  The main appendix in my "theory of operation" paper gives a precise derivation of what I'm saying for the case in which the wavetable contains a sinc function.  In that case, linear interpolation is "exact" to working provision provided there are a few hundred samples per zero-crossing of the sinc function stored in the wavetable.  In a general wavetable synthesizer, this spec could translate to some number of samples per zero-crossing of the _highest harmonic_ present in the wavetable.  Of course, when the highest harmonic is very weak (as it normally is), requirements are really less stringent than this.

Another point is that if you're willing to spend 5-6 mulitiplications per sample on interpolation, I don't believe polynomial interpolation is superior to bandlimited interpolation at that complexity level.   To compare them, we have to view polynomial interpolation in terms of its frequency response as a "bandlimited interpolation filter".  (After all, both methods simply implement time-varying linear filters on the original samples, so on that level they are equivalent --- they only differ fundamentally in the coefficients used.)  The classic paper on this topic is the one by Schafer and Rabiner cited in my tutorial:


@ARTICLE{SchaferAndRabiner,
	AUTHOR = "R. W. Schafer and L. R. Rabiner", 
	TITLE = "A Digital Signal Processing Approach to Interpolation",
	JOURNAL = ieee_proc,
	VOLUME = 61,
	PAGES = {692--702},
	MONTH = "June",
	YEAR = 1973
}

>Has the Spline approach ( 4th order) some signal quality advantages
>(worst/best in terms of dB) over let's say quatratic/cubic interpolation ?
>(assuming a max transposition range of -2 octaves / +1 octave).

Well, it's order is one higher than cubic so it should be that much better than cubic.   I consider all of these cases to fall under the topic of "Lagrange interpolation".  An excellent reference, available online, is

@PHDTHESIS{VesaT,
	AUTHOR = "Vesa {V\"alim\"aki}",
	TITLE = "Discrete-Time Modeling of Acoustic Tubes Using 
		Fractional Delay Filters",
	SCHOOL = "Report no. 37, Helsinki University of Technology, Faculty of \Elec\ \Eng, 
		 \Lab\ of Acoustic and Audio Signal Processing, Espoo, Finland",
	MONTH = "Dec.", 
	YEAR = 1995
}

It can be found online at

	http://www.acoustics.hut.fi/~vpv/publications/vesa_phd.html

In general, polynomial interpolation gives filters with a rapid roll-off (in gain versus frequency), but they exhibit a lot of "droop" at the edge of the passband.   This means the highest harmonics will come out attenuated.  

Ultimately, the question is how do you want to design the lowpass filter that guards against aliasing.  The bandlimited interpolation formulation allows you to address that issue explicitly rather than just "getting what you get" with polynomial interpolation.

Julius

From - Wed Sep  1 23:46:40 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA28289
	for <slinkp@ulster.net>; Wed, 1 Sep 1999 22:14:03 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA02129 for linux-audio-dev-list; Wed, 1 Sep 1999 21:37:12 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA02126 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Sep 1999 21:37:09 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id VAA12609
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Sep 1999 21:32:33 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id VAA03731; Wed, 1 Sep 1999 21:32:32 -0400 (EDT)
Date: Wed, 1 Sep 1999 21:32:29 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Timed Event Editor Framework
In-Reply-To: <199909010923.FAA25494@ginette.musique.umontreal.ca>
Message-ID: <Pine.GSO.4.10.9909012117120.2613-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e0f5b23900bc029b27972e947196145a

On Mon, 30 Aug 1999, Eli Brandt wrote:

(continuing the debate over whether or not to merge tracks for the
internal representation of data in a MIDI sequencer)

> How about escalating the structure's tree-depth?  The first version
> gets more for-each levels but the inner loop stays clean:
> 
>         for each_group in merged_groups
>                 for each_track in each_group
>                         old_e.time = e.time;  output old_e
>                         old_e = e
> 
>  vs.
> 
>         for each event e in flattened_all_groups_in_tracks
>                 this_old_e = (old_e[e.track])[e.group]
>                 this_old_e.time = e.time;  output this_old_e
>                 (old_e[e.track])[e.group] = e
> 
> And with a more-involved structure the second loop involves things like
> (((old_e[e.level1index])[e.level2index])[e.level3index])[e.level4index]
> (and that isn't a one-piece multidimensional array).

I'm afraid I don't understand this part here.  I'm not sure what you
mean by a "group".  Remember that the model I'm discussing is not supposed
to support patterns, loops, etc, but rather just a linear list (or
parallel linear lists) of events.

> Other sorts of scenarios: apply a function to some part of a musical
> structure -- call it on that part of the data structure, or grovel
> through all the data elements determining whether they're in the part?
> (Is speed a concern?)  Rearrange a musical structure -- twiddle
> pointers at the top level, or grovel again munging all the data
> elements' tags?

The point about speed is well taken.  

As for "rearranging musical structure", that sounds like a heavyhanded way
of saying "reordering the tracks".  I agree that exchanging two pointers
in a list of tracks is far easier and faster than modifying an integer
"track number" field for every event in the two tracks in question.
 
You have me pretty much convinced (remember, we weren't fighting after
all :-) ), but I do have one more issue that would need to be resolved:

In the merged list, there is one definite, user and API controlled order
of events.  No two events are truly simultaneous, even if they have the 
same timestamp.  This is advantageous for purposes like dropping markers
(I'm a HUGE fan of using markers rather than selections for editing 
except when you need discontinous selection).  It is perfectly valid to
drop a marker between two events with the same timestamp.  How do you
handle this when you use separate lists for separate tracks?

Nearly convinced,
Div.

From - Wed Sep  1 23:46:42 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA00503
	for <slinkp@ulster.net>; Wed, 1 Sep 1999 22:43:12 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA02204 for linux-audio-dev-list; Wed, 1 Sep 1999 22:09:14 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA02201 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Sep 1999 22:09:12 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id WAA14121
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Sep 1999 22:04:00 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id WAA04537; Wed, 1 Sep 1999 22:03:59 -0400 (EDT)
Date: Wed, 1 Sep 1999 22:03:56 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Timed Event Editor Framework
In-Reply-To: <199909012158.RAA01816@ginette.musique.umontreal.ca>
Message-ID: <Pine.GSO.4.10.9909012155410.2613-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0578e1ecbb1130abf236579852f0cfe7

On Wed, 1 Sep 1999, Eli Brandt wrote:

> Or if the language has higher-order functions, you can do this by
> composing the ones you're using to get a new one.

Errrgh.  I can think in procedural.  I can think in OO.  I can think
in list-oriented.  I can even think in stack-based.  Trying to think in
functional always makes my head ache.

Not to put functional programming down... it is abstractly very neat, but
I had a fairly bad experience with SML-NJ, and an absolutely aweful time
with pure lamda calc (damnit, I don't want to have to derive the concepts
of one and zero!).

On a more pragmatic note, I was shooting to implement this in Java, which
although it is a bastard child of languages, did not manage to inherit
the concept of functional programming.  Actually, now that I think about
it, you probably could do it by making abusive use of java.lang.Class, but
I wouldn't recommend it.

Div.

From - Thu Sep  2 12:19:49 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA02376
	for <slinkp@ulster.net>; Thu, 2 Sep 1999 06:54:21 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA02830 for linux-audio-dev-list; Thu, 2 Sep 1999 05:10:59 -0400
Received: from pat.bath.ac.uk (pat.bath.ac.uk [138.38.32.2]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id FAA02827 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 2 Sep 1999 05:10:55 -0400
Received: (qmail 14145 invoked from network); 2 Sep 1999 09:07:33 -0000
Received: from mary.bath.ac.uk (HELO bath.ac.uk) (mmdf@138.38.32.14)
  by pat.bath.ac.uk with SMTP; 2 Sep 1999 09:07:33 -0000
Received: from tobi.bath.ac.uk by mary.bath.ac.uk id aa11487; 2 Sep 99 10:07 BST
Message-ID: <37CE3E55.794B@bath.ac.uk>
Date: Thu, 02 Sep 1999 10:07:33 +0100
From: "P.J.Leonard" <P.J.Leonard@bath.ac.uk>
Organization: Applied Electromagnetic Research Centre
X-Mailer: Mozilla 3.0 (X11; I; OSF1 V2.0 alpha)
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Structure 
References: <Pine.GSO.4.10.9909012155410.2613-100000@ux02.CS.Princeton.EDU>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: f0b361a8a4c56177a870bb47b886146c

Hello Linux audio people,

 Since there has been some interest in tracks and events I will
contribute my own little scheme for your musings. This structure is
the result of a few years evolution. What follows is the skeleton of the
structure.


 The class structure is            [A] == abstract


    Component[A]
     /      \
 Part         Gesture[A]
             /   |     \
          Note  Effect Sweep   whatever


 A Component is not completely abstract it has

    A parent    (another component,  root of song has a null parent)
    next and prev pointers to implement an double linked list.
    time        (used relative to its parents time to get absolute)
    voiceId     (used to resolve the device patch etc. if this is null
                 the inherits the parent voice)
    trackId     (used for cosmetics GUI stuff for vertical placement)



 A Part contians a linked list components. This gives you the
tree structure for a song.

 To sequence this structure you need to implement a part sequencer
and the sequencers for the concrete gestures. For example a note
sequencer generates 2 events NOTEON then NOTEOFF.  A sweep gesture
generates many events for a given effect to make a nice wah for example.

 All the sequencing is done in real time with real time priority.
So all events get stuffed straight out to devices
(at present using OSS with dump straight away but will migratiate to 
ALSA once it stabalises). 

 The plan is to include real audio as another gesture.
 Software synths would look like another midi device.
 
 Please note and feel free to comment on the following:

  the lack of tracks in this scheme.
  the abitrary depth of recursion in the Parts within Parts etc.
  the nightmare of designing a user interface for such a beast.
  Editing is done in a lazy fashion. I never delete any components
  so you do not get problems because with dangling pointers. Later
  I may implemnt some garbage collection.

-- 
 Cheers Paul (P.J.Leonard)

From - Thu Sep  2 12:29:49 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA16470
	for <slinkp@ulster.net>; Thu, 2 Sep 1999 12:37:41 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA03344 for linux-audio-dev-list; Thu, 2 Sep 1999 11:14:40 -0400
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id LAA03341 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 2 Sep 1999 11:14:38 -0400
Message-Id: <199909021514.LAA03341@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Timed Event Editor Framework
To: David Slomin <dgslomin@CS.Princeton.EDU>
Date: Thu, 2 Sep 1999 11:10:54 -0400 (EDT)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
In-Reply-To: <Pine.GSO.4.10.9909012117120.2613-100000@ux02.CS.Princeton.EDU> from "David Slomin" at Sep 1, 99 09:32:29 pm
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d5d1c5d21e24e977cfc71e31b390396b

David Slomin wrote:
> I'm afraid I don't understand this part here.  I'm not sure what you
> mean by a "group".  Remember that the model I'm discussing is not supposed
> to support patterns, loops, etc, but rather just a linear list (or
> parallel linear lists) of events.

If a flat list of tracks is the extent of the structure you present to
the user, it may not much matter which way you implement it.

> In the merged list, there is one definite, user and API controlled order
> of events.  No two events are truly simultaneous, even if they have the 
> same timestamp.  This is advantageous for purposes like dropping markers
> (I'm a HUGE fan of using markers rather than selections for editing 
> except when you need discontinous selection).  It is perfectly valid to
> drop a marker between two events with the same timestamp.  How do you
> handle this when you use separate lists for separate tracks?

Dunno offhand.  First off, I think my idea of time says that if two
events aren't at the same time, they shouldn't have the same timestamp.
Maybe make the timestamp a pair (time, tiebreaker) and order
lexicographically.

I don't think I understand the difference between markers and
selections.  A marker is an event, while a selection endpoint isn't?
But that's an implementation detail, not user-visible.

Anyway, my seat-of-the-pants design would be a list of timestamps at
each structure node: at track and at "all tracks" in your case.  These
times could be selection endpoints, defining selected intervals that
are, say, closed on the left and open on the right (start <= time <
end).  Then you effectively union-or-xor-or-whatever-seems-useful the
all-tracks selection with that of the particular track.

Or maybe the timestamp could be markers, where the marked instant is
defined as the leftmost point of the interval corresponding to that
timestamp.  I think I'm nervous about really making markers events,
because you get into a situation where you've got events at t and t+1
and want to drop something in between, and there is no such time.
(Unless your timestamps are scary and unbounded in length.)  Whereas if
you have a selection-endpoint timestamp at t+1, that selects exactly one
of the two events.

Hmm, equivalently you could make timestamps triples, (time, tiebreaker,
is-a-marker?); then you could put markers in tracks and have them slip
between events, but not between other markers.

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Sat Sep  4 00:38:31 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA11725
	for <slinkp@ulster.net>; Fri, 3 Sep 1999 15:29:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA08965 for linux-audio-dev-list; Fri, 3 Sep 1999 14:34:07 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA08961 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 3 Sep 1999 14:34:01 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id VAA28914
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 2 Sep 1999 21:46:45 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id VAA09928; Thu, 2 Sep 1999 21:46:45 -0400 (EDT)
Date: Thu, 2 Sep 1999 21:46:42 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Timed Event Editor Framework
In-Reply-To: <199909021511.LAA22113@CS.Princeton.EDU>
Message-ID: <Pine.GSO.4.10.9909022106070.9198-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d8297ee2dd9e50f6897894a9dc483532

On Thu, 2 Sep 1999, Eli Brandt wrote:

> Dunno offhand.  First off, I think my idea of time says that if two
> events aren't at the same time, they shouldn't have the same timestamp.
> Maybe make the timestamp a pair (time, tiebreaker) and order
> lexicographically.

Scary, but a potential solution.  I'm not crazy about an arbitrary
tiebreaker field which would be used for nothing else.  It seems a little
far removed from the music, but then so is any system in which
simultaneous events have a distinct order.
 
> I don't think I understand the difference between markers and
> selections.  A marker is an event, while a selection endpoint isn't?
> But that's an implementation detail, not user-visible.

That's it exactly, but I meant to make it (optionally) user-visible.
The implementation of course would have to drop markers at the left and
right of a drag selection, but the user could also place them manually.
This allows several things:

1.  Accuracy.  A drag selection doesn't lend itself to popping up a dialog
box when it's necessary to type in an exact timestamp.  Cakewalk, for
example, gets around this by using three markers (begin, end, and now) but
doesn't allow an arbitrary list of markers.

2.  Bookmarks.  Especially since I'm pushing for a non-structured
sequencer, jumping around the file to arbitrary timestamps is pretty
important.  If you've ever used a text editor equipped with markers,
you'll never want to do without them again (Vi sold me on them, but it's
not unique in this regard).

3.  Persistance.  If markers are implemented as events (and yes, there
really is a standard defined "marker" event in SMF), then they can be
saved with the file, which can be convenient.

That said, they're less convenient for discontiguous selections, so I'll
have to handle those separately (unless you can recommend a better way).

> I think I'm nervous about really making markers events, because you
> get into a situation where you've got events at t and t+1 and want to
> drop something in between, and there is no such time. (Unless your
> timestamps are scary and unbounded in length.)  Whereas if you have a
> selection-endpoint timestamp at t+1, that selects exactly one of the
> two events.

That's where the single-merged-list-of-events-per-song model helps. To
insert a marker between two events even with the same timestamp, just
insert it between them.  That way you don't need infinitely accurate
timestamps... you don't have to change the marker's timestamp to guarantee
a specific order.  

BTW, I have at least two hitherto unseen sequencer interface concepts
I'm itching to implement that rely on having markers work this way:

The first I call "rhythm shadows".  You select a phrase (or such), and run
a function (plugin, etc) on it.  The plugin creates a marker for each
note-on and note-off at the same timestamps.  These markers can now be
copied and pasted anywhere without the notes of the phrase, but preserving
the phrase's rhythm.  

You then use a custom pencil (note insert) tool that quantizes start time
and duration to the nearest markers.  Voila, same rhythm, new melody.  
Delete the markers when you're done, or set an option on the pencil tool
to do it automatically as you go.

I haven't come up with a decent name for the second function, but I've
referred to it on this list before as "semi-automatic interpolating
timestamp adjust".  It's meant to make quantizing a thing of the past. To
use it, first record the song in realtime, ignoring the sequencer's
metronome entirely.  This is essential for me, because I don't hold a
tempo very well when I'm playing the piano (shame on me, I should be more
disciplined).  

Next, look at what you recorded.  The rhythm will be approximately correct
(even if the tempo changes over time), but the actual measures won't line
up with what the sequencer calls measures. Drop some markers at points in
the music for which you know the intended timestamp (regardless of what
the sequencer thinks the marker's timestamp is).  Label each of those
markers with a string version of the intended timestamp (in some syntax
which has yet to be decided).  

Run the nifty function (plugin, etc), and it will adjust the timestamps of
all events in the specified range so that the intended timestamps become
real.  Everything between the markers will be linearly interpolated.

This runs rings around quantization for three reasons:  first, it works
even if you're _really_ far off from the intended rhythm; second, it
doesn't lose rhythmic nuances unless you tell it to; and third, it handles
any sort of rhythm you want, not just straight and swing.

See why I like markers?  :-)
Div.

From - Sat Sep  4 00:38:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA12432
	for <slinkp@ulster.net>; Fri, 3 Sep 1999 15:35:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA08964 for linux-audio-dev-list; Fri, 3 Sep 1999 14:34:04 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA08958 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 3 Sep 1999 14:34:00 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id WAA01430
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 2 Sep 1999 22:38:22 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id WAA10810; Thu, 2 Sep 1999 22:38:21 -0400 (EDT)
Date: Thu, 2 Sep 1999 22:38:18 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Structure 
In-Reply-To: <37CE3E55.794B@bath.ac.uk>
Message-ID: <Pine.GSO.4.10.9909022218480.9198-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1f2df244de3fa6ac027c84afb618ca04

On Thu, 2 Sep 1999, P.J.Leonard wrote:

> Since there has been some interest in tracks and events I will
> contribute my own little scheme for your musings. This structure is
> the result of a few years evolution. What follows is the skeleton of the
> structure.

I'm very impressed... that sounds quite near optimal for a
strongly-structured song representation.  However, I think what you've
designed is not a sequencer, but an song representation language, a la
Common Music (CCRMA).  CM shares a fairly similar design, and is not
realtime or GUI oriented... just the issues you mentioned.  If you
implement yours so that it is not so heavily tied down to Lisp (as is CM),
then I'll personally be quite interested in using it.

Keep in mind that I think a structured song representation language and a
sequencer make very good complementary tools, each of which is doomed to
fail if it tries to subsume the tasks of the other.  

Then again, where does that put JMax, which falls somewhere in between.
It's not suited to be a sequencer, but it runs in realtime.  It's far from
optimized at representing the complete structure of a song, yet inherently
deals with heirarchical structure (a "phrase start" event triggers the
events within that phrase to be output, and so forth).  It even goes a
step further, by allowing the "parts within parts" to be dynamic or even
nondeterministic.

Hmm,
Div.

From - Sat Sep  4 00:38:34 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA18414
	for <slinkp@ulster.net>; Fri, 3 Sep 1999 16:16:14 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA09130 for linux-audio-dev-list; Fri, 3 Sep 1999 15:32:58 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA09127 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 3 Sep 1999 15:32:56 -0400
From: est@hyperreal.org
Received: (qmail 4504 invoked by uid 162); 3 Sep 1999 19:28:43 -0000
Message-ID: <19990903192843.4503.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] Re: Timed Event Editor Framework
In-Reply-To: <Pine.GSO.4.10.9909022106070.9198-100000@ux02.CS.Princeton.EDU>
 from David Slomin at "Sep 2, 1999 09:46:42 pm"
To: David Slomin <dgslomin@CS.Princeton.EDU>
Date: Fri, 3 Sep 1999 12:28:42 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 8f17fcb92f36683d1d0d5f7eb74bf563

David Slomin discourseth:
> 
> I haven't come up with a decent name for the second function, but I've
> referred to it on this list before as "semi-automatic interpolating
> timestamp adjust".

Hmm..how bout `meter-cast'..since you're casting a meter between two
points or `meter-snap' since you're conforming your meter to your data
instead of vice versa.

Anyhow, this is a great discussion!

Eric

From - Sat Sep  4 00:38:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA19475
	for <slinkp@ulster.net>; Fri, 3 Sep 1999 16:23:32 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA09147 for linux-audio-dev-list; Fri, 3 Sep 1999 15:38:46 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA09144 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 3 Sep 1999 15:38:39 -0400
From: est@hyperreal.org
Received: (qmail 8964 invoked by uid 162); 3 Sep 1999 19:32:35 -0000
Message-ID: <19990903193235.8961.qmail@hyperreal.org>
Subject: [linux-audio-dev] good csound virtual midi synths
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Fri, 3 Sep 1999 12:32:35 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: b480b6bc81219ea7e0d571af14013fa1

Can anyone recommend some good csound virtual synthesizers taking midi
input?  The micall.{sco,orc} in the csound examples is an example of
what I'm talking about.

Also, orcs that combine midi input with alternate tunings would be
interesting though *that* part seems pretty easy to figure out. :)

Eric

From - Sat Sep  4 00:38:37 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA12445
	for <slinkp@ulster.net>; Fri, 3 Sep 1999 19:40:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA09383 for linux-audio-dev-list; Fri, 3 Sep 1999 19:04:41 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA09380 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 3 Sep 1999 19:04:36 -0400
Received: from linuxhost.localdomain (IDENT:root@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id BAA27277;
	Sat, 4 Sep 1999 01:00:28 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id DAA04220;
	Sat, 4 Sep 1999 03:01:13 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Julius Smith <jos@w3k.org>, Benno Senoner <sbenno@em.gardena.net>
Subject: [linux-audio-dev] Re: Bandlimited interpolation suitable for realtime audio
Date: Sat, 4 Sep 1999 01:57:28 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: sbenno@gardena.net, linux-audio-dev@ginette.musique.umontreal.ca,
        audiality@swipnet.se, pbd@op.net, jos@ccrma.Stanford.EDU
References: <199909012326.QAA23083@proxy4.ba.best.com>
MIME-Version: 1.0
Message-Id: <99090403011300.00815@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: e723beba594d35f2829b21b7831152a7

Hello,

On Thu, 02 Sep 1999, Julius Smith wrote:
> Hi again,
> 
>> 
>
> >... my concern is that if we oversample by 2,
> >since we allow to sample-playback modules to be routed through various
> >modules like FX-processors , filters etc, we have to run the entire engine
> >at twice the samplefrequency, and this means twice the CPU load,
> >Is there no other way to allow flexible voicerouting AND avoiding
> >to run the entire engine at twice the samplefrequency ?
> 
> The oversampling need only affect the wavetables themselves.
>  It just means doubling the memory over what you would have had.  Consider,
> for example, how it would work if you somehow encoded the wavetables as exact
> continuous functions.  In principle, they would be oversampled by infinity. 
> However, the playback oscillator just asks for them at intervals of the
> current sampling period (which can change to any value at any time, without
> regard for the "phase alignment" of the sampling points).

Ok, but we are speaking of sample playback engines,
that means I have arbitrary  data (a WAV file) sampled that 44.1kHz , and want
to play the data at pitches up to 1 octave higher but without aliasing effects.
Assume we use only linear interpolation, and we want to play the data at
1.5 of the original pitch.
Without oversampling we would advance the source offset pointer by 1.5
on each step (step-size), and use interpolation (through evaluating non integer
part) the get the values of of samples at non-integer boundaries.
But in this case we are already in the aliasing area.

By oversampling by a factor of 2 , we reduce the stepsize to 0.75 with no
aliasing noise, but we have to play the data back at 88.2kHz,
or lowpassfilter the result at 20kHz, and then extract only the even (or odd)
samples and send the result to our 44.1kHz DAC.
Correct me please if I miss something.

If this is the only approach for oversampling, then the drawback is it's use of
in a comple audio engine like audiality,
since you have to run the entire signal-path at twice the samplingrate,
until you output the results to the DAC.
This is very expensive in terms of CPU usage.
Another approach could be to put a 20kHz lowpassfilter after each
polinomial interpolator/oversampler,
but that means if you play 30 voices on your soft-sampler you have to
activate 20 low-passfilters which means additional CPU consumption. 


> >I think the overhead between linear and higher order polinomial
> >interpolation is not very big compared to using bandlimited interpolation,
> >(5-6 mulitiplications per sample is not very much)
> 
> Ok, but if you compare, I think you'll find that quadratic interpolation is not nearly as big of an
>  improvement over linear as linear interpolation is over no interpolation.   
> The reason is that if the wavetable is very "smooth" (which can always be
> provided by densely sampling the original bandlimited audio), then the exact
> "Taylor series expansion" (infinite-order polynomial interpolation, if you
> will), has coefficients which rapidly decrease with order.  In other words,
> linear interpolation will nail it to the last LSB if your table is oversampled
> enough, so that there's no reason to waste multiply-adds on higher-order
> interpolation.  (You may need a few guard bits below.)  The main appendix in
> my "theory of operation" paper gives a precise derivation of what I'm saying
> for the case in which the wavetable contains a sinc function.  In that case,
> linear interpolation is "exact" to working provision provided there are a few
> hundred samples per zero-crossing of the sinc function stored in the
> wavetable.  In a general wavetable synthesizer, this spec could translate to
> some number of samples per zero-crossing of the _highest harmonic_ present in
> the wavetable.  Of course, when the highest harmonic is very weak (as it
> normally is), requirements are really less stringent than this. > 

I want an interpolation method that has good quality , even when you play
the data at let's say -2 octaves, but does not use too much multiply-adds.

Using linear interpolating condributes to "edges" into the signal , which means
harmonic distortion.

I experimented a bit with the "natural cubic spline"  ( 3rd order) ,
I tested this by sampling 2 periods (4*PI) of a pure sine ,
using 20 points.
for the first 17 samples the maximum error between interpolated signal
and original sine is about -68dB which is quite good if you consider that
there are only 10 points per 2PI period.
The last 3 samples show higher errors , up to -35dB, but I think this is
because the interpolator does not know how the sine wave continues.
It's interesting that the last sample is one step before the next zero cross,
and if I choose 21 points (therefore including the last zero cross),
the maximum error stays below the   -68dB mark even for the last samples.
The algorithm takes about 12 multiplications per sample or so.

comments about this algorithm ?
(There seems to be some software aroung which uses the spline approach
to perform audio interpolation)


> Another point is that if you're willing to spend 5-6 mulitiplications per sample on interpolation, 
>I don't believe polynomial interpolation is superior to bandlimited
>interpolation at that complexity level.   To compare them, we have to view
>polynomial interpolation in terms of its frequency response as a "bandlimited
>interpolation filter".  (After all, both methods simply implement time-varying
>linear filters on the original samples, so on that level they are equivalent
>--- they only differ fundamentally in the coefficients used.)

About the complexity level of bandlimited interpolation:

Using polinomial interpolation the number of multiplications per sample stays
constant, regardless of pitch, we just have to traverse the wave table faster
or slower.
Using bandlimited interpolation , lowering the pitch by 2 octaves produces four
times the CPU load of the playback at normal pitch.
The big advantage of bandlimited interpolation is that you can play the data
at higher pitches without aliasing problems + higher pitches = no increased CPU
load.
correct me please if I'm wrong. 

> >Has the Spline approach ( 4th order) some signal quality advantages
> >(worst/best in terms of dB) over let's say quatratic/cubic interpolation ?
> >(assuming a max transposition range of -2 octaves / +1 octave).
> 
> Well, it's order is one higher than cubic so it should be that much better than cubic.
> I consider all of these cases to fall under the topic of "Lagrange
> interpolation".  An excellent reference, available online, is > 

> 	TITLE = "Discrete-Time Modeling of Acoustic Tubes Using 
> 		Fractional Delay Filters",
> 
> It can be found online at
> 
> 	http://www.acoustics.hut.fi/~vpv/publications/vesa_phd.html

nice paper , very heavy math  .. :-)

But even this paper mentions something about Splines (only references) in
the Lagrange interpolation chapter.


> Ultimately, the question is how do you want to design the lowpass filter that guards against aliasing.
>  The bandlimited interpolation formulation allows you to address that issue
> explicitly rather than just "getting what you get" with polynomial
> interpolation. 

What kind of 20kHz lowpass filter would you recommend ?
Butterworth / Bessel / Chebyshev ?  which order ? ( is 6th order to heavy ?)

Which factors are more important for sample-playback engines ?
(like impulse response , step response etc.)

I jus did a quick math:

let's assume a spline interpolator + 6th order ( 36dB/oct)  Butterworth
lowpass at 20kHz
12 multiplications for the interpolator and 9 for the lowpass filter =
21 multiplications.

Let's assume playback at pitch -2 octaves:
nr.of multiplications / output-sample:

104 for bandlimited  interpolation
21 for the cubic interpolation + lowpass filter.

correct ?

(David: your thoughts about quality vs. performance tradeoffs ?)

this page for interactive filter design with realtime-generated graphs is quite
nice.
http://www-users.cs.york.ac.uk/~fisher/mkfilter/

regards,
Benno.

Benno Senoner
E-Mail: sbenno@gardena.net
Linux low-latency audio / scheduling latency benchmarks
http://www.gardena.net/benno/linux/audio

From - Sat Sep  4 00:38:42 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA29964
	for <slinkp@ulster.net>; Fri, 3 Sep 1999 22:11:32 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA09562 for linux-audio-dev-list; Fri, 3 Sep 1999 21:34:12 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA09559 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 3 Sep 1999 21:34:09 -0400
Received: from localhost.localdomain (dialup88-3-13.swipnet.se [130.244.88.45]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id DAA27633; 
          Sat, 4 Sep 1999 03:30:32 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Benno Senoner <sbenno@gardena.net>, Julius Smith <jos@w3k.org>
Subject: Re: [linux-audio-dev] Re: Bandlimited interpolation suitable for realtime audio
Date: Sat, 4 Sep 1999 02:19:56 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca, pbd@op.net,
        jos@ccrma.Stanford.EDU
References: <99090403011300.00815@linuxhost.localdomain>
MIME-Version: 1.0
Message-Id: <99090403360103.00437@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id DAA27633
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id WAA29964
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 22592f37e8753d9676626759626c4c25

On Sat, 04 Sep 1999, Benno Senoner wrote:
[...]
> By oversampling by a factor of 2
[...]
> If this is the only approach for oversampling, then the drawback is it's use
of > in a comple audio engine like audiality,
> since you have to run the entire signal-path at twice the samplingrate,
> until you output the results to the DAC.
> This is very expensive in terms of CPU usage.

Indeed. Think about FIR filters and the like. Not only does the sample rate
double; many algorithms also have to deal with doubled window sizes at that
rate... (Unless, of course, they cheat and take for granted that the supersonic
noise won't get out of the system in any form. Wouldn't be a nice burden to put
on plug-in developers, though.)

> Another approach could be to put a 20kHz lowpassfilter after each
> polinomial interpolator/oversampler,
> but that means if you play 30 voices on your soft-sampler you have to
> activate 20 low-passfilters which means additional CPU consumption. 

Low pass filters at fixed frequencies related to the sample rate don't have to
be very CPU consuming, especially not compared to most alternative solutions.
(That is, getting a nice signal directly from the rate conversion.)

OTOH, that would have to be a very steep filter not to cut the treble of the
resampled signals... Of course, such and "analog style" artifact would be _a
lot_ better than any the usual kinds of distortion in digital systems.

[...]
> I want an interpolation method that has good quality , even when you play
> the data at let's say -2 octaves, but does not use too much multiply-adds.

I'd like to know how the EMU8000 chip (AWE) does it... It sounds very good for
being something you can find on low end sound cards, so the obvious question is
"How do they do it without lots of expensive DSP power?"

Ok, the chip *does* have some restrictions, but as long as you stay within
reasonable sample rates, it sounds pretty clean. (Heck, pro synths have
audible artifacts! The EMU8000 + decent external DAC beats many of them
easily...)

> Using linear interpolating condributes to "edges" into the signal , which means
> harmonic distortion.

Yep... It draws straight lines between the samles, which is not a very good
aproximation for data with high frequency components.

> I experimented a bit with the "natural cubic spline"  ( 3rd order) ,
> I tested this by sampling 2 periods (4*PI) of a pure sine ,
> using 20 points.
> for the first 17 samples the maximum error between interpolated signal
> and original sine is about -68dB which is quite good if you consider that
> there are only 10 points per 2PI period.
> The last 3 samples show higher errors , up to -35dB, but I think this is
> because the interpolator does not know how the sine wave continues.

This is a common problem. BTW, this is one of the limitations of that EMU chip;
it doesn't feed samples into the resampling algo through the "DMA", so it fails
to handle loops correctly. You have to copy the first two samples of the loop
to after the end of the loop to avoid clicks. Not nice if you had in mind
sliding the loops in real time, and bl**dy frustrating the patch editor
doesn't handle it automatically...

> It's interesting that the last sample is one step before the next zero cross,
> and if I choose 21 points (therefore including the last zero cross),
> the maximum error stays below the   -68dB mark even for the last samples.
> The algorithm takes about 12 multiplications per sample or so.
> 
> comments about this algorithm ?
> (There seems to be some software aroung which uses the spline approach
> to perform audio interpolation)

Don't know if they're using something like that, but E-mu claims to have
"8-point interpolation" in their newer samplers. Unfortunately, I'm afraid
asking them how they do it wouldn't work! ;-)

> > Another point is that if you're willing to spend 5-6 mulitiplications per
> > sample on interpolation, I don't believe polynomial interpolation is
> > superior to bandlimited interpolation at that complexity level.   To
> > compare them, we have to view polynomial interpolation in terms of its
> > frequency response as a "bandlimited interpolation filter".  (After all,
> > both methods simply implement time-varying linear filters on the original
> > samples, so on that level they are equivalent --- they only differ
> > fundamentally in the coefficients used.)
> 
> About the complexity level of bandlimited interpolation:
> 
> Using polinomial interpolation the number of multiplications per sample stays
> constant, regardless of pitch, we just have to traverse the wave table faster
> or slower.
> Using bandlimited interpolation , lowering the pitch by 2 octaves produces four
> times the CPU load of the playback at normal pitch.
> 
> The big advantage of bandlimited interpolation is that you can play the data
> at higher pitches without aliasing problems + higher pitches = no increased CPU
> load.
> correct me please if I'm wrong. 

What about crossfading or switching? (Is there a "safe" switch point, that
wouldn't result in a sudden change of the frequency response?) From what I have
managed to find out about synthesizers, most use various tricks to get good
quality across the entire resampling range. It seems that some do only
downsampling, while others do only upsampling. That's used in combination
with either some highly optimized +/- n octaves resampling algorithms, or just
plain preprocessed data.

(Again, that EMU does up to +2 octaves, and doesn't seem to have a low limit.
However, only around +1/-2 octaves can be used without undesired side effects,
but that depends a bit on the actual data.)

[...]
> > Ultimately, the question is how do you want to design the lowpass filter that
> > guards against aliasing.
> >  The bandlimited interpolation formulation allows you to address that issue
> > explicitly rather than just "getting what you get" with polynomial
> > interpolation. 
> 
> What kind of 20kHz lowpass filter would you recommend ?
> Butterworth / Bessel / Chebyshev ?  which order ? ( is 6th order to heavy ?)

20 kHz doesn't sound like a very good choice to me... There's a reason why we
use 44.1 or 48 kHz and not 40 kHz, and that's the fact that higher rates means
less steep filters without getting a drop within the audible range, or letting
the "problems" out through the filter...

Back in the Amiga days, I managed to cut away lots of distortion in a CPU based
music engine by simply running the resampler (no interpolation - no way to do
that even with my 25 MHz 68030!) at twice the output sample rate, and then
downsampling the mixed signal through a simple interpolation filter.

> Which factors are more important for sample-playback engines ?
> (like impulse response , step response etc.)

Percieved audio quality is important. The rest is just theory. In some cases,
this means h*ll, in other cases, it means "cheating" actually results in better
audio quality.

For example, the very simple filters I used in the old Win16 Audiality engine
were "simulated RC filters", which meant that they had the normal problems
simple analog RC filters have. They probably did far more weird stuff to the
signal than carefully designed FIR filters, but they showed no audible
"digital" side effects whatsoever. And a 6dB filter can be as little as one
subtraction, one multiplication (or shift) and one add, regardless of the
sample rate/cutoff frequency ratio...

> I jus did a quick math:
> 
> let's assume a spline interpolator + 6th order ( 36dB/oct)  Butterworth
> lowpass at 20kHz
> 12 multiplications for the interpolator and 9 for the lowpass filter =
> 21 multiplications.
> 
> Let's assume playback at pitch -2 octaves:
> nr.of multiplications / output-sample:
> 
> 104 for bandlimited  interpolation
> 21 for the cubic interpolation + lowpass filter.
> 
> correct ?
> 
> (David: your thoughts about quality vs. performance tradeoffs ?)

Well, as a system with obvious and unpleasant digital artifacts is more or less
usless for anything but entertainment systems and consumer products, we just
have to pay what it costs.

However, trying to achieve the Perfect Resampling Algorithm is just plain
pointless. First, it'll most likely use up so much CPU power that no one will
afford building a usable system. Second, there's a good chance our efforts of
getting a clinically perfect sound will only result in a harch, cold and dead
system... All systems affect the audio in one way or another, and the important
thing is to make sure the effect doesn't destroy the signals.

Extra harmonics are often regarded as a *positive* effect, but unfortunately,
most distortion we're likely to get in a digital system is of everything but
that kind... Noise is usually less noticable than aliasing distortion. An
unlinear frequency response is far more pleasant to the ears than audible
interference frequenices.

So, "If it sounds good, it IS good", but of course, keeping an eye on the
frequency response and phase diagrams may save us from some unpleasant
surprises. Some audio signals just have a way of making most systems sound like
@$@...

And of course, there's always the option of just using a different resampler
plug-in, if you don't like the standard one. Or use different ones for
different kinds of audio, if you're really picky. Try that with a dedicated
sampler... ;-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Sep  4 00:38:36 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA07680
	for <slinkp@ulster.net>; Fri, 3 Sep 1999 18:58:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA09339 for linux-audio-dev-list; Fri, 3 Sep 1999 18:22:37 -0400
Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA09336 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 3 Sep 1999 18:22:34 -0400
Received: (from uucp@localhost)
	by news-ma.rhein-neckar.de (8.8.8/8.8.8) with UUCP id AAA29124;
	Sat, 4 Sep 1999 00:19:01 +0200 (CEST)
	(envelope-from andreas@avix.rhein-neckar.de)
Received: from localhost (andreas@localhost [127.0.0.1])
	by avix.localnet (8.9.3/8.9.3) with ESMTP id DAA00984;
	Sat, 4 Sep 1999 03:22:10 +0200
Date: Sat, 4 Sep 1999 03:22:10 +0200 (MEST)
From: Andreas Voss <andreas@avix.rhein-neckar.de>
X-Sender: andreas@avix.localnet
To: David Slomin <dgslomin@CS.Princeton.EDU>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Timed Event Editor Framework
In-Reply-To: <Pine.GSO.4.10.9909012117120.2613-100000@ux02.CS.Princeton.EDU>
Message-ID: <Pine.LNX.4.10.9909040307550.340-100000@avix.localnet>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: be7b3a572a223161d7f636bffe48ab51

> In the merged list, there is one definite, user and API controlled order
> of events.  No two events are truly simultaneous, even if they have the 
> same timestamp.  This is advantageous for purposes like dropping markers
> (I'm a HUGE fan of using markers rather than selections for editing 
> except when you need discontinous selection).  It is perfectly valid to
> drop a marker between two events with the same timestamp.  How do you
> handle this when you use separate lists for separate tracks?

Lets assume there are two events a and b with the same time stamp. If you
want to include a into your selection but not b, you can insert the marker
inbetween a and b. But if you want to include b but not a, you would have
to swap a and b first. Now, if there is an event c which is played a
little after a and b, there would be no chance to include for example a
and c, but not b into the selection.

I think selecting events by marker events is some mixture of selecting a
range of events related to timestamp and selecting a time-independent
set of events. Both should be possible, i would like to process bars 1 to
10 for example, and I would also like to process event a and c but not b
in the above example. In this case the user could select the desired
events by clicking on them.

Andreas


From - Sat Sep  4 01:17:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA16461
	for <slinkp@ulster.net>; Sat, 4 Sep 1999 01:20:58 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA09815 for linux-audio-dev-list; Sat, 4 Sep 1999 00:47:29 -0400
Received: from bsx.ru (bsx.ru [194.67.110.28]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA09812 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 4 Sep 1999 00:47:23 -0400
Received: from localhost (2nb@localhost)
	by bsx.ru (8.8.6/8.8.6) with SMTP id IAA09614;
	Sat, 4 Sep 1999 08:45:57 +0400
Date: Sat, 4 Sep 1999 08:45:57 +0400 (MSD)
From: 2nb <2nb@bsx.ru>
To: David Olofson <audiality@swipnet.se>
cc: Guenter Geiger <geiger@epy.co.at>, est@hyperreal.org,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] plugin ideas based on Guenter's mix plugin
 API
In-Reply-To: <99082804574509.01621@localhost.localdomain>
Message-ID: <Pine.LNX.4.00.9909040831070.3775-100000@bsx.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 006092ad7cd275c8765bed5664fa6cf9


On Sat, 28 Aug 1999, David Olofson wrote:

>>  ops sounds cool, but .... well Open Plugin Specification sound rather
>>   .. not very inventive .. but probably what we need for some people 
>>  to accept the API.
>
>OMPIS... Open Multimedia Plug-In Specification. *hehe*
>
>No, seriously, should we try to give a hint as to what the main use of the
>standard is, or not? Open Plugin Specification is perhaps a bit too
>non-specific, but OpAPS, Open Audio Plug-in Specification probably doesn't
>cover all areas where it can be used... Kind of a marketing decision.

hello, i've been following the discussion from the beginning.
my background and current work are not very interesting since i don't plan
to contribute and/or propose anything useful at least for the momment. so
i'll skip any kind of intro.

but your OpAPS acronym set me thinging of a new one:
TOPAS
sounds nice
stands for "The Open Plugin Audio Spec" or gnu-like "TOPAS is Open Plugin
Audio Spec"
one bad thing, i remember of at least one graphics product named topas.

                                                  2nb.

From - Sat Sep  4 02:47:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id CAA21043
	for <slinkp@ulster.net>; Sat, 4 Sep 1999 02:53:48 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id CAA09940 for linux-audio-dev-list; Sat, 4 Sep 1999 02:21:27 -0400
Received: from m1.rconnect.com (m1.rconnect.com [209.163.30.3]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA09937 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 4 Sep 1999 02:21:25 -0400
Received: from rconnect.com ([209.163.11.96])
	by m1.rconnect.com (8.9.3/8.9.3) with ESMTP id BAA22292
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 4 Sep 1999 01:17:43 -0500 (CDT)
Message-ID: <37D0B8AF.EB25A041@rconnect.com>
Date: Sat, 04 Sep 1999 01:14:08 -0500
From: Andrew Harris <squid@rconnect.com>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] plugin ideas based on Guenter's mix pluginAPI
References: <Pine.LNX.4.00.9909040831070.3775-100000@bsx.ru>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: cac82fefc6065ee2c73625eeeae67ad9

Personally, I think it should be PHAT:  Plug-in Handling Audio Technology

OK, maybe that is a little dumb.

Andrew Harris
squid@rconnect.com

2nb wrote:

> On Sat, 28 Aug 1999, David Olofson wrote:
>
> >>  ops sounds cool, but .... well Open Plugin Specification sound rather
> >>   .. not very inventive .. but probably what we need for some people
> >>  to accept the API.
> >
> >OMPIS... Open Multimedia Plug-In Specification. *hehe*
> >
> >No, seriously, should we try to give a hint as to what the main use of the
> >standard is, or not? Open Plugin Specification is perhaps a bit too
> >non-specific, but OpAPS, Open Audio Plug-in Specification probably doesn't
> >cover all areas where it can be used... Kind of a marketing decision.
>
> hello, i've been following the discussion from the beginning.
> my background and current work are not very interesting since i don't plan
> to contribute and/or propose anything useful at least for the momment. so
> i'll skip any kind of intro.
>
> but your OpAPS acronym set me thinging of a new one:
> TOPAS
> sounds nice
> stands for "The Open Plugin Audio Spec" or gnu-like "TOPAS is Open Plugin
> Audio Spec"
> one bad thing, i remember of at least one graphics product named topas.
>
>                                                   2nb.

From - Sun Sep  5 22:16:03 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id FAA27637
	for <slinkp@ulster.net>; Sat, 4 Sep 1999 05:54:31 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA10281 for linux-audio-dev-list; Sat, 4 Sep 1999 05:13:53 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA10278 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 4 Sep 1999 05:13:50 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id FAA00246
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 4 Sep 1999 05:09:06 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id FAA12095; Sat, 4 Sep 1999 05:09:06 -0400 (EDT)
Date: Sat, 4 Sep 1999 05:09:04 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Timed Event Editor Framework
In-Reply-To: <Pine.LNX.4.10.9909040307550.340-100000@avix.localnet>
Message-ID: <Pine.GSO.4.10.9909040504100.11889-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 737fb7b1d8763aee00d4422c06ae85b7

On Sat, 4 Sep 1999, Andreas Voss wrote:

> I think selecting events by marker events is some mixture of selecting a
> range of events related to timestamp and selecting a time-independent
> set of events. Both should be possible, i would like to process bars 1 to
> 10 for example, and I would also like to process event a and c but not b
> in the above example. In this case the user could select the desired
> events by clicking on them.

You know, you're absolutely right.  I'd been keeping the discontiguous
selection mechanism separate in my mind, and I forgot that this case
was best handled by that.  Thanks.

I guess that eliminates the last barrier to having a separate event list
per track.  Now I have to decide how to deal with markers.  Should there
be two types of marker event, one which is track specific and one which
goes in the conductor (global) track?  I can think of cases where each
would be more appropriate.  I'm pretty sure that SMF only defines one type
of marker, and I don't remember whether or not it has a track number
associated with it.

Div.

From - Sun Sep  5 22:16:16 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA32572
	for <slinkp@ulster.net>; Sat, 4 Sep 1999 13:30:01 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA10815 for linux-audio-dev-list; Sat, 4 Sep 1999 12:51:53 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id MAA10812 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 4 Sep 1999 12:51:50 -0400
From: est@hyperreal.org
Received: (qmail 26385 invoked by uid 162); 4 Sep 1999 16:48:23 -0000
Message-ID: <19990904164823.26384.qmail@hyperreal.org>
Subject: [linux-audio-dev] markers for Div's sequencer
In-Reply-To: <Pine.GSO.4.10.9909040504100.11889-100000@ux02.CS.Princeton.EDU>
 from David Slomin at "Sep 4, 1999 05:09:04 am"
To: David Slomin <dgslomin@CS.Princeton.EDU>
Date: Sat, 4 Sep 1999 09:48:23 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: fea6bf90d7fe467497f5da51d14dc9c9

David Slomin discourseth:
> 
> I'm pretty sure that SMF only defines one type
> of marker, and I don't remember whether or not it has a track number
> associated with it.

It doesn't..but it's arbitrary text, so you could encode something.
However, they `normally' appear in only one track..so maybe that's an
point for the single event list?  OTOH, a `sequencer-specific
meta-event' might be more appropriate for your markers.

In any case, I sure hope you're able to get to coding soon.  We need
sequencers! :)

Eric

From - Sun Sep  5 22:16:18 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA04327
	for <slinkp@ulster.net>; Sat, 4 Sep 1999 20:22:57 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA11223 for linux-audio-dev-list; Sat, 4 Sep 1999 19:37:58 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA11220 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 4 Sep 1999 19:37:55 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id TAA17776
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 4 Sep 1999 19:32:57 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id TAA24932; Sat, 4 Sep 1999 19:32:55 -0400 (EDT)
Date: Sat, 4 Sep 1999 19:32:53 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: markers for Div's sequencer
In-Reply-To: <19990904164823.26384.qmail@hyperreal.org>
Message-ID: <Pine.GSO.4.10.9909041925460.24713-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: e5fb7b1ae571111ba00a0f62926a6fe5

On Sat, 4 Sep 1999 est@hyperreal.org wrote:

> David Slomin discourseth:
> > 
> > I'm pretty sure that SMF only defines one type
> > of marker, and I don't remember whether or not it has a track number
> > associated with it.
> 
> It doesn't..but it's arbitrary text, so you could encode something.
> However, they `normally' appear in only one track..so maybe that's an
> point for the single event list?  OTOH, a `sequencer-specific
> meta-event' might be more appropriate for your markers.

That makes sense... the SMF marker event is intended to be used for
rehearsal numbers and such, so it would probably be an abuse to coerce it
into use as a bookmark.  Actually, as a SysEx, I guess I can create
whatever I want, right?  I suppose I should apply to the MMA for a vendor
ID <shudder>.
 
> In any case, I sure hope you're able to get to coding soon.  We need
> sequencers! :)

Well, it's a long weekend; I'll see if I can get a rudimentary event list
viewer (display only, no editing or file I/O) tonight.  It would be more
useful to do the SMF I/O first, but I'd like to be able to see what I'm
doing (all backend and no GUI makes Jack a dull boy).  Optimally I'd hope
to get SMF I/O done by the end of the weekend, but no promises... there's
a party on Monday...

Cheers,
Div.

From - Sun Sep  5 22:16:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA11109
	for <slinkp@ulster.net>; Sat, 4 Sep 1999 21:35:30 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA11313 for linux-audio-dev-list; Sat, 4 Sep 1999 21:01:51 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id VAA11310 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 4 Sep 1999 21:01:45 -0400
From: est@hyperreal.org
Received: (qmail 25320 invoked by uid 162); 5 Sep 1999 00:58:20 -0000
Message-ID: <19990905005820.25319.qmail@hyperreal.org>
Subject: [linux-audio-dev] linux csound real-tim input
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Sat, 4 Sep 1999 17:58:20 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8003
X-Mozilla-Status2: 00000000
X-UIDL: b8dec9ea2bac4cc80a00806803537f9d

I've been having fun with the higher-level midi input operators, but
I'm stumped by midiin.  Does anyone have a nice example of using it?
Could the stuff in midirecv-linux.c that outputs "midi channel 1 using
instr 1" be clobbering its behavior?

Also, I haven't been able to get -L to work at all.  Trying it with
`cat >&3| csound -odac -L /dev/fd/3 foo.orc' or on a fifo I get:

can't reopen (null)
stdmode = 00000000 Linefd = 4

Eric

From - Sun Sep  5 22:16:22 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA13093
	for <slinkp@ulster.net>; Sat, 4 Sep 1999 21:56:53 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA11358 for linux-audio-dev-list; Sat, 4 Sep 1999 21:20:10 -0400
Received: from proxy4.ba.best.com (proxy4.ba.best.com [206.184.139.15]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA11355 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 4 Sep 1999 21:20:07 -0400
Received: from julius (dynamic28.pm07.mv.best.com [209.24.241.156])
	by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with SMTP id SAA17678;
	Sat, 4 Sep 1999 18:15:04 -0700 (PDT)
Message-Id: <199909050115.SAA17678@proxy4.ba.best.com>
X-Sender: julius@shell16.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Sat, 04 Sep 1999 18:11:16 -0700
To: Benno Senoner <sbenno@gardena.net>
From: Julius Smith <jos@w3k.org>
Subject: [linux-audio-dev] Re: Bandlimited interpolation suitable for realtime audio
Cc: Benno Senoner <sbenno@em.gardena.net>, sbenno@gardena.net,
        linux-audio-dev@ginette.musique.umontreal.ca, audiality@swipnet.se,
        pbd@op.net, jos@ccrma.Stanford.EDU
In-Reply-To: <99090403011300.00815@linuxhost.localdomain>
References: <199909012326.QAA23083@proxy4.ba.best.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 83b10363e5328c5c030ab76a4594d553

Hi again,

>> >... my concern is that if we oversample by 2,
>> >since we allow to sample-playback modules to be routed through various
>> >modules like FX-processors , filters etc, we have to run the entire engine
>> >at twice the samplefrequency, and this means twice the CPU load,
>> >Is there no other way to allow flexible voicerouting AND avoiding
>> >to run the entire engine at twice the samplefrequency ?
>> 
>> The oversampling need only affect the wavetables themselves.
>>  It just means doubling the memory over what you would have had.  Consider,
>> for example, how it would work if you somehow encoded the wavetables as exact
>> continuous functions.  In principle, they would be oversampled by infinity. 
>> However, the playback oscillator just asks for them at intervals of the
>> current sampling period (which can change to any value at any time, without
>> regard for the "phase alignment" of the sampling points).
>
>Ok, but we are speaking of sample playback engines,
>that means I have arbitrary  data (a WAV file) sampled that 44.1kHz , and want
>to play the data at pitches up to 1 octave higher but without aliasing effects.

In that case you could upsample once when loading the .wav file
using a high-quality converter.  This would increase the load time, of course,
which could be a problem if you want to support dynamic loading of wave files
in response to MIDI "program select" during a musical performance.

>By oversampling by a factor of 2 , we reduce the stepsize to 0.75 with no
>aliasing noise, but we have to play the data back at 88.2kHz,
>or lowpassfilter the result at 20kHz, and then extract only the even (or odd)
>samples and send the result to our 44.1kHz DAC.
>Correct me please if I miss something.

I'm not sure I understand what you're saying, but when you are doing interpolation, you
never have to play back at any rate other than the final one you want.
That's what interpolation is for.  The quality of the interpolation is 
an independent issue controlled by wavetable samping density and interpolation-filter
quality (number of multiply-adds and coefficients used).

>Using linear interpolating condributes to "edges" into the signal , which means
>harmonic distortion.

Not if your table is oversampled enough.  With a sufficiently oversampled wavetable,
the audible distortion is ZERO with linear interpolation.  

>About the complexity level of bandlimited interpolation:
>
>Using polinomial interpolation the number of multiplications per sample stays
>constant, regardless of pitch, we just have to traverse the wave table faster
>or slower.
>Using bandlimited interpolation , lowering the pitch by 2 octaves produces four
>times the CPU load of the playback at normal pitch.

The CPU load should be constant when going down in pitch.  In that case, the
waveform is interpolated to many samples per sample, and
the filter length stays fixed.

>The big advantage of bandlimited interpolation is that you can play the data
>at higher pitches without aliasing problems + higher pitches = no increased CPU
>load.
>correct me please if I'm wrong. 

Going up in pitch, the wavetable has to be decimated.  That requires anti-aliasing
filtering, and the farther up you shift, the more filtering is required.  This is a basic
fact no matter what interpolation method you use.

If you want, you can also fix the filter length
used in bandlimited interpolation, but this will give a poorer result because
the filter really should get longer to carve away more and more of
the original signal band.

>What kind of 20kHz lowpass filter would you recommend ?
>Butterworth / Bessel / Chebyshev ?  which order ? ( is 6th order to heavy ?)

At that high a frequency, I'd use elliptic.  (Chebyshev is next best.)
In floating-point, 6th order is not too high from a coefficient-precision point
of view, if that's what you're asking.

>Which factors are more important for sample-playback engines ?
>(like impulse response , step response etc.)
>
>I jus did a quick math:
>
>let's assume a spline interpolator + 6th order ( 36dB/oct)  Butterworth
>lowpass at 20kHz
>12 multiplications for the interpolator and 9 for the lowpass filter =
>21 multiplications.
>
>Let's assume playback at pitch -2 octaves:
>nr.of multiplications / output-sample:
>
>104 for bandlimited  interpolation
>21 for the cubic interpolation + lowpass filter.
>
>correct ?

The correct comparison would be

>21 for bandlimited  interpolation
>21 for the cubic interpolation + lowpass filter.

and then listen to how they sound.
In other words, either method can be implemented at pretty much
any complexity level, so just make them be the same, run some listening tests,
and choose the best one.

Julius

From - Sun Sep  5 22:16:24 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA14904
	for <slinkp@ulster.net>; Sat, 4 Sep 1999 22:16:04 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA11378 for linux-audio-dev-list; Sat, 4 Sep 1999 21:35:42 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id VAA11375 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 4 Sep 1999 21:35:39 -0400
From: est@hyperreal.org
Received: (qmail 8694 invoked by uid 162); 5 Sep 1999 01:32:15 -0000
Message-ID: <19990905013215.8693.qmail@hyperreal.org>
Subject: [linux-audio-dev] using csound as a sampling engine
In-Reply-To: <37D160E0.92302142@bright.net> from Dave Phillips at "Sep 4, 1999
 02:11:44 pm"
To: Dave Phillips <dlphilp@bright.net>
Date: Sat, 4 Sep 1999 18:32:15 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: f0b36098535390b039f9d7a1b57454a5

Dave Phillips discourseth:
>  
> > Has anyone done a general
> > midi-controlled sampler for csound?  If not, I may have to.  One with
> > per-channel controls (e.g., pan) would be especially delish. :)
> 
> That would be cool, maybe you should throw that at the LAD list
> sometime. Tell me more about how you'd build that "sampler for
> csound"...

There's a start at http://www.hyperreal.org/~est/csound/s1/.  It's a
front end to csound that allows you to conveniently map files to midi
keys.  I threw in some sound files and a script to spew some midi so
you can hear a beat from it immediately. :)

Eric

From - Sun Sep  5 22:16:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA05773
	for <slinkp@ulster.net>; Sun, 5 Sep 1999 13:05:17 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA12152 for linux-audio-dev-list; Sun, 5 Sep 1999 12:28:04 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA12149 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 5 Sep 1999 12:28:02 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id MAA09513
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 5 Sep 1999 12:23:28 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id MAA09630; Sun, 5 Sep 1999 12:23:27 -0400 (EDT)
Date: Sun, 5 Sep 1999 12:23:18 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Bandlimited interpolation suitable for
 realtime audio
In-Reply-To: <199909050115.SAA17678@proxy4.ba.best.com>
Message-ID: <Pine.GSO.4.10.9909051218400.9534-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 04dbc9cf4d9aa5fa905055ad5e779f66

On Sat, 4 Sep 1999, Julius Smith wrote:

> In that case you could upsample once when loading the .wav file
> using a high-quality converter.  This would increase the load time, of course,
> which could be a problem if you want to support dynamic loading of wave files
> in response to MIDI "program select" during a musical performance.

Please forgive my ignorance, but is there really such a thing as 
upsampling without introducing distortion?  I mean, I thought the rule
was you can always filter-out data, but you can't put it back in from
nowhere without doing some harm.  I can see how interpolation (linear or
higher order) would help, but it still wouldn't be the "real" waveform,
right?  For instance, could it successfully counteract Nyquist foldover?

Just curious,
Div.

From - Sun Sep  5 22:16:40 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA25119
	for <slinkp@ulster.net>; Sun, 5 Sep 1999 16:48:22 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA12331 for linux-audio-dev-list; Sun, 5 Sep 1999 16:11:14 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id QAA12328 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 5 Sep 1999 16:11:11 -0400
From: est@hyperreal.org
Received: (qmail 26395 invoked by uid 162); 5 Sep 1999 20:07:45 -0000
Message-ID: <19990905200745.26394.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] linux csound real-time input
In-Reply-To: <19990905005820.25319.qmail@hyperreal.org> from "est@hyperreal.org"
 at "Sep 4, 1999 05:58:20 pm"
To: csound-unix-dev@ilogic.com.au,
        linux-audio-dev@ginette.musique.umontreal.ca
Date: Sun, 5 Sep 1999 13:07:45 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7cdc20a6729a5a9f16e5bdbb36f739c1

est@hyperreal.org discourseth:
> 
> Also, I haven't been able to get -L to work at all.  Trying it with
> `cat >&3| csound -odac -L /dev/fd/3 foo.orc' or on a fifo I get:
> 
> can't reopen (null)

OK, the following patch seems to fix *this* problem:

--- musmon.c~   Thu Aug 12 00:59:58 1999
+++ musmon.c    Sun Sep  5 15:56:06 1999
@@ -221,7 +221,7 @@
         if (O.Beatmode)                        /* if performing from beats */
             settempo((FLOAT)O.cmdTempo);       /*   set the initial tempo  */

-        /*if (!O.RTevents)*/ {               /* *************** */
+        if (!O.Linein) {               /* *************** */
           if (!(scfp = fopen(O.playscore, "r")))
             dies(Str(X_649,"cannot reopen %s"), O.playscore);
         }

Eric

From - Sun Sep  5 22:16:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA02884
	for <slinkp@ulster.net>; Sun, 5 Sep 1999 18:44:14 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA12444 for linux-audio-dev-list; Sun, 5 Sep 1999 18:01:27 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id SAA12441 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 5 Sep 1999 18:01:17 -0400
From: est@hyperreal.org
Received: (qmail 9096 invoked by uid 162); 5 Sep 1999 21:57:51 -0000
Message-ID: <19990905215751.9095.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] using csound as a sampling engine
In-Reply-To: <19990905013215.8693.qmail@hyperreal.org> from "est@hyperreal.org"
 at "Sep 4, 1999 06:32:15 pm"
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Sun, 5 Sep 1999 14:57:51 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 36c7816c8dc62a3b54e458e4e769cace

est@hyperreal.org discourseth:
> Dave Phillips discourseth:
> >  
> > > Has anyone done a general
> > > midi-controlled sampler for csound?  If not, I may have to.  One with
> > > per-channel controls (e.g., pan) would be especially delish. :)
> > 
> > That would be cool, maybe you should throw that at the LAD list
> > sometime. Tell me more about how you'd build that "sampler for
> > csound"...
> 
> There's a start at http://www.hyperreal.org/~est/csound/s1/.

Now that I've got csound's -L option working, I'm taking an quite
different approach based on it.  It will allow many parameters at note
startup, more than 16 channels with parameters for each, and other
goodies. :)

Eric

From - Sun Sep  5 22:17:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA04747
	for <slinkp@ulster.net>; Sun, 5 Sep 1999 19:05:05 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA12471 for linux-audio-dev-list; Sun, 5 Sep 1999 18:21:00 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id SAA12468 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 5 Sep 1999 18:20:58 -0400
From: est@hyperreal.org
Received: (qmail 20462 invoked by uid 162); 5 Sep 1999 22:17:31 -0000
Message-ID: <19990905221731.20461.qmail@hyperreal.org>
Subject: [linux-audio-dev] Athlon/3dnow! dsp benchmark results
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Sun, 5 Sep 1999 15:17:31 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 8b9f5ccb374825d17f17f182bbc691a4

I coded a biquadratic filter in C, bummed C (`caching' values in
locals csound-style), and 3dnow.  I tested how long it took (in
microseconds) to process a buffer of 128 mono float samples 100 times.

I also wrote another routine to mix two channels into one with scale
factors for each input channel.  I ran it on the same size data as the
biquad benchmark.

On my amd k6-2/350 using gcc-2.95.1, I got the following typical results:

                        biquad 3dnow: 382
                          biquad gcc: 2004
                   biquad bummed gcc: 1493
                           mix 3dnow: 105
                             mix gcc: 659

Dieter Nuetzel was kind enough to run the same tests on his Athlon/500
system with pgcc-2.91.  The results he got were:

                        biquad 3dnow: 573
                          biquad gcc: 679
                   biquad bummed gcc: 340
       biquad gcc (-O6 -mpentiumpro): 378
biquad bummed gcc (-O6 -mpentiumpro): 353
                           mix 3dnow: 64
                             mix gcc: 136
          mix gcc (-O6 -mpentiumpro): 99

As you can see, biquad/3dnow was actually slower on his system!  mix
allowed 3dnow to maintain a (diminished) lead on the Athlon.  It's
more inherently SIMD.  In the case of biquad I think 3dnow beat gcc on
the k6-2 because the k6-2 fp architecture is just way behind 3dnow.
In the Athlon it's leap-frogged ahead.  Apparently the 3dnow
instructions have higher latency on the Athlon.  I have no idea
whether AMD plans to fix this.

Lastly, the Athlon is fast. :)

Eric

From - Sun Sep  5 22:55:54 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA29074
	for <slinkp@ulster.net>; Sun, 5 Sep 1999 23:03:22 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA12695 for linux-audio-dev-list; Sun, 5 Sep 1999 22:22:35 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA12692 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 5 Sep 1999 22:22:33 -0400
Received: from ulster.net (annex3-port44.ulster.net [208.133.194.44])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id WAA26407;
	Sun, 5 Sep 1999 22:34:57 -0400
Message-ID: <37D32635.44116E3D@ulster.net>
Date: Sun, 05 Sep 1999 22:25:57 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: est@hyperreal.org
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] linux csound real-tim input
References: <19990905005820.25319.qmail@hyperreal.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e38f28c36dae3ed59523c18d1836e3de

est@hyperreal.org wrote:
 
> Also, I haven't been able to get -L to work at all.  Trying it with
> `cat >&3| csound -odac -L /dev/fd/3 foo.orc' or on a fifo I get:
> 
> can't reopen (null)
> stdmode = 00000000 Linefd = 4

I don't really get what you're trying to accomplish with this command
line, but -L  works for me like this (unofficial linux csound v.
v3.53.0.1b):

mkfifo FOO
csound -d -m0 -odevaudio -L ./FOO orchestra.orc dummy.sco

 
--PW

From - Mon Sep  6 00:03:44 1999
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA02243
	for <slinkp@ulster.net>; Mon, 6 Sep 1999 00:05:47 -0400
From: est@hyperreal.org
Received: (qmail 20361 invoked by uid 162); 6 Sep 1999 03:49:21 -0000
Message-ID: <19990906034921.20360.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] linux csound real-tim input
In-Reply-To: <37D32635.44116E3D@ulster.net> from Paul Winkler at "Sep 5, 1999
 10:25:57 pm"
To: Paul Winkler <slinkp@ulster.net>
Date: Sun, 5 Sep 1999 20:49:21 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 68157b40448248c4aaae215d35906c93

Paul Winkler discourseth:
> est@hyperreal.org wrote:
>  
> > Also, I haven't been able to get -L to work at all.  Trying it with
> > `cat >&3| csound -odac -L /dev/fd/3 foo.orc' or on a fifo I get:
> > 
> > can't reopen (null)
> > stdmode = 00000000 Linefd = 4
> 
> I don't really get what you're trying to accomplish with this command
> line, 

Wow..yeah, that was a pretty obtuse example.

> but -L  works for me like this (unofficial linux csound v.
> v3.53.0.1b):
> 
> mkfifo FOO
> csound -d -m0 -odevaudio -L ./FOO orchestra.orc dummy.sco

..and it just doesn't work in unpatched unofficial-csound-3.57.0.1d-linux.

Anyhow, thanks for the reply. :)

Eric

From - Tue Sep  7 01:18:11 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id CAA10491
	for <slinkp@ulster.net>; Mon, 6 Sep 1999 02:12:12 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id BAA12922 for linux-audio-dev-list; Mon, 6 Sep 1999 01:33:49 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA12919 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 6 Sep 1999 01:33:47 -0400
Received: from ulster.net (annex3-port44.ulster.net [208.133.194.44])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id BAA09164;
	Mon, 6 Sep 1999 01:46:35 -0400
Message-ID: <37D35320.C23D2244@ulster.net>
Date: Mon, 06 Sep 1999 01:37:36 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: est@hyperreal.org
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] A Python loop sequencer, was re: using csound as a 
 sampling engine
References: <19990905215751.9095.qmail@hyperreal.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c150f5793e487a07f373e7786466e50b

est@hyperreal.org wrote:
> Now that I've got csound's -L option working, I'm taking an quite
> different approach based on it.  It will allow many parameters at note
> startup, more than 16 channels with parameters for each, and other
> goodies. :)
> 
> Eric


Eric, I just played with s1 and was impressed by several things:
1) it works nicely.
2) it's in python (I was wondering if anyone on the list used python!).
3) it's in very few lines of code, as a result of (2).

Your last statement above about doing it with -L input instead is very
interesting to me because ... well, this seems like a good opportunity
to go off about my current mental project. :)

I was thinking about building a vaguely 303-ish sequencer that, while
not pretending to be a general-purpose sequencer, does a LOT more than a
303-clone. Sort of like a graphical tracker with unlimited parameters.
I was thinking of writing it in python with a Tkinter interface. And
most relevant to your post, I was thinking of ignoring midi entirely and
using Csound as the synthesis engine, via stdin or a pipe.

So, comments from the list about the following rant would be most
welcome. This is my notes to myself about the project, so some things
may not make any sense. :)


THE HYPOTHETICAL PYTHON/TKINTER SEQUENCER THINGIE
-------------------------------------------------

possible name: NATOTS (not another three-oh-three sequencer)
               NYATS (not yet another three-oh-three sequencer)
               or something pretentious and "kewl"
                Hmm, those are terrible names.


General Idea:
-------------

Compositional tool that controls Csound in realtime.
Based on a sort of 303 / drum machine paradigm.

Inspired by 303Seq (a dumb but fun Windows sequencer) and all the
things I wish it did, and Cecilia (a Tcl/Tk interface to Csound) and
some things I wish _it_ did.


THE BIG QUESTION
----------------

Need to do some feasibility testing to see if this _can_ work
realtime. How accurate/reliable is application-generated timing sent
to csound -L <devicename>?

So I need to at least construct an event-generating script that really
works the pipe... and does so in a way that I can verify (in)accuracy
of timing. Try it with both stdin and FIFOs -- does that make a
difference?

Previous experiments with csound events from stdin are not especially
encouraging: more than about 10 simultaneous events were audibly not
simultaneous.  This is, at heart, a drum machine -- if simultaneous
hits are smeared, it'll sound awful. This may be an inherent problem
with mkfifo and stdin... Is that stuff tweakable?
But those experiments were done by flushing the buffer after each
line. If I want to send 50 simultaneous events, maybe they should fill
the buffer and _then_ flush it before going to the next event? If so, my
engine would need to efficiently know when it's done with "current"
events.

And another thing... how many simultaneous events am I really going to
have in practice?

      Things to try:
      --Add progressively more simultaneous events
      --Try sending events with non-zero start times WHILE sending
      streams of zero-start-time-events, e.g.:
              at 1:00:00 send "i1 0\n i1 1 \n i1 2 \n i1 3"
              at 1:00:01 send "i2 0" (should synchronize with i1 1)
              at 1:00:02 send "i2 0" (should synchronize with i1 2)
              at 1:00:03 send "i2 0" (should synchronize with i1 3)
        Issues: does the above start in sync? Can it be made to do so
        with compensatory delays? Does it drift out of sync (can't do
much
        about that)? If the latter, that would rule out sending big
        blocks of events with different start times..

      A big question is whether a python script is even capable of
      REALLY accurately timing its output. The built-in time and sched
      modules are probably what I'll end up using. Try them! How fast
are they?
      Do some experiments. Can't find anything on dejanews about this.
      For my purposes, timing resolution down to 1 msec is probably
      plenty. I bet 10 msec would even be useable for a lot of stuff
      (though probably ultimately frustrating).

This all probably depends on the speed of getting stuff into and out of
the
FIFO or pipe... 

If this proves to be unworkable, is there any other (faster) way to get
realtime events to Csound? Some sort of IPC? I don't think so.
Somebody was working on reading k-rate values in realtime from X11
scrollbars, but I don't know if they ever finished it, or if it could
be used for "i" events...

Or if Python is the source of timing problems, could I implement the
core event-sending mechanism in C? I don't want to have to do
this... In fact, I'm NOT going to do that. If the feasibility test
fails, the project will probably die. let's hope it works.


WISH LIST:
----------

     --"Panic button" -- kills Csound.

     --Editable Csound command to toggle displays, message level,
       output buffer size, etc.

     --Unlimited parallel tracks in _each pattern_.

     --"Continuous controller" line graphs can be created and assigned
     to any parameter

     --303Seq-style rows of scrollbars can be used as an alternative to
       the line graphs.

     --Can convert (by interpolation or down-sampling) back and
       forth between line graphs and scrollbar rows     

     --Events are all Csound "i" events, so they can really be
     anything; a track could be used just for csound global (or ZAK)
     parameter control

     --While I'm at it, maybe there's a more useful & general way to
     organize stuff:
     A "Pattern" (a period of time) is divided into "tracks" (a
     series of parameter values in time). So the "Notes" parameter
     would be the same as any other parameter -- a list of "at" values
     for p2. Does this make sense? Seen as a line graph, the "at" or
     "notes" graph would just be a collection of zeroes and ones --
     "yes, a note starts here" or "no, no note starts here".
     But it seems like that's a waste of a parameter; zero should
     always mean no note, but a non-zero value should be assignable to
     anything you want, right? (Most often, initial volume or some
     other "intensity" parameter.)

     --Would be nice if I could display more than one parameter's graph
at
      a time.

     --Unlimited user-definable parameters per pattern/track.

     --Parameters may be "linked" and modified: e.g.volume(track(1),
     pattern(B)) =  (1 / pitch(track2, pattern B))^2 * 100
     ... though I'm sure I can come up with a better way to say that.
     The graph for the link should show the currently evaluated values
     and somehow indicate very obviously that it's a link, what it's a
link to,
     and any modifications. Linked graphs are not directly editable
     unless they are first frozen (see below).
     QUESTION: Can this and all continuous-controller type stuff be
     better implemented within a Csound orc?
     Certainly it would be faster. Maybe I should think about having
     my app write orcs as well as scores! But then it couldn't be
     modified during runtime, which would be a bummer. And it would be
     hard to get / edit displays. And it would make it harder to have 
     the orc be totally user-designable.
     I should take another look at Cecilia and see if I can figure out
     how they create, edit, and send their graphs... probably just as
     ftables... hmmm: is there a way I could use ftables to do 
     everything I want?
 
     --Linked parameters may be "frozen", i.e. the currently evaluated
     values are written to a line graph and saved. 

     --Copying patterns is just a function or method that implements a
      special case of the previous two features:
      freeze(all_parameters(track(all), pattern(A)) = all_parameters
      (track(all), pattern(B)))
      Or something like that. A more OO syntax might be better. What
      I'm saying is: "All parameters for all tracks of pattern B are
      linked to all parameters for all tracks of pattern A. Now freeze
      pattern B."

     --Some sort of "song-editor": possibly just a text representation
     of named patterns. There's still a lot you can do with
     this. E.g.:
           "a a a b a c a2 tag chorus breakdown ending"
           or
           "intro (a * 3) b end"
           or
           "(a UPTO 8) * 2 a" 
             ... that will play a up to beat 8 twice, then the full
             "a"
           or
           "((a * 3) WHILE (b * 2)) c"
           ...that will play a 3 times, and b 2 times
           simultaneously; c will play whenever a and b are both done.  
           This kind of parallelism gets clunky in a text
           representation...
           Better would be a visual meta-piano-roll style, with
           "tracks" for placing patterns.

     --There really needs to be a way to save interactive stuff, in
       the same way that 303Seq writes a midi file whenever you start
       it. That's a really cool feature. Is there a way that the
       csound events can be simultaneously written to a file with
       meaningful timestamps?
       Actually this would be a nice feature in Csound itself: a flag
       to write all received events into a file with the times
       replaced by the times they were received.
	In any case, I really need to be able to play with it in 
	realtime and capture the results for later editing / rendering.

     --Envelopes: I will probably start with ADSR and simple gates
       because it's easy and handles 99% of what I want to do.
       Anything more complicated can be assigned to a user-defined 
       linseg. Hmm: How to control ADSR? Would that be four separate
        parameter graphs??

     --Held notes: I want a way to optionally say "Do this until I
       tell you to
       stop" -- that is, follow the "noteoff" paradigm rather than the
       "dur" paradigm. Sometimes this just makes more sense.  
       Probably held notes would be a special note type implemented by
       the sequencer, and Csound wouldn't have to know about it -- dur
       would be calculated by the sequencer. Problem is, that would
       mean changing noteoff after the note starts would have no effect.
       Hmmm.

     --"Global" tracks: Need a way to control various parameters
        independent of patterns. E.g. fades, some effects parameters,
         whatever. How to best implement this?

SUGAR (features I don't care so much about, yet):
-----

    --It should be possible to run an arbitrary csound score at the
      same time as the realtime input from my sequencer. I'm not sure
      what I would use this for, but it might be useful for something,
      and probably not hard to implement.

    --The piano-roll-style "song editor"

    --It would be cool if, possibly in the song editor, you could
      place an arbitrary .wav file at an arbitrary time, so you could
      pre-render complicated stuff and keep working from there. (Much
      like Tkscore.)
      This would probably be implemented by always having a "diskin"
      instrument in the orc...

    --That "swing" scrollbar in 303Seq is kind of a cool
       feature. Consider adding something similar.

    --I should probably think about making the events generic so they
    can be mapped to MIDI or whatever instead of csound. That would
make     it a lot easier
    to, for instance, collaborate with James.

    --"Randomize" button for current parameter; should operate on only
      selected part of the window. For that matter, there could be
      lots of interesting parameter-generate/edit tools like that.

    --A button to pop up your favorite text editor with the current
      orc for modifications.


TKINTER QUESTIONS AND RESOURCES
-------------------------------

        --I want to be able to build Cecilia-style graphs (at the very
          least, simple click-and-drag line segments). Freehand line
          drawing would be very nice too.
          BLT has a graph element... maybe it could be used.

        --Beat indicators:
          This is not so important.
          But it would be nice if we could see where we are. At the
          very least, like a tracker, show the current pattern name
somewhere.
          Aside from the difficulty of synchronizing anything to audio
          output (I don't want it to be as useless as 303seq...), how do
I display
          this?  I think a light that blinks green at start of a new
          phrase, and another that blinks at a user-settable multiple
          of ticks (default 4). Look for a widget set that implements
          this.  I think there's a blinker in foztools:
          http://www.python.org/ftp/python/contrib/Graphics/Tkinter/





-- 

----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Tue Sep  7 01:18:23 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA23852
	for <slinkp@ulster.net>; Mon, 6 Sep 1999 07:36:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA13375 for linux-audio-dev-list; Mon, 6 Sep 1999 06:39:36 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA13372 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 6 Sep 1999 06:39:31 -0400
Received: from linuxhost.localdomain (IDENT:root@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id MAA02185;
	Mon, 6 Sep 1999 12:35:57 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id OAA00951;
	Mon, 6 Sep 1999 14:36:38 +0200
From: Benno Senoner <sbenno@gardena.net>
To: est@hyperreal.org, linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Athlon/3dnow! dsp benchmark results
Date: Mon, 6 Sep 1999 14:21:56 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <19990905221731.20461.qmail@hyperreal.org>
MIME-Version: 1.0
Message-Id: <99090614363801.00704@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 6a5cd72cdebbf4b57837dd8d75286ea3

Hi folks,
I can't wait go get such a beast like the Athlon.
:-)
Eric: are you sure that the biquad filter is coded in an optimal way.
Maybe you have to reorder things ?
I can't believe that 3Dnow is slower than optimized C on the Athlon.

But it's nice to see that well optimized C code runs only 30% slower than
3dnow code.
:-)

regards,
Benno.



On Mon, 06 Sep 1999, est@hyperreal.org wrote:
> I coded a biquadratic filter in C, bummed C (`caching' values in
> locals csound-style), and 3dnow.  I tested how long it took (in
> microseconds) to process a buffer of 128 mono float samples 100 times.
> 
> I also wrote another routine to mix two channels into one with scale
> factors for each input channel.  I ran it on the same size data as the
> biquad benchmark.
> 
> On my amd k6-2/350 using gcc-2.95.1, I got the following typical results:
> 
>                         biquad 3dnow: 382
>                           biquad gcc: 2004
>                    biquad bummed gcc: 1493
>                            mix 3dnow: 105
>                              mix gcc: 659
> 
> Dieter Nuetzel was kind enough to run the same tests on his Athlon/500
> system with pgcc-2.91.  The results he got were:
> 
>                         biquad 3dnow: 573
>                           biquad gcc: 679
>                    biquad bummed gcc: 340
>        biquad gcc (-O6 -mpentiumpro): 378
> biquad bummed gcc (-O6 -mpentiumpro): 353
>                            mix 3dnow: 64
>                              mix gcc: 136
>           mix gcc (-O6 -mpentiumpro): 99
> 
> As you can see, biquad/3dnow was actually slower on his system!  mix
> allowed 3dnow to maintain a (diminished) lead on the Athlon.  It's
> more inherently SIMD.  In the case of biquad I think 3dnow beat gcc on
> the k6-2 because the k6-2 fp architecture is just way behind 3dnow.
> In the Athlon it's leap-frogged ahead.  Apparently the 3dnow
> instructions have higher latency on the Athlon.  I have no idea
> whether AMD plans to fix this.
> 
> Lastly, the Athlon is fast. :)
> 
> Eric

From - Tue Sep  7 01:18:34 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA19997
	for <slinkp@ulster.net>; Mon, 6 Sep 1999 12:08:49 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA13651 for linux-audio-dev-list; Mon, 6 Sep 1999 11:16:44 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id LAA13647 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 6 Sep 1999 11:16:41 -0400
From: est@hyperreal.org
Received: (qmail 23793 invoked by uid 162); 6 Sep 1999 15:13:15 -0000
Message-ID: <19990906151315.23792.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] Athlon/3dnow! dsp benchmark results
In-Reply-To: <99090614363801.00704@linuxhost.localdomain> from Benno Senoner
 at "Sep 6, 1999 02:21:56 pm"
To: Benno Senoner <sbenno@gardena.net>
Date: Mon, 6 Sep 1999 08:13:15 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e9df2141143324a9a418c3680a08ad56

Benno Senoner discourseth:
>
> Eric: are you sure that the biquad filter is coded in an optimal way.
> Maybe you have to reorder things ?

Well, it's pretty optimal for the k6-2.  I sweated over it a *lot* but
couldn't get it above that 3.9-fold speedup even though I had a spare
register to play with.  I tried various unrollings and interleavings
and many, many reorderings (even some that were incorrect).

> I can't believe that 3Dnow is slower than optimized C on the Athlon.

..or that biquad/3dnow is slower on an Athlon/500 than a K6-2/350?  I
found it shocking but easier to believe than that Dieter is hoaxing
me.  Again, the Athlon has greater latency for 3dnow instructions.

Eric

From - Tue Sep  7 01:18:45 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA07959
	for <slinkp@ulster.net>; Mon, 6 Sep 1999 14:55:15 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA13920 for linux-audio-dev-list; Mon, 6 Sep 1999 14:14:05 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id OAA13917 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 6 Sep 1999 14:13:58 -0400
From: est@hyperreal.org
Received: (qmail 19226 invoked by uid 162); 6 Sep 1999 18:10:29 -0000
Message-ID: <19990906181029.19225.qmail@hyperreal.org>
Subject: [linux-audio-dev] more re csound -L
In-Reply-To: <37D35320.C23D2244@ulster.net> from Paul Winkler at "Sep 6, 1999
 01:37:36 am"
To: Paul Winkler <slinkp@ulster.net>
Date: Mon, 6 Sep 1999 11:10:29 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8003
X-Mozilla-Status2: 00000000
X-UIDL: 3346bb7789ef59313a1551a718b5fde4

Paul Winkler discourseth:
> 
> Need to do some feasibility testing to see if this _can_ work
> realtime. How accurate/reliable is application-generated timing sent
> to csound -L <devicename>?
> 
[...]
> 
> Previous experiments with csound events from stdin are not especially
> encouraging: more than about 10 simultaneous events were audibly not
> simultaneous.

I'm getting good results.  Interested parties should see
www.hyperreal.org/~est/csound/csoundL.tar.gz.

Eric

From - Tue Sep  7 01:18:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA07503
	for <slinkp@ulster.net>; Mon, 6 Sep 1999 19:32:28 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA14264 for linux-audio-dev-list; Mon, 6 Sep 1999 18:52:10 -0400
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id SAA14261 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 6 Sep 1999 18:52:08 -0400
Message-Id: <199909062252.SAA14261@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Plug-in API design decisions; please consider
To: David Olofson <audiality@swipnet.se>
Date: Mon, 6 Sep 1999 18:48:01 -0400 (EDT)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
In-Reply-To: <99082916172602.00444@localhost.localdomain> from "David Olofson" at Aug 29, 99 02:26:20 pm
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: fa920c36368e90317095f129a3f9b089

Old message here...

David Olofson wrote:
> .-------
> | Are we concentrating fully on audio-only, or
> | should we take other forms of data into account?
> `-------

And sound in general is more than just sampled audio!  I would love to
be able to deal with short-time spectra, LPC frames, timestamped audio
fragments, time-varying matrices, who knows what all.  Going down this
road does make the system unprecendentedly involved....

If people who program streaming video think what they'd want in a
plug-in system is the same as what we'd want for audio, sure, at least
reserve field-space for merging it in.  I'm leery of going out and
designing a video-processing system myself, since I don't do video and
wouldn't want to use a video guy's idea of an audio system either.
(Consider DirectShow, formerly known as ActiveMovie.  You can tell.)

Video people have god-awful synchronization issues that I never have to
think about.  Their frames are much longer than mine, so they might
consider it reasonable to hog the CPU for 20 msec.  I dunno what else
might come up.  You know, the more I think about this the more I think
the job is quite big enough already.

A counterargument is that if we ever want video/audio sync to work, we
probably have to do the work up-front and get it right now.

The rest of your post I'll have to read when I have some time.

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Tue Sep  7 03:56:24 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id EAA22164
	for <slinkp@ulster.net>; Tue, 7 Sep 1999 04:01:10 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id DAA14821 for linux-audio-dev-list; Tue, 7 Sep 1999 03:21:05 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA14818 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 7 Sep 1999 03:21:03 -0400
Received: from ulster.net (annex2-port45.ulster.net [208.133.193.45])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id DAA21053;
	Tue, 7 Sep 1999 03:34:02 -0400
Message-ID: <37D4BDC8.D1BF1947@ulster.net>
Date: Tue, 07 Sep 1999 03:24:56 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: est@hyperreal.org
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] more re csound -L
References: <19990906181029.19225.qmail@hyperreal.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 411d27e21f97081c22db6de429030ea8

est@hyperreal.org wrote:
> 
> Paul Winkler discourseth:
> >
> > Need to do some feasibility testing to see if this _can_ work
> > realtime. How accurate/reliable is application-generated timing sent
> > to csound -L <devicename>?
> >
> [...]
> >
> > Previous experiments with csound events from stdin are not especially
> > encouraging: more than about 10 simultaneous events were audibly not
> > simultaneous.
> 
> I'm getting good results.  Interested parties should see
> www.hyperreal.org/~est/csound/csoundL.tar.gz.

Thanks a lot! This definitely answers some of my questions.

I tried changing that last loop to run nothing but lots() 4 times, then
run that loop 16 times. On my system, having 30 events in lots() doesn't
work so well... it starts out sounding good, but within 5 seconds timing
has gone haywire and notes are breaking down into a blur of successive
notes...

I noticed your README says that
"Note well: the 30 events are written in a single call to os.write()"

I wanted to see how much that matters. The answer seems to be, "not all
that much" (not the answer I expected).
First I modified your function lots() into this:

def lotsn(n):
    amp = 30000 / n
    note = "i1 0 5 " + str(amp) + "\n"
    notes = note * n
    os.write(1, notes)

With this method, I can only get about n = 12 before timing starts to go
bad. Though it doesn't sound like individual "notes" (calls to lots())
are blurred; rather, they are misplaced in time. (Blurring happens
quickly with much higher values of n.)

I fiddled a bit more to see how much it hurts to have lots of os.write()
calls in a row...

def lotsmore(n):
    amp = 30000 / n
    note = "i1 0 5 " + str(amp) + "\n"
    for i in range (0, n ):
        os.write(1,  note)


You would think that for a given n, lotsn() would fare better than
lotsmore() since it only ever calls os.write() once.
But I'm not finding much difference...

Thoughts?


-- 

----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Tue Sep  7 03:56:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id EAA22191
	for <slinkp@ulster.net>; Tue, 7 Sep 1999 04:02:00 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id DAA14836 for linux-audio-dev-list; Tue, 7 Sep 1999 03:27:07 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA14833 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 7 Sep 1999 03:27:05 -0400
Received: from ulster.net (annex2-port45.ulster.net [208.133.193.45])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id DAA21329;
	Tue, 7 Sep 1999 03:40:06 -0400
Message-ID: <37D4BF35.DEFCD7C6@ulster.net>
Date: Tue, 07 Sep 1999 03:31:01 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: est@hyperreal.org
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] csound stereo problems
References: <19990906214635.15025.qmail@hyperreal.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: da862665e27bd52b030ae2a79e31a6c5

est@hyperreal.org wrote:
> 
> I was trying to hack panning into my csound-based sampler, but when
> using stereo the first channel seems to disappear and the second
> channel appears as both channels of the audio output.
> 
> I'm using unofficial-csound-3.57.0.1d-linux.
> 
> What stupid thing could I be doing wrong.

Nothing, I think. I just ran these and got all 3 notes panned like you'd
expect.

Possible causes:
hardware problem? soundcard mixer set up funny?
(play some stereo files just in case...)

or some totally bizarre bug in 3.57.0.1d-linux
(I'm using an 3.53.something).

--PW

From - Tue Sep  7 04:56:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id EAA24376
	for <slinkp@ulster.net>; Tue, 7 Sep 1999 04:57:43 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id EAA15062 for linux-audio-dev-list; Tue, 7 Sep 1999 04:10:06 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA15059 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 7 Sep 1999 04:10:04 -0400
Received: from ulster.net (annex2-port45.ulster.net [208.133.193.45])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id EAA22969;
	Tue, 7 Sep 1999 04:23:02 -0400
Message-ID: <37D4C923.FF750224@ulster.net>
Date: Tue, 07 Sep 1999 04:13:23 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: est@hyperreal.org
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] A Python loop sequencer, was re: using csoundas a  
 sampling engine
References: <19990906161156.17556.qmail@hyperreal.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 8245a98853d5896defbe3b2547ce439c

est@hyperreal.org wrote:

> Re (2): www.hyperreal.org/~est/oolaboola (major new release in two
> weeks) has a gui written in Python.  It communicates with the dsp over
> a pair of pipes using Scheme symbolic expressions (which are logged
> with timestamps to a file).

OK, I'm downloading oolaboola now! There are definitely some things I'm
going to want to see how you handled...
What exactly are Scheme symbolic expressions (aside from having
something to do with Scheme)? I've heard you guys talking about them and
always just scratched my head at those messages...

> oola is written using pygtk.  This may have some bearing on using
> python/tkinter for a similar project.  In particular, the following
> points may be of interest:
> 
> 1) I think pygtk is faster than Tkinter (because there's no tcl level
>    involved).

This is almost certainly true. However, I'm brand-new to GUI programming
of any sort, and looking at tutorials for both tk and gtk, I notice gtk
takes a lot more work to get it to do anything (at least for C; I
haven't looked at pygtk specifically, maybe I should). I think I can
live with slow displays as long as the sequencer itself isn't too slow
to be useful.

> 2) Even so, I perceive a subliminal mushiness to a pygtk gui, really only
>    noticable by the comparative feeling of `solidity' of a C/gtk app.
> 
> 3) I'm experiencing (2) even though I've migrated a fair amount of
>    code to Python extensions in C.

I'm curious: what specific speed problems motivated this? How much
improvement did you get?
 
> 4) When the gui is saturated with midi controller events it takes up
>    to 40% of my processor time.

Uh-oh. Do you mean midi continuous controllers?
I had hoped to make things update nicely in realtime, though I was only
thinking of mouse control, not MIDI.

  Worse, there's no hot-spot..nothing I
>    can migrate to C except the whole midi control architecture (the
>    parsing is already in C) which I wanted to keep in Python for easy
>    programmability.  On the plus side, my midi parsing module does
>    event compression if it runs out of cpu.

"event compression"? What's that?
 

> I wish it worked for me.  It freezes on the very pretty splash screen.

Cecilia, you mean? I haven't used it in quite some time.
I think it requires some specific versions of tcl/tk stuff installed.
The trouble with freeware closed-source projects is the authors never
have time to fix stuff like that... haven't seen a cecilia update in a
*long* time... 
 

> > of timing. Try it with both stdin and FIFOs -- does that make a
> > difference?
> 
> It shouldn't..stdin *would* be an (unnamed) fifo if you're piping to
> it.

Thanks for the info.
 
> > Previous experiments with csound events from stdin are not especially
> > encouraging: more than about 10 simultaneous events were audibly not
> > simultaneous.
> 
> Hmm..what was your k-rate..and your overall system configuration.

Don't remember k-rate.
I haven't tweaked my system much at all. What specifically?

> Something that could produce this problem would be quite useful.

OK, now I've been trying your csoundL stuff and still finding problems
between 10 and 15 simultaneous events. Not blurring of attack time, but
weird glitches in the timing of each whole bunch of events... See my
other message about that...

> > line. If I want to send 50 simultaneous events, maybe they should fill
> > the buffer and _then_ flush it before going to the next event? If so, my
> > engine would need to efficiently know when it's done with "current"
> > events.
> 
> This shouldn't make too much difference.  I haven't checked the csound
> code, but I'll bet it checks the -L input on every k-cycle and
> processes anything it finds there.  It may need to be tweaked in some
> ways..we'll see!  Also, if you really want to gather up your events
> before sending them, the wait-to-flush approach will be unreliable
> since stdio may autoflush anyhow.

Aha, good point. I haven't looked at csound code lately either. I tried
once. Brrrr. Too much for my newbie eyes.

> I don't think there's a problem here except for the limitations of the
> kernel you're using.  I think us linux-audio people generally want a
> >=1000HZ kernel anyhow.

Hmmm, maybe I should try that kernel recompile with higher HZ...
 
> >      --Held notes: I want a way to optionally say "Do this until I
> >        tell you to
> >        stop" -- that is, follow the "noteoff" paradigm rather than the
> >        "dur" paradigm. Sometimes this just makes more sense.
> 
> I don't know enough about csound yet.  Is there a way for an
> instrument to explicitly say "I'm done, deallocate me now!".  If so
> then this could be handled via table entries.

Well, I see you've already figured out one solution.

> Thanks for posting these thoughts! :)
> 
> Eric

-- 

----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Wed Sep  8 03:56:23 1999
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA18061
	for <slinkp@ulster.net>; Tue, 7 Sep 1999 10:06:25 -0400
From: est@hyperreal.org
Received: (qmail 28312 invoked by uid 162); 7 Sep 1999 13:49:43 -0000
Message-ID: <19990907134943.28311.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] more re csound -L
In-Reply-To: <37D4BDC8.D1BF1947@ulster.net> from Paul Winkler at "Sep 7, 1999
 03:24:56 am"
To: Paul Winkler <slinkp@ulster.net>
Date: Tue, 7 Sep 1999 06:49:43 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4457b188cd0ced390057bc22dc248e62

Paul Winkler discourseth:
> est@hyperreal.org wrote:
> >
> > I'm getting good results.  Interested parties should see
> > www.hyperreal.org/~est/csound/csoundL.tar.gz.
> 
> Thanks a lot! This definitely answers some of my questions.
> 
> I tried changing that last loop to run nothing but lots() 4 times, then
> run that loop 16 times. On my system, having 30 events in lots() doesn't
> work so well... it starts out sounding good, but within 5 seconds timing
> has gone haywire and notes are breaking down into a blur of successive
> notes...

That's with the single call to os.write() per call to lots?  Hmm, I
don't have that problem at all.  Maybe you should try it with
unofficial-csound-3.57.0.1d-linux.

> [ with another method] I can only get about n = 12 before timing starts to go
> bad. Though it doesn't sound like individual "notes" (calls to lots())
> are blurred; rather, they are misplaced in time. (Blurring happens
> quickly with much higher values of n.)
[also]
> You would think that for a given n, lotsn() would fare better than
> lotsmore() since it only ever calls os.write() once.
> But I'm not finding much difference...

It's partly a matter of reliability.  Someone else might run *between*
your calls to write.

Anyhow, to really isolate these problems, you'd need to run both
processes as real-time processes, apply the real-time patches, and
upgrade your HZ (..and possibly also change the SCHED_RR
quantum..yikes!  i haven't looked into that question yet.).  I hadn't
done *any* of that and got good (though no doubt unreliable) results,
but lacking any of those can easily cause some of the problems you
described.

Eric

From - Wed Sep  8 03:56:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA24124
	for <slinkp@ulster.net>; Tue, 7 Sep 1999 10:47:11 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA15455 for linux-audio-dev-list; Tue, 7 Sep 1999 09:53:15 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id JAA15452 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 7 Sep 1999 09:53:13 -0400
From: est@hyperreal.org
Received: (qmail 28312 invoked by uid 162); 7 Sep 1999 13:49:43 -0000
Message-ID: <19990907134943.28311.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] more re csound -L
In-Reply-To: <37D4BDC8.D1BF1947@ulster.net> from Paul Winkler at "Sep 7, 1999
 03:24:56 am"
To: Paul Winkler <slinkp@ulster.net>
Date: Tue, 7 Sep 1999 06:49:43 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: bb9985cca451a0307c424f4fd7ce588f

Paul Winkler discourseth:
> est@hyperreal.org wrote:
> >
> > I'm getting good results.  Interested parties should see
> > www.hyperreal.org/~est/csound/csoundL.tar.gz.
> 
> Thanks a lot! This definitely answers some of my questions.
> 
> I tried changing that last loop to run nothing but lots() 4 times, then
> run that loop 16 times. On my system, having 30 events in lots() doesn't
> work so well... it starts out sounding good, but within 5 seconds timing
> has gone haywire and notes are breaking down into a blur of successive
> notes...

That's with the single call to os.write() per call to lots?  Hmm, I
don't have that problem at all.  Maybe you should try it with
unofficial-csound-3.57.0.1d-linux.

> [ with another method] I can only get about n = 12 before timing starts to go
> bad. Though it doesn't sound like individual "notes" (calls to lots())
> are blurred; rather, they are misplaced in time. (Blurring happens
> quickly with much higher values of n.)
[also]
> You would think that for a given n, lotsn() would fare better than
> lotsmore() since it only ever calls os.write() once.
> But I'm not finding much difference...

It's partly a matter of reliability.  Someone else might run *between*
your calls to write.

Anyhow, to really isolate these problems, you'd need to run both
processes as real-time processes, apply the real-time patches, and
upgrade your HZ (..and possibly also change the SCHED_RR
quantum..yikes!  i haven't looked into that question yet.).  I hadn't
done *any* of that and got good (though no doubt unreliable) results,
but lacking any of those can easily cause some of the problems you
described.

Eric

From - Wed Sep  8 03:56:38 1999
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA18702
	for <slinkp@ulster.net>; Tue, 7 Sep 1999 13:27:35 -0400
From: est@hyperreal.org
Received: (qmail 13738 invoked by uid 162); 7 Sep 1999 17:10:55 -0000
Message-ID: <19990907171055.13737.qmail@hyperreal.org>
Subject: python audio development details, etc
In-Reply-To: <37D4C923.FF750224@ulster.net> from Paul Winkler at "Sep 7, 1999
 04:13:23 am"
To: Paul Winkler <slinkp@ulster.net>
Date: Tue, 7 Sep 1999 10:10:55 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8003
X-Mozilla-Status2: 00000000
X-UIDL: 9518034b22dc8bb29b00f8fd86309a6b

Paul Winkler discourseth:
> est@hyperreal.org wrote:
> 
> > Re (2): www.hyperreal.org/~est/oolaboola (major new release in two
> > weeks) has a gui written in Python.  It communicates with the dsp over
> > a pair of pipes using Scheme symbolic expressions (which are logged
> > with timestamps to a file).
> 
> OK, I'm downloading oolaboola now! There are definitely some things I'm
> going to want to see how you handled...

Things are often handled abominably. :) The new release will have a
good amount of internal cleanup, but there's plenty more to come.

> What exactly are Scheme symbolic expressions (aside from having
> something to do with Scheme)? I've heard you guys talking about them and
> always just scratched my head at those messages...

Its a polymorphic datatype consisting of pairs (which are the building
blocks of lists), symbols, strings, numbers, booleans, etc.  They have
a well-defined textual representation and procedures to read and write
them are basic to Scheme.  What I like about it is that it lets me
forget about the lexical details of textually represented structured
data and just concentrate on the abstract syntax.  A simple example
would be:

 (note-on 5 60 90)

If you type that into guile preceeded by a single quote, you'll
get..well, the same thing back!  It's a list of 4 elements: one symbol
and 3 integers.

As mentioned in other messages, symbolic expressions compare in
interesting ways with XML as a representation strategy.

BTW, I'm working on a real-time implementation of Scheme.  It will
allow a lot of the easy extensibility Python provides along with the
speed of more of a `systems language'.  Python will still have a place
for me though..it really has its own linguistic niche.

> > oola is written using pygtk.  This may have some bearing on using
> > python/tkinter for a similar project.  In particular, the following
> > points may be of interest:
> > 
> > 1) I think pygtk is faster than Tkinter (because there's no tcl level
> >    involved).
> 
> This is almost certainly true. However, I'm brand-new to GUI programming
> of any sort, and looking at tutorials for both tk and gtk, I notice gtk
> takes a lot more work to get it to do anything (at least for C; I
> haven't looked at pygtk specifically, maybe I should). I think I can
> live with slow displays as long as the sequencer itself isn't too slow
> to be useful.

Fair enough. :) There's a nice Tkinter intro in the larger Lutz book
also.

> > 3) I'm experiencing (2) even though I've migrated a fair amount of
> >    code to Python extensions in C.
> 
> I'm curious: what specific speed problems motivated this? How much
> improvement did you get?

Oh, it was fairly random stuff..generally any place where too much
logic was executed too often.  Remember that the basic execution speed
of python is about 100x slower than C!  I profiled the python script
(Profiling is one of the great things about python.  You can invoke
oola with script profiling via the --profile option :) and migrated
what I could that was taking a lot of time to C.  I have no idea what
the overall speedup was, but I wouldn't be surprised if it were 2 to
10 times.  One thing that still consumes a lot of time is the
play-position slider and read-outs.  I think I may create a full-dress
gtk widget for that (I've already done so for the level-hold
meters..making them much prettier :)

> > 4) When the gui is saturated with midi controller events it takes up
> >    to 40% of my processor time.
> 
> Uh-oh. Do you mean midi continuous controllers?

Yes.

> I had hoped to make things update nicely in realtime, though I was only
> thinking of mouse control, not MIDI.

That might not be too hard..remember those midi cc events can arrive
at a ridiculous rate.

> >    Worse, there's no hot-spot..nothing I
> >    can migrate to C except the whole midi control architecture (the
> >    parsing is already in C) which I wanted to keep in Python for easy
> >    programmability.  On the plus side, my midi parsing module does
> >    event compression if it runs out of cpu.
> 
> "event compression"? What's that?

That's where you disregard all but the most recent value of a stream
of cc events.  My streaming midi input module does it when the client
hands it a chunk of input containing more than one event for a given
continuous controller.  In that case, it calls the callback only for
the last event for each controller.  If the client hands it one or two
bytes at a time, there's no compression.

> > I wish it worked for me.  It freezes on the very pretty splash screen.
> 
> Cecilia, you mean?

Yes, indeed.

> I haven't used it in quite some time.
> I think it requires some specific versions of tcl/tk stuff installed.
> The trouble with freeware closed-source projects is the authors never
> have time to fix stuff like that... haven't seen a cecilia update in a
> *long* time... 

Yes..such things are often not worth the time of learning to use!

> > Hmm..what was your k-rate..and your overall system configuration.
> 
> Don't remember k-rate.
> I haven't tweaked my system much at all. What specifically?

Oh, what kind of cpu and kernel for example.

> Aha, good point. I haven't looked at csound code lately either. I tried
> once. Brrrr. Too much for my newbie eyes.

The csound code is generally even more abominable than mine..doesn't
keep it from being a great program though. :)

> > I don't think there's a problem here except for the limitations of the
> > kernel you're using.  I think us linux-audio people generally want a
> > >=1000HZ kernel anyhow.
> 
> Hmmm, maybe I should try that kernel recompile with higher HZ...

It's good for tight timing.  At the moment it tends to screw up
various utilities though.  top(1) becomes fairly useless for example.

Eric

From - Wed Sep  8 03:57:01 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA03602
	for <slinkp@ulster.net>; Tue, 7 Sep 1999 18:38:50 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA16149 for linux-audio-dev-list; Tue, 7 Sep 1999 17:58:53 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA16146 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 7 Sep 1999 17:58:50 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id RAA01833
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 7 Sep 1999 17:55:16 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id RAA19968; Tue, 7 Sep 1999 17:55:16 -0400 (EDT)
Date: Tue, 7 Sep 1999 17:55:08 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] A Python loop sequencer, was re: using csound
 as a  sampling engine
In-Reply-To: <37D35320.C23D2244@ulster.net>
Message-ID: <Pine.GSO.4.10.9909071733380.19724-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b251f28ed1e462031a04d5315aefe606

On Mon, 6 Sep 1999, Paul Winkler wrote:

> I was thinking about building a vaguely 303-ish sequencer that, while
> not pretending to be a general-purpose sequencer, does a LOT more than a
> 303-clone. Sort of like a graphical tracker with unlimited parameters.
> I was thinking of writing it in python with a Tkinter interface. And
> most relevant to your post, I was thinking of ignoring midi entirely and
> using Csound as the synthesis engine, via stdin or a pipe.

Intriguing.  It brings to mind something I was thinking of playing with
once my sequencer got to a useable state:

We all know that Csound can take input over MIDI in realtime.  We also
know that when it does so, it loses all the power of its arbitrary-number-
and-meaning-of-parameters-per-event design.  Would it be possible to write
a patch to Csound so that it _would_ accept full score-file-style events
wrapped as MIDI sysex events in realtime?

If you could do that, you could drive Csound (at full power) from a MIDI
sequencer or something like JMax.  At the same time you would get free
[MIDI-based] syncronization with other softsynths and even hardware MIDI
devices.  This would be truly wonderful to me.

Div.

P.S.  Anybody want to propose a sysex message format for a Csound event?

From - Wed Sep  8 03:57:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA06077
	for <slinkp@ulster.net>; Tue, 7 Sep 1999 18:55:23 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA16195 for linux-audio-dev-list; Tue, 7 Sep 1999 18:14:52 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA16192 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 7 Sep 1999 18:14:50 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id SAA03035
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 7 Sep 1999 18:11:05 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id SAA20063; Tue, 7 Sep 1999 18:11:05 -0400 (EDT)
Date: Tue, 7 Sep 1999 18:11:03 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] A Python loop sequencer, was re: using csound
 as a  sampling engine
In-Reply-To: <19990906161156.17556.qmail@hyperreal.org>
Message-ID: <Pine.GSO.4.10.9909071809580.19724-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b30efa0b87ff2699f010a4a25a6a6e85

On Mon, 6 Sep 1999 est@hyperreal.org wrote:

> Generally not.  Pipes typically have a 4K buffer internally.  However,
> I don't see that that should cause a problem.

I love pipes, particularly the named variety.  However, I haven't figured
out how to adjust the buffer size.  Have you?

Div.


From - Wed Sep  8 03:57:07 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA08564
	for <slinkp@ulster.net>; Tue, 7 Sep 1999 19:12:38 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA16224 for linux-audio-dev-list; Tue, 7 Sep 1999 18:34:52 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA16221 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 7 Sep 1999 18:34:50 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id SAA04325
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 7 Sep 1999 18:29:30 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id SAA20150; Tue, 7 Sep 1999 18:29:30 -0400 (EDT)
Date: Tue, 7 Sep 1999 18:29:28 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] python audio development details, etc
In-Reply-To: <19990907171055.13737.qmail@hyperreal.org>
Message-ID: <Pine.GSO.4.10.9909071820280.19724-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3be3f83ed253e4a7cd1bdefb86cef89e

On Tue, 7 Sep 1999 est@hyperreal.org wrote:

> BTW, I'm working on a real-time implementation of Scheme.  It will
> allow a lot of the easy extensibility Python provides along with the
> speed of more of a `systems language'.  Python will still have a place
> for me though..it really has its own linguistic niche.

Now _that_ is very intriguing, and not just from an audio standpoint.
eWhat makes a language (not an OS) inherently realtime oriented?  C, C++,
and Pascal (the system languages of Unix, Windows, and MacOS respectively)
make no availability guarantees for realtime purposes that I know about.

If you just mean fast, there are a number of existing Scheme
implementations or variations that use just-in-time compilation to achieve
pretty impressive speed (or so they claim).  Check Freshmeat.  I
personally rather like the idea of working in Scheme for practical,
everyday purposes.  I only wish there was some ubiquitous implementation
that could be relied upon in the manner of C or Perl (Guile just isn't
there yet).

Div.

From - Wed Sep  8 03:57:08 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA09247
	for <slinkp@ulster.net>; Tue, 7 Sep 1999 19:18:15 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA16245 for linux-audio-dev-list; Tue, 7 Sep 1999 18:44:16 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id SAA16242 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 7 Sep 1999 18:44:13 -0400
From: est@hyperreal.org
Received: (qmail 3182 invoked by uid 162); 7 Sep 1999 22:40:47 -0000
Message-ID: <19990907224047.3181.qmail@hyperreal.org>
Subject: [linux-audio-dev] sysex -> csound score event
In-Reply-To: <Pine.GSO.4.10.9909071733380.19724-100000@ux02.CS.Princeton.EDU>
 from David Slomin at "Sep 7, 1999 05:55:08 pm"
To: David Slomin <dgslomin@CS.Princeton.EDU>
Date: Tue, 7 Sep 1999 15:40:47 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 640b2944906e6f1e355e5c8bc12db98c

David Slomin discourseth:
> 
> Intriguing.  It brings to mind something I was thinking of playing with
> once my sequencer got to a useable state:
> 
> We all know that Csound can take input over MIDI in realtime.  We also
> know that when it does so, it loses all the power of its arbitrary-number-
> and-meaning-of-parameters-per-event design.  Would it be possible to write
> a patch to Csound so that it _would_ accept full score-file-style events
> wrapped as MIDI sysex events in realtime?

Sure, just use a transducer ahead of csound in the pipe that unwraps
the score events from the sysex's.  This makes it generic to any
program that accepts extended textual events.

> P.S.  Anybody want to propose a sysex message format for a Csound event?

Well, there are some ways it might perhaps be made easier to use.  For
example, you might have a sysex that specified a translation scheme
for note events..basically a string with escapes for key and velocity
in it.  The transducer could then apply that scheme to subsequent note
events.  I think we'll discover plenty of such tricks just playing
around with such a system.

Eric

From - Wed Sep  8 03:57:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA11709
	for <slinkp@ulster.net>; Tue, 7 Sep 1999 19:34:53 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA16273 for linux-audio-dev-list; Tue, 7 Sep 1999 18:57:24 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id SAA16270 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 7 Sep 1999 18:57:22 -0400
From: est@hyperreal.org
Received: (qmail 16639 invoked by uid 162); 7 Sep 1999 22:52:24 -0000
Message-ID: <19990907225224.16638.qmail@hyperreal.org>
Subject: [linux-audio-dev] pipe buffer sizes
In-Reply-To: <Pine.GSO.4.10.9909071809580.19724-100000@ux02.CS.Princeton.EDU>
 from David Slomin at "Sep 7, 1999 06:11:03 pm"
To: David Slomin <dgslomin@CS.Princeton.EDU>
Date: Tue, 7 Sep 1999 15:52:24 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: e981dabf3b30de60a9da52a1395f5ac1

David Slomin discourseth:
> On Mon, 6 Sep 1999 est@hyperreal.org wrote:
> 
> > Generally not.  Pipes typically have a 4K buffer internally.  However,
> > I don't see that that should cause a problem.
> 
> I love pipes, particularly the named variety.  However, I haven't figured
> out how to adjust the buffer size.  Have you?

Modify PIPE_BUF in /usr/src/linux/include/linux/limits.h :)

Why would you want to?  To maintain atomicity of aribitrary sized
writes on a fifo by multiple processes?  I don't think that would be
too hard to hack into the kernel.  You'd just need an extra channel to
wait on in pipe_write().

Eric

From - Wed Sep  8 03:57:10 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA16652
	for <slinkp@ulster.net>; Tue, 7 Sep 1999 20:07:48 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA16328 for linux-audio-dev-list; Tue, 7 Sep 1999 19:17:49 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id TAA16325 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 7 Sep 1999 19:17:40 -0400
From: est@hyperreal.org
Received: (qmail 8999 invoked by uid 162); 7 Sep 1999 23:14:12 -0000
Message-ID: <19990907231412.8998.qmail@hyperreal.org>
Subject: [linux-audio-dev] real-time scheme implementation
In-Reply-To: <Pine.GSO.4.10.9909071820280.19724-100000@ux02.CS.Princeton.EDU>
 from David Slomin at "Sep 7, 1999 06:29:28 pm"
To: David Slomin <dgslomin@CS.Princeton.EDU>
Date: Tue, 7 Sep 1999 16:14:12 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 8a710129eb5c5c108763068c38191ac9

David Slomin discourseth:
> On Tue, 7 Sep 1999 est@hyperreal.org wrote:
> 
> > BTW, I'm working on a real-time implementation of Scheme.  It will
> > allow a lot of the easy extensibility Python provides along with the
> > speed of more of a `systems language'.  Python will still have a place
> > for me though..it really has its own linguistic niche.
> 
> Now _that_ is very intriguing, and not just from an audio standpoint.
> What makes a language (not an OS) inherently realtime oriented?

In this case I'm talking about hard real-time garbage collection with
safe-for-space guarantees and a run-time system that won't unduly
block threads from running (say in the middle of a bignum multiply).

> I
> personally rather like the idea of working in Scheme for practical,
> everyday purposes.

Ahh..that's nice to hear.  Sequencing is a lot of my motivation, btw,
considering how it consists of patterns and transformations
thereof. :)

I hope to bootstrap my compiler/run-time this year.  Even if I don't
make it, I'll put up a website with current progress by year-end.

Eric

From - Wed Sep  8 22:27:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id FAA10140
	for <slinkp@ulster.net>; Wed, 8 Sep 1999 05:36:37 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id EAA17231 for linux-audio-dev-list; Wed, 8 Sep 1999 04:50:41 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA17228 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 8 Sep 1999 04:50:38 -0400
Received: from ulster.net (port177.king.ulster.net [208.242.160.178])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id FAA08640;
	Wed, 8 Sep 1999 05:03:44 -0400
Message-ID: <37D62446.3064D3AD@ulster.net>
Date: Wed, 08 Sep 1999 04:54:30 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: est@hyperreal.org
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: python audio development details, etc
References: <19990907171055.13737.qmail@hyperreal.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 9b0043fd659552daecd87d4ea106128d

est@hyperreal.org wrote:
> BTW, I'm working on a real-time implementation of Scheme.  It will
> allow a lot of the easy extensibility Python provides along with the
> speed of more of a `systems language'.

Cool idea. That might get me to finally get my lisp feet wet (so far all
I do is wrangle my .emacs file into something that sort of does what I
want even if I don't understand it.) 
I hesitate to ask how you will accomplish the speed. (probably way over
my head!)


> >
> > "event compression"? What's that?
> 
> That's where you disregard all but the most recent value of a stream
> of cc events.  My streaming midi input module does it when the client
> hands it a chunk of input containing more than one event for a given
> continuous controller.  In that case, it calls the callback only for
> the last event for each controller.  If the client hands it one or two
> bytes at a time, there's no compression.

Hmm, very useful idea. not sure if it applies to anything in my project
but I'll keep it in mind.

> > > Hmm..what was your k-rate..and your overall system configuration.
> >
> > Don't remember k-rate.
> > I haven't tweaked my system much at all. What specifically?
> 
> Oh, what kind of cpu and kernel for example.

Celeron 333, 66 mhz bus (gotta switch to PC100 RAM), kernel 2.0.36. I'm
about due for a major linux upgrade but I like to wait till there's a
compelling reason to get a new CD so I don't have to download quite so
much.

> > Hmmm, maybe I should try that kernel recompile with higher HZ...
> 
> It's good for tight timing.  At the moment it tends to screw up
> various utilities though.  top(1) becomes fairly useless for example.

Well, I can just keep my old kernel handy and give it a different LILO
image.


----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Wed Sep  8 22:27:08 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA17545
	for <slinkp@ulster.net>; Wed, 8 Sep 1999 07:38:22 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA17464 for linux-audio-dev-list; Wed, 8 Sep 1999 06:43:56 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA17461 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 8 Sep 1999 06:43:53 -0400
Received: from trkkazulu (d212-151-161-98.swipnet.se [212.151.161.98]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id MAA15585 for <linux-audio-dev@ginette.musique.umontreal.ca>; 
          Wed, 8 Sep 1999 12:40:22 +0200 (MET DST)
Message-ID: <002501bef9e9$bb2df500$62a197d4@trkkazulu>
From: "Jair-Rohm" <gtc@mbox200.swipnet.se>
To: <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] python audio development details, etc
Date: Wed, 8 Sep 1999 12:46:35 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0017_01BEF9F8.2F3412A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7de0831542a50f34ec24e69f0b60142c

This is a multi-part message in MIME format.

------=_NextPart_000_0017_01BEF9F8.2F3412A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

High all;

I've been following this thread and wonder if anyone has tried =
developing an audio app in Java. What were your experiences? What =
advantages/disadvantages did you encounter?=20

------=_NextPart_000_0017_01BEF9F8.2F3412A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#c0c0c0>
<DIV><FONT color=3D#000000>High all;</FONT></DIV>
<DIV><FONT color=3D#000000></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000>I've been following this thread and wonder if =
anyone=20
has tried developing an audio app in Java. What were your experiences? =
What=20
advantages/disadvantages did you encounter? </FONT></DIV></BODY></HTML>

------=_NextPart_000_0017_01BEF9F8.2F3412A0--

From - Wed Sep  8 22:27:11 1999
Received: from em.gardena.net ([212.11.71.70])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id JAA32257
	for <slinkp@ulster.net>; Wed, 8 Sep 1999 09:43:29 -0400
Received: from linuxhost.localdomain (IDENT:root@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id PAA07640;
	Wed, 8 Sep 1999 15:26:02 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id RAA00894;
	Wed, 8 Sep 1999 17:08:23 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Paul Winkler <slinkp@ulster.net>, est@hyperreal.org
Subject: Re: [linux-audio-dev] A Python loop sequencer, was re: using csound as a sampling engine
Date: Wed, 8 Sep 1999 16:45:28 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca,
        David Olofson <audiality@swipnet.se>
References: <37D35320.C23D2244@ulster.net>
MIME-Version: 1.0
Message-Id: <99090817082303.00759@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 6b43ea4b2d0f9283a344d8ec43156de7

On Mon, 06 Sep 1999, Paul Winkler wrote:
>       A big question is whether a python script is even capable of
>       REALLY accurately timing its output. The built-in time and sched
>       modules are probably what I'll end up using. Try them! How fast
> are they?

I do not know python, but interpreted scripts are much slower than
C/C++ code, don't expect 1msec precisions.

>       Do some experiments. Can't find anything on dejanews about this.
>       For my purposes, timing resolution down to 1 msec is probably
>       plenty. I bet 10 msec would even be useable for a lot of stuff
>       (though probably ultimately frustrating).
> 
> This all probably depends on the speed of getting stuff into and out of
> the
> FIFO or pipe... 
> 
> If this proves to be unworkable, is there any other (faster) way to get
> realtime events to Csound? Some sort of IPC? I don't think so.
> Somebody was working on reading k-rate values in realtime from X11
> scrollbars, but I don't know if they ever finished it, or if it could
> be used for "i" events...

I don't know the performance of named pipes, but
i benchmarked the IPC functions msgsnd() , msgrvc()
and was able to send about 45000-90000 short messges, between 2 processes
therefore the delay is around 15-30usecs (on my PII400).

Pipes uses usually 4k buffers, and maybe you are experiencing buffering/flushing
problems.

> 
> Or if Python is the source of timing problems, could I implement the
> core event-sending mechanism in C? I don't want to have to do
> this... In fact, I'm NOT going to do that. If the feasibility test
> fails, the project will probably die. let's hope it works.

I'm not very confident that Python will be suitable for RT apps,
especially music that require precisions in the 1-5ms range for
stable timing + low-latency. 

I think sooner or later we should all join our efforts and contribute
to the Audiality project (with first versions running in userspace on
ordinary Linux kernel , then on RT-Linux with sub 1msec lanecies).

Audiality will be designed with realtime, flexibility, efficiency and
scalabitily in mind.

In future, designing an audio app will be more a GUI programming task
than re-implementing audio-engines evertime from scratch.

For example oolabola could be almost a GUI app which calls
audiality modules and connect them together.
For example:
- open 2 instances of the wave-streamer plugin (will be capable of stream
audio from disk)
- wire the wave streamers to 2 resampler-plugins (do change pitch)
- send the results to 2 equalizers and finally mix together the audio.

The user could then easily feed the oolabola output to a track of a harddisk
recording app.
If you want to use your high quality EQ in your preferred
audio-app, just load the plug-in and replace your standard EQ.


regards,
Benno

--
Benno Senoner
E-Mail: sbenno@gardena.net
Linux low-latency audio / scheduling latency benchmarks
http://www.gardena.net/benno/linux/audio

From - Wed Sep  8 22:27:23 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA24612
	for <slinkp@ulster.net>; Wed, 8 Sep 1999 15:54:56 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA18245 for linux-audio-dev-list; Wed, 8 Sep 1999 15:14:48 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA18242 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 8 Sep 1999 15:14:45 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id PAA02749
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 8 Sep 1999 15:09:31 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id PAA29226; Wed, 8 Sep 1999 15:09:31 -0400 (EDT)
Date: Wed, 8 Sep 1999 15:09:25 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: sysex -> csound score event
In-Reply-To: <19990907224047.3181.qmail@hyperreal.org>
Message-ID: <Pine.GSO.4.10.9909081500150.29057-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: d8d698d8aedbef845335271488e2f8d7

On Tue, 7 Sep 1999 est@hyperreal.org wrote:

> Sure, just use a transducer ahead of csound in the pipe that unwraps
> the score events from the sysex's.  This makes it generic to any
> program that accepts extended textual events.

Very nice... I feel silly for not having thought of that myself.  I've
never personally used Csound in that manner though (driving it in realtime
but using its native score language on a pipe rather than MIDI); can it
really do that?
 
> Well, there are some ways it might perhaps be made easier to use.  
> For example, you might have a sysex that specified a translation
> scheme for note events..basically a string with escapes for key and
> velocity in it.  The transducer could then apply that scheme to
> subsequent note events.  I think we'll discover plenty of such tricks
> just playing around with such a system.

Very utterly cool.  You could then build up a many-parametered Csound
event out of several MIDI events (note-on event for pitch and velocity, cc
events for most of the others).  This is worlds better than my original
idea because it lets you utilize your MIDI keyboard's real sliders and
knobs (and your sequencer's visual editors for same), rather than stuffing
everything into an unwieldy, opaque sysex.

Want me to implement it or will you?

Great ideas!
Div.

From - Wed Sep  8 22:27:25 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA28224
	for <slinkp@ulster.net>; Wed, 8 Sep 1999 16:16:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA18288 for linux-audio-dev-list; Wed, 8 Sep 1999 15:36:52 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA18285 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 8 Sep 1999 15:36:50 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id PAA05189
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 8 Sep 1999 15:33:15 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id PAA29432; Wed, 8 Sep 1999 15:33:15 -0400 (EDT)
Date: Wed, 8 Sep 1999 15:33:13 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] A Python loop sequencer, was re: using csound
 as a sampling engine
In-Reply-To: <99090817082303.00759@linuxhost.localdomain>
Message-ID: <Pine.GSO.4.10.9909081522200.29057-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1e8defdd2d13a14de4ae6637716d041c

On Wed, 8 Sep 1999, Benno Senoner wrote:

> I think sooner or later we should all join our efforts and contribute
> to the Audiality project (with first versions running in userspace on
> ordinary Linux kernel , then on RT-Linux with sub 1msec lanecies).

Don't forget that there's never such a thing as "one size fits all",
only "one size fits most" at best.  

I don't see myself as ever running Audiality (much less writing code that
relies on it) because I do not like the idea of having to run RT-Linux.
I'm a hobbiest musician, not a professional, so I'm not willing to
dedicate a machine to the job; I only run general purpose OS's.  This
doesn't mean I think there's no place for Audiality, but I don't think
it's realistic to expect _all_ the Linux audio developers to target that
single niche.

Besides, I don't think I've ever even written a program "for Linux".  I
write for Posix or for the JVM and test/use it on Linux.  Here's a new
poll for the day:  How many of you developers on the LAD list only target
Linux?

Just a cent or two,
Div.

From - Wed Sep  8 22:27:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA08842
	for <slinkp@ulster.net>; Wed, 8 Sep 1999 17:36:00 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA18419 for linux-audio-dev-list; Wed, 8 Sep 1999 16:56:53 -0400
Received: from gauss.deltav.hu (gauss.deltav.hu [194.9.64.225]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA18416 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 8 Sep 1999 16:56:49 -0400
Received: from cerealbox (103.dial02.deltav.hu [194.9.64.103])
          by gauss.deltav.hu (Netscape Messaging Server 3.6)  with ESMTP
          id AAA6922 for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Wed, 8 Sep 1999 22:56:27 +0200
Received: from reactor by cerealbox with local (Exim 1.92 #1 (Debian))
	id 11Oone-00005f-00; Wed, 8 Sep 1999 22:58:38 +0200
Message-ID: <19990908225838.A174@cerealbox>
Date: Wed, 8 Sep 1999 22:58:38 +0200
From: reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] A Python loop sequencer, was re: using csound as a sampling engine
Reply-To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
References: <99090817082303.00759@linuxhost.localdomain> <Pine.GSO.4.10.9909081522200.29057-100000@ux02.CS.Princeton.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.91.2
In-Reply-To: <Pine.GSO.4.10.9909081522200.29057-100000@ux02.CS.Princeton.EDU>; from David Slomin on Wed, Sep 08, 1999 at 03:33:13PM -0400
Organization: CTP media laboratories
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b7ff7b95f8ff99bfa16d29ef649386f6

 >% poll for the day:  How many of you developers on the LAD list only target
 >% Linux?

i'm one.

-- 

  Mt Rcz a.k.a. reactor  -  http://linux.gyakg.u-szeged.hu/~reactor/
   CTP media - since 1995   -  http://ctpmedia.scene.hu/

From - Wed Sep  8 22:27:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA15614
	for <slinkp@ulster.net>; Wed, 8 Sep 1999 18:18:55 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA18533 for linux-audio-dev-list; Wed, 8 Sep 1999 17:42:51 -0400
Received: from mail.virginia.edu (mail.Virginia.EDU [128.143.2.9]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id RAA18530 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 8 Sep 1999 17:42:49 -0400
Received: from neon.mail.virginia.edu by mail.virginia.edu id ab21143;
          8 Sep 99 17:39 EDT
Received: from virginia.edu (bootp-141-105.bootp.Virginia.EDU [128.143.141.105])
	by neon.mail.Virginia.EDU (8.8.7/8.8.7) with ESMTP id RAA21557
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 8 Sep 1999 17:39:18 -0400 (EDT)
Message-ID: <37D6D9EA.D7E5F43@virginia.edu>
Date: Wed, 08 Sep 1999 17:49:30 -0400
From: "David J. Topper" <topper@virginia.edu>
Organization: University of Virginia
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "linux-audio-dev@ginette.musique.umontreal.ca" <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Laptop MIDI?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 454808b661a4ac088518fefca5dec35b

Hi folks,

I know that the OSS drivers have no laptop MIDI support.  I'm wondering
if there are any drivers out there for serial or USB MIDI devices?

Thanks all,

DT
--
David Topper
Technical Director - Virginia Center for Computer Music
Programmer Analyst - School of Arts and Sciences
http://www.people.virginia.edu/~djt7p
(804) 924-6887


From - Wed Sep  8 22:27:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA17016
	for <slinkp@ulster.net>; Wed, 8 Sep 1999 18:29:06 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA18555 for linux-audio-dev-list; Wed, 8 Sep 1999 17:53:57 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id RAA18552 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 8 Sep 1999 17:53:55 -0400
From: est@hyperreal.org
Received: (qmail 28450 invoked by uid 162); 8 Sep 1999 21:50:18 -0000
Message-ID: <19990908215018.28449.qmail@hyperreal.org>
Subject: [linux-audio-dev] hybrid midi/textual sequencer & java real-time deliverability
In-Reply-To: <Pine.GSO.4.10.9909081500150.29057-100000@ux02.CS.Princeton.EDU>
 from David Slomin at "Sep 8, 1999 03:09:25 pm"
To: David Slomin <dgslomin@CS.Princeton.EDU>
Date: Wed, 8 Sep 1999 14:50:18 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: f766f3eb760db516461cca94ddd70704

David Slomin discourseth:
> On Tue, 7 Sep 1999 est@hyperreal.org wrote:
> 
> > Sure, just use a transducer ahead of csound in the pipe that unwraps
> > the score events from the sysex's.  This makes it generic to any
> > program that accepts extended textual events.
> 
> Very nice... I feel silly for not having thought of that myself.  I've
> never personally used Csound in that manner though (driving it in realtime
> but using its native score language on a pipe rather than MIDI); can it
> really do that?

Yes indeed..I've listened to pleasant drum loops driven that way. :)

> > Well, there are some ways it might perhaps be made easier to use.  
> > For example, you might have a sysex that specified a translation
> > scheme for note events..basically a string with escapes for key and
> > velocity in it.  The transducer could then apply that scheme to
> > subsequent note events.  I think we'll discover plenty of such tricks
> > just playing around with such a system.
> 
> Very utterly cool.  You could then build up a many-parametered Csound
> event out of several MIDI events (note-on event for pitch and velocity, cc
> events for most of the others).  This is worlds better than my original
> idea because it lets you utilize your MIDI keyboard's real sliders and
> knobs (and your sequencer's visual editors for same), rather than stuffing
> everything into an unwieldy, opaque sysex.
> 
> Want me to implement it or will you?

Go for it..no reason not to fold the unwrapping into your sequencer
though I think it may be worthwhile to keep it logically separable.

> Great ideas!

Thanks. :)  I really wouldn't have thought about them except for you
original concept.

Here's a random question for you that amplifies Jair-Rohm's query: how
deliverable is Java at this point for real-time purposes?  I'm
especially concerned about garbage collection pauses.  I know they
aren't inherent in the language.

Eric

From - Wed Sep  8 22:27:31 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA20413
	for <slinkp@ulster.net>; Wed, 8 Sep 1999 18:53:46 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA18605 for linux-audio-dev-list; Wed, 8 Sep 1999 18:12:58 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id SAA18602 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 8 Sep 1999 18:12:55 -0400
From: est@hyperreal.org
Received: (qmail 22550 invoked by uid 162); 8 Sep 1999 22:09:10 -0000
Message-ID: <19990908220910.22549.qmail@hyperreal.org>
Subject: [linux-audio-dev] python & generic audio engines
In-Reply-To: <99090817082303.00759@linuxhost.localdomain> from Benno Senoner
 at "Sep 8, 1999 04:45:28 pm"
To: Benno Senoner <sbenno@gardena.net>
Date: Wed, 8 Sep 1999 15:09:10 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 481976a75a39fa72526b0fa5c9c7ec22

Benno Senoner discourseth:
> 
> I'm not very confident that Python will be suitable for RT apps,
> especially music that require precisions in the 1-5ms range for
> stable timing + low-latency. 

It really all depends.  Python has limits, but I haven't encountered
any that are counterintuitive.  The more Python operations you perform
the more cycles you burn at that furious rate.

> I think sooner or later we should all join our efforts and contribute
> to the Audiality project (with first versions running in userspace on
> ordinary Linux kernel , then on RT-Linux with sub 1msec lanecies).
> 
> Audiality will be designed with realtime, flexibility, efficiency and
> scalabitily in mind.

David's interest in public discussion re module APIs bodes well for
this. :)

> In future, designing an audio app will be more a GUI programming task
> than re-implementing audio-engines evertime from scratch.
> 
> For example oolabola could be almost a GUI app which calls
> audiality modules and connect them together.

This has always been my ideal, though not in any audiality-specific way.

The current oolaboola is a hack to get something that works reliably,
portably, efficiently..and now.  In fact, it was a conscious, atypical
and long-considered decision to embark on such a short-term
project. :)

Eric

From - Wed Sep  8 22:27:34 1999
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA21873
	for <slinkp@ulster.net>; Wed, 8 Sep 1999 19:03:24 -0400
From: est@hyperreal.org
Received: (qmail 4270 invoked by uid 162); 8 Sep 1999 22:44:13 -0000
Message-ID: <19990908224413.4269.qmail@hyperreal.org>
Subject: Python and Scheme's linguistic niches
In-Reply-To: <37D62446.3064D3AD@ulster.net> from Paul Winkler at "Sep 8, 1999
 04:54:30 am"
To: Paul Winkler <slinkp@ulster.net>
Date: Wed, 8 Sep 1999 15:44:13 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 9f65c0b2ac82714d6949edb99e9e34a9

Paul Winkler discourseth:
> est@hyperreal.org wrote:
> > BTW, I'm working on a real-time implementation of Scheme.  It will
> > allow a lot of the easy extensibility Python provides along with the
> > speed of more of a `systems language'.
> 
> Cool idea. That might get me to finally get my lisp feet wet (so far all
> I do is wrangle my .emacs file into something that sort of does what I
> want even if I don't understand it.) 
> I hesitate to ask how you will accomplish the speed. (probably way over
> my head!)

Well, the crucial fact is pretty simple.  Python is way more
polymorphic than Scheme.  (string-ref s i) means one thing..something
that can sometimes even translate to a single machine instruction if
you don't care about safety.  s[i] in Python means one thing too, but
it's `see if s has a getitem method and, if so, invoke it on s and i'.

Eric

From - Wed Sep  8 22:27:27 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA13087
	for <slinkp@ulster.net>; Wed, 8 Sep 1999 18:02:37 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA18480 for linux-audio-dev-list; Wed, 8 Sep 1999 17:18:46 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA18477 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 8 Sep 1999 17:18:39 -0400
Received: from linuxhost.localdomain (IDENT:root@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id XAA14270;
	Wed, 8 Sep 1999 23:14:39 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id BAA01320;
	Thu, 9 Sep 1999 01:15:32 +0200
From: Benno Senoner <sbenno@gardena.net>
To: David Slomin <dgslomin@CS.Princeton.EDU>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] A Python loop sequencer, was re: using csound as a sampling engine
Date: Thu, 9 Sep 1999 01:00:30 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: David Olofson <audiality@swipnet.se>
References: <Pine.GSO.4.10.9909081522200.29057-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Message-Id: <99090901153200.01278@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f78b3f425805b640e79f63ce18e2091c

On Wed, 08 Sep 1999, David Slomin wrote:
> On Wed, 8 Sep 1999, Benno Senoner wrote:
> 
> > I think sooner or later we should all join our efforts and contribute
> > to the Audiality project (with first versions running in userspace on
> > ordinary Linux kernel , then on RT-Linux with sub 1msec lanecies).
> 
> Don't forget that there's never such a thing as "one size fits all",
> only "one size fits most" at best.  

Agreed.
> 
> I don't see myself as ever running Audiality (much less writing code that
> relies on it) because I do not like the idea of having to run RT-Linux.
> I'm a hobbiest musician, not a professional, so I'm not willing to
> dedicate a machine to the job; I only run general purpose OS's.  This
> doesn't mean I think there's no place for Audiality, but I don't think
> it's realistic to expect _all_ the Linux audio developers to target that
> single niche.

Yes, this is the main reason I stressed the kernel folks so much to
improve the userspace realtime behaviour, and in fact
Ingo did it: now we can implement much lower-lantency soft-synths
as Windoze on the same hardware, RELIABLY, with no glitches during
system load.
RT Linux is way to difficult to install for Joe average user.

Since shared-mem/IPC is pretty fast, we could implement a version of Audiality
by letting run the audiality "daemon" as normal SCHED_FIFO process,
on a a regular linux kernel (with the hope that the low-latency patches will go
into the mainstream kernel).

RT-Linux is maybe only needed by the *VERY* audio professional,
but Joe average will go with userspace engines.

If RT Linux will go into the mainstream kernel someday, then we could provide
both engines (RTLinux engine and userspace engine), to provide easy porting
to other POSIX architectures.

Since the userspace engines are almost POSIX code + some OSS/ALSA code,
it would be not too difficult to port the engine to other POSIX OSes like
Solaris, FreeBSD etc. 

(But as far I know FreeBSD still lacks of the POSIX Realtime extensions
( sched_setscheduler() are fake calls with no effect),
therefore you can't run your 4ms-latency soft-synth on this OS)

> 
> Besides, I don't think I've ever even written a program "for Linux".  I
> write for Posix or for the JVM and test/use it on Linux.  Here's a new
> poll for the day:  How many of you developers on the LAD list only target
> Linux?

I think it will be like with other projects: there is a release for the primary
OS and other groups will provide the ports.

But actually Linux is the only free OS capapable of this hardcore
realtime-audio stuff.

regards,
Benno.

From - Fri Sep 10 12:40:55 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA01173
	for <slinkp@ulster.net>; Thu, 9 Sep 1999 12:12:15 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA20151 for linux-audio-dev-list; Thu, 9 Sep 1999 11:25:37 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA20148 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 9 Sep 1999 11:25:34 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S42519AbPIIPVm>; Thu, 9 Sep 1999 18:21:42 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: audiality@swipnet.se
CC: sbenno@gardena.net, jos@w3k.org,
        linux-audio-dev@ginette.musique.umontreal.ca, pbd@op.net,
        jos@ccrma.Stanford.EDU
In-reply-to: <99090403360103.00437@localhost.localdomain> (message from David
	Olofson on Sat, 4 Sep 1999 02:19:56 +0200)
Subject: Re: [linux-audio-dev] Re: Bandlimited interpolation suitable for realtime audio
Message-Id: <19990909152146Z42519-16539+1226@nic.funet.fi>
Date:   Thu, 9 Sep 1999 18:21:42 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ee8dd717d9c788ac1ac08bec851ee6a5

Audiality wrote:
>Don't know if they're using something like that, but E-mu claims to have
>"8-point interpolation" in their newer samplers. Unfortunately, I'm afraid
>asking them how they do it wouldn't work! ;-)

Check good papers on the topic:

Dattorro, J., 1997, "Effect Design, Part 1: Reverberator and Other Filters,"
Journal of the Audio Engineering Society, Vol. 45, No. 9

Dattorro, J., 1997, "Effect Design, Part 2: Delay-line Modulation and Chorus,"
Journal of the Audio Engineering Society, Vol. 45, No. 10

I have no idea where is Part 3 but Dattorro is at Stanford...

The part 2 tells: Proteus sampling synth and its relatives all employ
seventh-order interpolation polynomials. They are not exactly "Lagrange"
though. They use a technique in which a Remez exchange is applied to an
"ideal" filter response similar to that of Lagrange, but having lower maxima
in the stopband. This gives the deep notches advantageous in the Lagrange
approach, but also the superior stopband rejection of a sinc-based
design. For more information, see the U.S. patent on the fundamental E-mu
G-chip interpolator; no. 5,111,727, David Rossum.

Check also:

T. Laakso, etc., 1996, "Splitting the Unit Delay," IEEE Signal Processing
Magazine, January 1996

This paper is very informative and lists many references.
Code is available at "http://www.hut.fi/HUT/Acoustics/fdtools.html".


JOS wrote: (hey, I sent you mail to your university address, hopefully it
reaches you sooner than later :-)

>In that case you could upsample once when loading the .wav file
>using a high-quality converter.  This would increase the load time, of course,
>which could be a problem if you want to support dynamic loading of wave files
>in response to MIDI "program select" during a musical performance.

There would be pre-upsampled files available, of course.  :)

Basically, I'm ready to do the thing the way Julius suggest. While
those papers gives other methods we could in the first place take
what is already working good enough. Distortion? I have already written
a time-varying delay line based on above mentioned papers: if I don't
hear any difference between 2-tap and 4-tap interpolation, it doesn't
matter if I use 2-tap interpolation only. (I might have made some mistage
even I verified the formulas carefully and found a mistage (or my mistage?)
in the paper.)

Yours,

Juhana

From - Fri Sep 10 12:40:57 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA03310
	for <slinkp@ulster.net>; Thu, 9 Sep 1999 12:26:02 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA20175 for linux-audio-dev-list; Thu, 9 Sep 1999 11:41:52 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA20171 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 9 Sep 1999 11:41:50 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S42494AbPIIPiJ>; Thu, 9 Sep 1999 18:38:09 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca,
        gtk-app-devel-list@redhat.com, alsa-devel@alsa-project.org
Subject: [linux-audio-dev] GASP: programming manuals
Message-Id: <19990909153809Z42494-32561+1302@nic.funet.fi>
Date:   Thu, 9 Sep 1999 18:38:09 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 4eaf9f360b32c1ebd90a1844ea226769

I'm posting this to gtk-app-devel list too because recently somebody there
asked programming manuals.

I have put a list of programming manual links to my GASP pages at
  http://www.funet.fi/~kouhia/gasp/

There are very advanced programming manuals too which I have found
very useful in realtime audio software writing. They are all freely
available which is good because at least I don't have any interest
in buying equivalent books.

Unfortunately there is no very good GTK manual available (except Havoc's
said-to-be-excellent $$ book).

Please let me know if you know other excellent manuals!

Yours,

Juhana

From - Fri Sep 10 12:40:58 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA04634
	for <slinkp@ulster.net>; Thu, 9 Sep 1999 12:34:02 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA20226 for linux-audio-dev-list; Thu, 9 Sep 1999 11:50:34 -0400
Received: from icon.labs.redhat.com (icon.labs.redhat.com [207.175.42.144]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA20223 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 9 Sep 1999 11:50:32 -0400
Received: from localhost (hp@localhost)
	by icon.labs.redhat.com (8.9.3/8.9.3) with ESMTP id LAA20096;
	Thu, 9 Sep 1999 11:44:21 -0400
X-Authentication-Warning: icon.labs.redhat.com: hp owned process doing -bs
Date: Thu, 9 Sep 1999 11:44:21 -0400 (EDT)
From: Havoc Pennington <hp@redhat.com>
X-Sender: hp@icon.labs.redhat.com
To: gtk-app-devel-list@redhat.com
cc: linux-audio-dev@ginette.musique.umontreal.ca, alsa-devel@alsa-project.org
Subject: [linux-audio-dev] Re: GASP: programming manuals
In-Reply-To: <19990909153809Z42494-32561+1302@nic.funet.fi>
Message-ID: <Pine.LNX.4.10.9909091144030.6753-100000@icon.labs.redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 58b57735f87e59b794620b111f85c981


On Thu, 9 Sep 1999, Juhana Sadeharju wrote:
> 
> Unfortunately there is no very good GTK manual available (except Havoc's
> said-to-be-excellent $$ book).
> 

It's online too, http://developer.gnome.org/doc/GGAD

Havoc


From - Fri Sep 10 12:41:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA14259
	for <slinkp@ulster.net>; Thu, 9 Sep 1999 17:39:21 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA20729 for linux-audio-dev-list; Thu, 9 Sep 1999 17:00:51 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA20726 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 9 Sep 1999 17:00:48 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id QAA26136
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 9 Sep 1999 16:55:25 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id QAA13901; Thu, 9 Sep 1999 16:55:25 -0400 (EDT)
Date: Thu, 9 Sep 1999 16:55:17 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: hybrid midi/textual sequencer & java real-time deliverability
In-Reply-To: <19990908215018.28449.qmail@hyperreal.org>
Message-ID: <Pine.GSO.4.10.9909091647140.13697-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: e553c26d496a9ddcced967e7cea0fbba

On Wed, 8 Sep 1999 est@hyperreal.org wrote:

> > Want me to implement it or will you?
> 
> Go for it..no reason not to fold the unwrapping into your sequencer
> though I think it may be worthwhile to keep it logically separable.

Yes, I'll definitely keep it separate.
 
> Here's a random question for you that amplifies Jair-Rohm's query: how
> deliverable is Java at this point for real-time purposes?  I'm
> especially concerned about garbage collection pauses.  I know they
> aren't inherent in the language.

I'm not yet doing any realtime I/O in the sequencer, so I haven't been
able to test the performance yet.  When the time comes, I plan to do as
much as possible of the realtime stuff in C via JNI.  At that point, the
latency issues will be on a par with any C program.

My prior experience with JVM's has been that they _never_ garbage collect
until they actually run out of memory.  I don't know if this is still the
case; I know that the garbage collection process is usually a major point
of concern in garbage collected languages like Lisp.  However, Java has
managed to squeak by in this because most Java programs (and especially
applets) are small and short-lived, so they tend not to run out of memory
during their lifespan.

Div.

From - Fri Sep 10 12:41:10 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA01721
	for <slinkp@ulster.net>; Thu, 9 Sep 1999 19:50:34 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA20935 for linux-audio-dev-list; Thu, 9 Sep 1999 19:10:44 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id TAA20932 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 9 Sep 1999 19:10:38 -0400
From: est@hyperreal.org
Received: (qmail 21426 invoked by uid 162); 9 Sep 1999 22:57:09 -0000
Message-ID: <19990909225709.21425.qmail@hyperreal.org>
Subject: [linux-audio-dev] java real-time deliverability
In-Reply-To: <Pine.GSO.4.10.9909091647140.13697-100000@ux02.CS.Princeton.EDU>
 from David Slomin at "Sep 9, 1999 04:55:17 pm"
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Thu, 9 Sep 1999 15:57:09 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 15cda6f4b086ca6e8ed34ca7f2816ecf

David Slomin discourseth:
> On Wed, 8 Sep 1999 est@hyperreal.org wrote:
>  
> > Here's a random question for you that amplifies Jair-Rohm's query: how
> > deliverable is Java at this point for real-time purposes?  I'm
> > especially concerned about garbage collection pauses.  I know they
> > aren't inherent in the language.
> 
> I'm not yet doing any realtime I/O in the sequencer, so I haven't been
> able to test the performance yet.  When the time comes, I plan to do as
> much as possible of the realtime stuff in C via JNI.

Hmm..that may not be necessary actually, but I'm sure you'll find
out. :)

> At that point, the
> latency issues will be on a par with any C program.

I've looked into this a bit since I last posted about it, and it seems
that when you allocate an object, you are not guaranteed any sort of
bounded pause.  Even Sun's HotSpot, though it has an `incremental'
collector, does not bound gc pauses.

> My prior experience with JVM's has been that they _never_ garbage collect
> until they actually run out of memory.

It's not true anymore, but even if it were, is that something you can
dependably code to for an application used in performance situations?

> I don't know if this is still the
> case; I know that the garbage collection process is usually a major point
> of concern in garbage collected languages like Lisp.  However, Java has
> managed to squeak by in this because most Java programs (and especially
> applets) are small and short-lived, so they tend not to run out of memory
> during their lifespan.

Well, you can be very imperative in Java.  You can simply not allocate
during performance periods.

Eric

From - Fri Sep 10 12:41:17 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA14185
	for <slinkp@ulster.net>; Fri, 10 Sep 1999 01:24:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA21269 for linux-audio-dev-list; Fri, 10 Sep 1999 00:46:55 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA21266 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 10 Sep 1999 00:46:52 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id AAA02727
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 10 Sep 1999 00:41:41 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id AAA22602; Fri, 10 Sep 1999 00:41:39 -0400 (EDT)
Date: Fri, 10 Sep 1999 00:41:37 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Project status, etc.
Message-ID: <Pine.GSO.4.10.9909100026450.22361-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 13b72a227b2c2430aedc577573463a99


In case you're curious, I've been working on the adapter program that lets
Csound be controlled via MIDI messages in realtime (but with full control
over intrument parameters, unlike with Csound's own MIDI support).

To do so, I had to get the MIDI hardware on my system working again,
something I hadn't gotten around to doing since simultaneously adding an
AWE64 to the system and upgrading to Red Hat 6.  Suffice it to say that
I now know a lot more about the ISA-Pnp tools than I did before, but
both the AWE64 and my MPU401 now play happily together under OpenSound.

I did notice an interesting thing though... copying directly from
/dev/midi02 (the MPU401) to /dev/midi01 (the AWE64's wavetable) didn't
work with messages generated from my Yamaha SY22 synth/keyboard.  It
did work fine when piped through any of my MIDI toys filters.  Some
experimentation exposed the reason for this... the AWE64 can't comprehend
running status bytes (which the SY22 generates but my filters expand
to normal repeated status bytes).

In short, could it be true that the best-selling sound card and thus
probably the single most common MIDI synth today doesn't actually support
such a simple, common, fundamental part of the MIDI standard?!  Agh!

Now that this is resolved, onwards to the Csound adapter, but I probably
won't have that for you folks until Monday (simple though it is), since
I'll be away for the holiday this weekend.  Shanah tovah (happy new year)
to all of you who are observing it!

Div.

From - Fri Sep 10 12:41:18 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA14913
	for <slinkp@ulster.net>; Fri, 10 Sep 1999 01:34:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA21283 for linux-audio-dev-list; Fri, 10 Sep 1999 00:58:51 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA21280 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 10 Sep 1999 00:58:49 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id AAA03514
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 10 Sep 1999 00:53:36 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id AAA22785; Fri, 10 Sep 1999 00:53:35 -0400 (EDT)
Date: Fri, 10 Sep 1999 00:53:33 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] java real-time deliverability
In-Reply-To: <19990909225709.21425.qmail@hyperreal.org>
Message-ID: <Pine.GSO.4.10.9909100043250.22361-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b221f21cbc93afa9d1afa555608ffa25

On Thu, 9 Sep 1999 est@hyperreal.org wrote:

> David Slomin discourseth:
> 
> > My prior experience with JVM's has been that they _never_ garbage collect
> > until they actually run out of memory.
> 
> It's not true anymore, but even if it were, is that something you can
> dependably code to for an application used in performance situations?
> 
> > I don't know if this is still the
> > case; I know that the garbage collection process is usually a major point
> > of concern in garbage collected languages like Lisp.  However, Java has
> > managed to squeak by in this because most Java programs (and especially
> > applets) are small and short-lived, so they tend not to run out of memory
> > during their lifespan.
> 
> Well, you can be very imperative in Java.  You can simply not allocate
> during performance periods.

That's half the solution; the other half is to manually call the garbage
collector before entering each performance period.  You can do this with
java.lang.Runtime.gc().  It doesn't return until the garbage collecting is
finished, so you don't have to worry about it being nasty in the
background.  You can also monitor how close you are getting to the next
out of memory triggered garbage collection point by calling
java.lang.Runtime.freeMemory().

With functions like these, a lazy garbage collector (doesn't collect until
out of memory) is actually preferable to a more aggressive one, since it
leaves you free to control it in the aforesaid manner.  So much for the
modern "improvement".

Div.

From - Fri Sep 10 12:41:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA16150
	for <slinkp@ulster.net>; Fri, 10 Sep 1999 09:45:02 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA22066 for linux-audio-dev-list; Fri, 10 Sep 1999 08:55:43 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA22063 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 10 Sep 1999 08:55:40 -0400
Received: from bright.net (find-cas1-cs-19.dial.bright.net [209.143.26.122])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id IAA08816;
	Fri, 10 Sep 1999 08:52:09 -0400 (EDT)
Message-ID: <37D9055B.91EC9D47@bright.net>
Date: Fri, 10 Sep 1999 09:19:23 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Kwave
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 30080326777c2f1e0bad8e1dc4370585

Greetings:

  I've been corresponding with Martin Wilz and we've been discussing the
fate of his Kwave soundfile editor. For those who don't know about it,
the homepage is located here:

	http://fs.spinfo.uni-koeln.de/~kwave/

  Its GUI is based on Qt and requires some of the KDE development
packages. It is an open-source project. Although only at version 0.29.7
it is already a pretty nice editor, but Martin is currently unable to
continue its development. He would be happy to hear from anyone who
might like to carry on the project, so if you haven't got anything else
to do, contact Martin at mwilz@ernie.MI.Uni-Koeln.DE and tell him I sent
you...

== Dave Phillips

"There's a whole lots of people talking, but there's a mighty few people
that know..." (Sonny Boy Williamson)

From - Mon Sep 13 02:09:16 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA11216
	for <slinkp@ulster.net>; Sat, 11 Sep 1999 14:21:22 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA28116 for linux-audio-dev-list; Sat, 11 Sep 1999 11:54:06 -0400
Received: from chiara.csoma.elte.hu ([157.181.71.18]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA28108 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 11 Sep 1999 11:44:43 -0400
From: mingo@chiara.csoma.elte.hu
Received: (from mingo@localhost)
	by chiara.csoma.elte.hu (8.8.8/8.8.8/c) id RAA22553;
	Sat, 11 Sep 1999 17:40:10 +0200
Date: Sat, 11 Sep 1999 17:46:01 +0200 (CEST)
To: Benno Senoner <sbenno@gardena.net>
cc: Paul Barton-Davis <pbd@op.net>, sct@redhat.com, est@hyperreal.org,
        andrea@suse.de, rtl@rtlinux.cs.nmt.edu, alsa-devel@alsa-project.org,
        David Olofson <audiality@swipnet.se>, yodaiken@fsmlabs.com,
        linux-kernel@vger.rutgers.edu,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>,
        Roger Larsson <nra02596@norran.net>, linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: low-latency benchmarks: excellent results of RTC clock + SIGIO
 notification, audio-latency now down to 2.1ms!
In-Reply-To: <99091119242901.00756@linuxhost.localdomain>
Message-ID: <Pine.LNX.4.10.9909111741080.3430-100000@chiara.csoma.elte.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 7432b14f64111085398c3da6a86f9ba8


On Sat, 11 Sep 1999, Benno Senoner wrote:

> Seems that under high disk I/O load,
> (very seldom, about every 30-100secs) the process
> gets woken up one IRQ period later.
> Ideas why this happens.

this could be a lost RTC IRQ. If you are using 2048 Hz RTC interrupts, it
just needs a single 1msec IRQ delay to lose an RTC IRQ. Especially SCSI
disk interrupts are known to sometimes cause 1-2 millisecs IRQ delays.  
But before jumping to conclusions, what exactly are the symptoms, what
does 'one IRQ period later' mean exactly?

-- mingo

From - Mon Sep 13 02:09:17 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA11223
	for <slinkp@ulster.net>; Sat, 11 Sep 1999 14:21:23 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA28104 for linux-audio-dev-list; Sat, 11 Sep 1999 11:37:55 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA28095 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 11 Sep 1999 11:28:31 -0400
Received: from linuxhost.localdomain (IDENT:root@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id RAA29738;
	Sat, 11 Sep 1999 17:23:50 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id TAA00941;
	Sat, 11 Sep 1999 19:24:29 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Paul Barton-Davis <pbd@op.net>, sct@redhat.com,
        Ingo Molnar <mingo@chiara.csoma.elte.hu>, est@hyperreal.org,
        andrea@suse.de
Subject: [linux-audio-dev] low-latency benchmarks: excellent results of RTC clock + SIGIO notification, audio-latency now down to 2.1ms!
Date: Sat, 11 Sep 1999 18:58:12 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: rtl@rtlinux.cs.nmt.edu, alsa-devel@alsa-project.org,
        David Olofson <audiality@swipnet.se>, yodaiken@fsmlabs.com,
        linux-kernel@vger.rutgers.edu,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>,
        Roger Larsson <nra02596@norran.net>, linux-sound@vger.rutgers.edu
MIME-Version: 1.0
Message-Id: <99091119242901.00756@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 2eaec9cd1c0cbaadab16d4ca1ddf3ad5

Hi,
good news folks:

Paul Barton Davis added async notification via SIGIO to the RTC device,
and I enhanced "latencytest" (you can get the latest version from my page) to
measure timedifferences between two SIGIO calls, All benchmarks performed using
Mingo's low-latency patch (without his patch timing sucks)
The results are very good,
In my example I used an RTC frequency of 2048HZ, and the maximum jitter was
about 500usecs (very sporadic , shows up every 60-100secs).

look at the the results:
CPU load=80%
http://www.gardena.net/benno/linux/audio/rtc2048-cpu80/2048.html

CPU load=10%
http://www.gardena.net/benno/linux/audio/rtc2048-cpu10/2048.html

A typical use could be an app which needs 1ms timing precision
( MIDI sequencer for example).


I have more good news,  On my audio benchmarks I was able to
reduce the audio buffer size from 4.3ms to ONLY 2.1ms ( 3x0.7ms buffers) ! ,
without losing reliability ,in this case the max jitter is about  0.7ms  in the
range of the fragment-time.

look at the results:
CPU load=80%
http://www.gardena.net/benno/linux/audio/audio3x128-cpu80/3x128.html

CPU load=10%
http://www.gardena.net/benno/linux/audio/audio3x128-cpu10/3x128.html

It's interesting that If I use 4.3ms = 3x1.45ms buffers, the max jitter (again
very sporadic) is about 1.5ms , the time it takes to play one fragment.  

Seems that under high disk I/O load,
(very seldom, about every 30-100secs) the process
gets woken up one IRQ period later.
Ideas why this happens.

The trick to deliver rock-solid audio seems to use 3 buffer, so that you can
have about 33% headroom.

Seems that we are now able to outperform most of the other OSes in terms of 
timing precision/ latency ( multimedia loves this)
:-)

In future, we will probably not need RT-Linux to deliver realtime audio
on Linux. (As processors get faster , jitter will go down)

comments ?

regards,
Benno.


---
Benno Senoner
E-Mail: sbenno@gardena.net
Linux low latency audio / scheduling latency benchmarks
http://www.gardena.net/benno/linux/audio

From - Mon Sep 13 02:09:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA11248
	for <slinkp@ulster.net>; Sat, 11 Sep 1999 14:21:28 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA28148 for linux-audio-dev-list; Sat, 11 Sep 1999 12:09:21 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA28119 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 11 Sep 1999 11:59:57 -0400
Received: from linuxhost.localdomain (IDENT:root@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id RAA30162;
	Sat, 11 Sep 1999 17:55:30 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id TAA00972;
	Sat, 11 Sep 1999 19:56:17 +0200
From: Benno Senoner <sbenno@gardena.net>
To: mingo@chiara.csoma.elte.hu
Subject: [linux-audio-dev] Re: low-latency benchmarks: excellent results of RTC clock + SIGIO notification, audio-latency now down to 2.1ms!
Date: Sat, 11 Sep 1999 19:41:50 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: Paul Barton-Davis <pbd@op.net>, sct@redhat.com, est@hyperreal.org,
        andrea@suse.de, rtl@rtlinux.cs.nmt.edu, alsa-devel@alsa-project.org,
        David Olofson <audiality@swipnet.se>, yodaiken@fsmlabs.com,
        linux-kernel@vger.rutgers.edu,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>,
        Roger Larsson <nra02596@norran.net>, linux-sound@vger.rutgers.edu
References: <Pine.LNX.4.10.9909111741080.3430-100000@chiara.csoma.elte.hu>
MIME-Version: 1.0
Message-Id: <99091119561702.00756@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 964217db1d9334631e8b88eef9b4dbb6

On Sat, 11 Sep 1999, mingo@chiara.csoma.elte.hu wrote:
> On Sat, 11 Sep 1999, Benno Senoner wrote:
> 
> > Seems that under high disk I/O load,
> > (very seldom, about every 30-100secs) the process
> > gets woken up one IRQ period later.
> > Ideas why this happens.
> 
> this could be a lost RTC IRQ. If you are using 2048 Hz RTC interrupts, it
> just needs a single 1msec IRQ delay to lose an RTC IRQ. Especially SCSI
> disk interrupts are known to sometimes cause 1-2 millisecs IRQ delays.  
> But before jumping to conclusions, what exactly are the symptoms, what
> does 'one IRQ period later' mean exactly?
> 
> -- mingo

The RTC benchmark measures the time between 2 calls to the SIGIO handler.
In my example RTC freq=2048HZ I used 0.48ms periods, and the max jitter
is exactly 2 * 0.48ms = 0.96ms.

The same thing happens on the audio card:

If I use 1.45ms audio fragments, then max delay between two write() calls is
2.9ms ( 2 * 1.45ms)

When I reduce the fragmentsize to 0.7ms , the max registered peak was 1.4ms =
2 * 0.7ms.

Maybe in the audio case, the same phenomen  of "lost IRQ" happens,

But it's interesting that the jitter depends on the IRQ frequency.
(maybe only for very low-latencies)

look at the diagrams , you can see very clearly that the peaks are a multiple 
of the IRQ period.

Maybe on lower IRQ frequencies ( intervals > 5-10ms ), these peaks will
not show up , because that there are  no losses of IRQs ?

But if my HD is blocking the IRQs for max 0.7ms using 0.7ms IRQ period,
why should it block for max 1.45ms by using  1.45ms IRQ periods ?

regards,
Benno.

From - Mon Sep 13 02:09:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA16038
	for <slinkp@ulster.net>; Sun, 12 Sep 1999 17:29:23 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA00277 for linux-audio-dev-list; Sun, 12 Sep 1999 16:49:01 -0400
Received: from sculpcave.localdomain (cvx-1-68.dyn.nic.fi [62.236.97.68]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA00274 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 12 Sep 1999 16:48:56 -0400
Received: from localhost (IDENT:root@localhost [127.0.0.1])
	by sculpcave.localdomain (8.9.3/8.9.3) with ESMTP id WAA12545;
	Sun, 12 Sep 1999 22:53:46 +0300
Date: Sun, 12 Sep 1999 22:53:46 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
X-Sender: root@sculpcave.localdomain
To: Dave Phillips <dlphilp@bright.net>
cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Kwave
In-Reply-To: <37D9055B.91EC9D47@bright.net>
Message-ID: <Pine.LNX.4.10.9909122152260.13205-100000@sculpcave.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f92629d23c10e23adcce25d6a107a429

On Fri, 10 Sep 1999, Dave Phillips wrote:

>   Its GUI is based on Qt and requires some of the KDE development
> packages. It is an open-source project. Although only at version 0.29.7
> it is already a pretty nice editor, but Martin is currently unable to
> continue its development. He would be happy to hear from anyone who
> might like to carry on the project, so if you haven't got anything
> else

I haven't had time to test kwave yet (I remember having some problems
compiling it), so could someone brief me on these:

- Does it load the sample data into memory (in otherwords; does
  it support _large_ files)?
- Are the basic UI-features (marking, copy, cut, paste, etc) working? 

I don't have the time to take over this project, but I wish I could.
The lack of a usable open-source audio editor is really 
slowing down my other projects. Ecasound is already quite usable 
for multitrack recording and mixing, but without audiofile editing
it's hard to do any real work with it.

I've tried a lot of editors recently, but none of them really 
suits my needs. Snd is very good for viewing&analyzing waveforms
and it's currently the default external editor in ecasound. But 
for audio editing, it's quite difficult and clumsy to use.

TAON looks goods, but I've had a lot of problems with it 
(crashes when loading big files, doesn't take file names
from the command line, gtk/gui freezes). If it was open-source,
I could have tried to fix these... oh well, I understand that they
don't want to release the sources. Still, I hope they will eventually
change their minds. 

Ideally, we could have a Linux version of SoundForge. WaveForge
project looks interesting, but still needs a lot of work to be useful.
Anyway, SoundForge is one of best GUI applications I've ever used. 
Things that I like the most:

	- handles large files with ease
	- very intuitive user interface
	- versatile cut&copy&paste and region marking

I've thought about writing a new Qt-based editor, which would
use libecasound.so for file-I/O and effects. It should be quite
easy to make a basic editor (with features mentioned above), but
hopefully I don't need to do it. I'm no expert GUI programmer,
so although this editor would do the job, it would a crude one. ;)

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav
 . http://www.wakkanet.fi/kerttulin_listat/ - music&movies (in Finnish)

From - Mon Sep 13 02:09:40 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA19713
	for <slinkp@ulster.net>; Sun, 12 Sep 1999 18:05:27 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA00348 for linux-audio-dev-list; Sun, 12 Sep 1999 17:24:38 -0400
Received: from proxy3.ba.best.com (proxy3.ba.best.com [206.184.139.14]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA00345 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 12 Sep 1999 17:24:35 -0400
Received: from julius (dynamic1.pm01.mv.best.com [209.24.240.1])
	by proxy3.ba.best.com (8.9.3/8.9.2/best.out) with SMTP id OAA09383;
	Sun, 12 Sep 1999 14:18:16 -0700 (PDT)
Message-Id: <199909122118.OAA09383@proxy3.ba.best.com>
X-Sender: julius@shell16.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Sun, 12 Sep 1999 13:34:43 -0700
To: Juhana Sadeharju <kouhia@nic.funet.fi>
From: Julius Smith <jos@w3k.org>
Subject: Re: [linux-audio-dev] Re: Bandlimited interpolation suitable
  for realtime audio
Cc: audiality@swipnet.se, sbenno@gardena.net,
        linux-audio-dev@ginette.musique.umontreal.ca, pbd@op.net,
        jos@ccrma.Stanford.EDU
In-Reply-To: <19990909152146Z42519-16539+1226@nic.funet.fi>
References: <99090403360103.00437@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA19713
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f87950698d8e5e2ca96fb7496db773ce

At 06:21 PM 9/9/99 +0300, Juhana Sadeharju wrote:
>Audiality wrote:
>>Don't know if they're using something like that, but E-mu claims to have
>>"8-point interpolation" in their newer samplers. Unfortunately, I'm afraid
>>asking them how they do it wouldn't work! ;-)
>
>Check good papers on the topic:
>
>Dattorro, J., 1997, "Effect Design, Part 1: Reverberator and Other Filters,"
>Journal of the Audio Engineering Society, Vol. 45, No. 9
>
>Dattorro, J., 1997, "Effect Design, Part 2: Delay-line Modulation and Chorus,"
>Journal of the Audio Engineering Society, Vol. 45, No. 10
>
>I have no idea where is Part 3 but Dattorro is at Stanford...

Part 3 was never published due to the objections of a former employer of Jon's.

>The part 2 tells: Proteus sampling synth and its relatives all employ
>seventh-order interpolation polynomials. They are not exactly "Lagrange"
>though. They use a technique in which a Remez exchange is applied to an
>"ideal" filter response similar to that of Lagrange, but having lower maxima
>in the stopband. This gives the deep notches advantageous in the Lagrange
>approach, but also the superior stopband rejection of a sinc-based
>design. For more information, see the U.S. patent on the fundamental E-mu
>G-chip interpolator; no. 5,111,727, David Rossum.

Yes, this is a nice filter-design method for use in the general bandlimited-interpolation context (which Emu has done for many years).  The "neat new idea" here is forcing notches at all multiples of the original sampling rate.  Since most audio energy is concentrated at relatively low frequencies, which translates to being concentrated at all multiples of the sampling rate, notches there are a nice improvement over classical lowpass designs.  However, such a design is not optimal.  The "right thing" here (if you are into total optimality), is to shape the filter stopband according to the inverse of the average spectral envelope.  This level of optimality can be pursued in the context of "constrained convex optimization":

@INPROCEEDINGS{PutnamAndSmithMohonk97,
	AUTHOR = "William Putnam and Julius O. Smith",
	TITLE = "Design of Fractional Delay filters Using Convex Optimization",
	BOOKTITLE = "\Proc\ IEEE Workshop on \Appl\ Signal Processing 
			to Audio and Acoustics, New Paltz, NY",
	PUBLISHER = "{IEEE} Press",
	ADDRESS = "New York",
	MONTH = "Oct.",
	YEAR = 1997
}

(A copy of this paper may be on the Stanford Music 421 website under "handouts".)

In addition to providing better filters than the Emu approach, it may dodge their patent in this area.  (I have not seen it, so I don't know how general the claims are.)

>Check also:
>
>T. Laakso, etc., 1996, "Splitting the Unit Delay," IEEE Signal Processing
>Magazine, January 1996

Yes, this is THE classic paper on interpolation. However, be prepared for "heavy on the math".

>>In that case you could upsample once when loading the .wav file
>>using a high-quality converter.  This would increase the load time, of course,
>>which could be a problem if you want to support dynamic loading of wave files
>>in response to MIDI "program select" during a musical performance.
>
>There would be pre-upsampled files available, of course.  :)

I was under the impression Benno wanted to support any standard wave files provided by the user.   After all, that's what "sampling synthesis" is all about.  Yes, obviously any .wav files which are provided with the system will of course be resampled in advance to whatever is rate is best for the system.  

Note that the ideal rate depends on the signal contained (how many harmonics), so ideally the .wav file should be able to be at any rate.  The playback engine takes the rate into account when computing the base step-size through the table.  After loading the .wav file into memory and computing the base step size in samples from the file's rate and the current system output sampling rate (usually 44 kHz, but 22 kHz and others should be supported as well), the base step-size is scaled according to pitch-shift amount, irrespective of the table's native sampling rate.  Thus, supporting any file sampling rate with any output sampling rate should have no effect on the "inner loop" of the playback engine.  Therefore, it's basically "free".

> If I don't hear any difference between 2-tap and 4-tap interpolation, it doesn't
>matter if I use 2-tap interpolation only.

There you go.  Good for you.  To check for bugs, listen also to worse and better interpolators, and on a variety of signals.  A good "screw-case" signal is the impulse train.  It has harmonics all the way out to the Nyquist limit, so any aliasing is highly audible.  To make the test even more "acidic", work at low output sampling rates such as 8KHz.  At that rate, you should be able to hear a progression of improvement with increasing filter order.  To be really rigorous, you should predict the amount of aliasing you expect from the filtering characteristics, and check in Cool Edit or something to see that you're where you should be, but this is probably not necessary.  After you are pretty sure there are no bugs, go back to 44 kHz and listen to a variety of "reasonably likely signals".  Perhaps the closest thing to a "screw case" in the real world is "virtual analog" synth sounds, such as a sawtooth waveform or pulse train (with the pulse width set to minimum), and with the VCF (lowpass filter) opened up to maximum.  In the acoustic world, brasses are among the brightest signals on the planet (loud note, recorded along the horn axis).

Julius


From - Mon Sep 13 02:09:43 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA21249
	for <slinkp@ulster.net>; Sun, 12 Sep 1999 18:19:19 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA00371 for linux-audio-dev-list; Sun, 12 Sep 1999 17:39:54 -0400
Received: from proxy3.ba.best.com (proxy3.ba.best.com [206.184.139.14]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA00368 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 12 Sep 1999 17:39:51 -0400
Received: from julius (dynamic1.pm01.mv.best.com [209.24.240.1])
	by proxy3.ba.best.com (8.9.3/8.9.2/best.out) with SMTP id OAA28237;
	Sun, 12 Sep 1999 14:35:38 -0700 (PDT)
Message-Id: <199909122135.OAA28237@proxy3.ba.best.com>
X-Sender: julius@shell16.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Sun, 12 Sep 1999 14:32:04 -0700
To: audiality@swipnet.se, sbenno@gardena.net,
        linux-audio-dev@ginette.musique.umontreal.ca, pbd@op.net,
        jos@ccrma.Stanford.EDU
From: Julius Smith <jos@w3k.org>
Subject: Re: [linux-audio-dev] Re: Bandlimited interpolation suitable 
  for realtime audio
In-Reply-To: <199909122118.OAA09383@proxy3.ba.best.com>
References: <19990909152146Z42519-16539+1226@nic.funet.fi>
 <99090403360103.00437@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 35832dc65f9cf4fb329b7ef4436de1d2

If anyone knows how to reach 

	Juhana Sadeharju <kouhia@nic.funet.fi>

please forward this email (and my previous message).  I cannot reach him at the above address.

Thanks,
Julius

To: <jos@w3k.org>
Subject: Returned mail: User unknown

The original message was received at Sun, 12 Sep 1999 14:18:11 -0700 (PDT)
from dynamic1.pm01.mv.best.com [209.24.240.1]

   ----- The following addresses had permanent fatal errors -----
<kouhia@nic.funet.fi>

   ----- Transcript of session follows -----
... while talking to nic.funet.fi.:
>>> RCPT To:<kouhia@nic.funet.fi>
<<< 553 5.7.1 Policy analysis reported: Open relay - see http://www.orbs.org/verify.cgi?address=206.184.139.14
550 <kouhia@nic.funet.fi>... User unknown
Reporting-MTA: dns; proxy3.ba.best.com
Arrival-Date: Sun, 12 Sep 1999 14:18:11 -0700 (PDT)

Final-Recipient: RFC822; kouhia@nic.funet.fi
Action: failed
Status: 5.1.1
Remote-MTA: DNS; nic.funet.fi
Diagnostic-Code: SMTP; 553 5.7.1 Policy analysis reported: Open relay - see http://www.orbs.org/verify.cgi?address=206.184.139.14
Last-Attempt-Date: Sun, 12 Sep 1999 14:20:37 -0700 (PDT)
Return-Path: <jos@w3k.org>
Received: from julius (dynamic1.pm01.mv.best.com [209.24.240.1])
	by proxy3.ba.best.com (8.9.3/8.9.2/best.out) with SMTP id OAA08606;
	Sun, 12 Sep 1999 14:18:11 -0700 (PDT)
Message-Id: <199909122118.OAA08606@proxy3.ba.best.com>
X-Sender: julius@shell16.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Sun, 12 Sep 1999 12:31:51 -0700
To: Juhana Sadeharju <kouhia@nic.funet.fi>
From: Julius Smith <jos@w3k.org>
Subject: Re: Game audio engines?
Cc: jos@ccrma.stanford.edu
In-Reply-To: <19990908155214Z42336-16539+1132@nic.funet.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 06:52 PM 9/8/99 +0300, Juhana Sadeharju wrote:
>Hello. You mentioned you have helped game people by writing audio engines
>for games. Would you please tell me if those softwares are freely available
>with a source code?

Yes, indirectly.  I was an initial co-developer of SynthBuilder which
is being used to develop game sounds at Staccato Systems (http://www.StaccatoSys.com).  The only free version is for NeXT computers, available from the CCRMA website.  Source code is provided in principle in that unit-generator source is provided (in DSP assembly language format), and the block diagram shows you how they are threaded together.

>I'm writing an audio engine too (having pretty much the same plans than
>the David (Audiality) except I'm staying in Posix RT processes instead
>of going to kernel level) and would greatly like to have a more or less
>detailed summary of a game audio engine. If possible would you please
>tell me details of your audio engines?

I'm afraid I have close to zero personal experience with audio for games.
My focus has been on musical instruments and general tools.
Others have used the general tools for game sounds.

Cheers,
Julius

From - Mon Sep 13 05:33:40 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id FAA13966
	for <slinkp@ulster.net>; Mon, 13 Sep 1999 05:42:28 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA01232 for linux-audio-dev-list; Mon, 13 Sep 1999 05:00:41 -0400
Received: from qhars001.nortel.com (qhars001.NortelNetworks.com [192.100.101.18]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA01229 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 13 Sep 1999 05:00:35 -0400
Received: from zhard00d.europe.nortel.com (actually zhard00d) 
          by qhars001.nortel.com; Mon, 13 Sep 1999 09:55:13 +0100
Received: from zadcd002.europe.nortel.com ([47.217.51.232]) 
          by zhard00d.europe.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id SKQY906P; Mon, 13 Sep 1999 09:55:13 +0100
Received: from europem01.nt.com (mjbas32.europe.nortel.com [136.147.65.155]) 
          by zadcd002.europe.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id SBH8W7K5; Mon, 13 Sep 1999 10:55:11 +0200
Message-ID: <37DCBBF4.B8B514C3@europem01.nt.com>
Date: Mon, 13 Sep 1999 10:55:16 +0200
From: "Eric Brunel" <brunel@nortelnetworks.com>
Organization: Nortel
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: fr, en
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Problem with Multitrack
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 5f28543fc2c0e26aafde1d7667dbf82c

Hi everybody,

My question may be quite off topic, but does anybody know how to contact
Boris Nagels, writer of the "Multitrack" direct-to-disk recorder? I have
quite a big problem with it (it won't record anything since the
installation of the latest OSS driver), his former email address
(boris@molphys.leidenuniv.nl) does not work anymore, and the Multitrack
home page @
http://rulhmpc38.leidenuniv.nl/private/multitrack/multitrack.html has
been unavailable for more than a week now...

Just in case anybody has a workaround for the problem, I describe it
here: I installed version 3.9 of the OSS commercial driver and since
then, every time I try to record something, Multitrack exits with the
message "Child exited signal recieved". Every other function seems to
work fine, including playback and vu-meter. The version of Multitrack I
use is 2.2, on a RedHat 5.1 commercial distribution, kernel v2.0.35 (I
think...).

Thanks a lot for what you can do.
--
 - Eric Brunel - email brunel@nortelnetworks.com -

From - Mon Sep 13 16:47:47 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA18834
	for <slinkp@ulster.net>; Mon, 13 Sep 1999 07:12:43 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA01376 for linux-audio-dev-list; Mon, 13 Sep 1999 06:14:55 -0400
Received: from upf.es (newton.upf.es [193.145.54.60]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA01373 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 13 Sep 1999 06:14:34 -0400
Received: from mtg150.upf.es (mtg150.upf.es [193.145.44.150])
	by upf.es (8.9.0/8.9.0) with SMTP id MAA20208;
	Mon, 13 Sep 1999 12:09:00 +0200 (MET DST)
From: Maarten de Boer <maarten.deboer@iua.upf.es>
To: brunel@nortelnetworks.com, linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Problem with Multitrack
Date: Mon, 13 Sep 1999 12:15:12 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <37DCBBF4.B8B514C3@europem01.nt.com>
MIME-Version: 1.0
Message-Id: <99091312161203.08077@mtg150.upf.es>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 8c8f13421397db6f5021dddf7e196853

On Mon, 13 Sep 1999, brunel@nortelnetworks.com wrote:
> My question may be quite off topic, but does anybody know how to contact
> Boris Nagels, writer of the "Multitrack" direct-to-disk recorder? I have

Hi, 

a friend of mine knows somebody how knew him, so maybe he can track him
down. I will tell you when I know more

Maarten


From - Mon Sep 13 16:47:49 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA31703
	for <slinkp@ulster.net>; Mon, 13 Sep 1999 09:18:55 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA01560 for linux-audio-dev-list; Mon, 13 Sep 1999 08:31:35 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA01557 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 13 Sep 1999 08:31:32 -0400
Received: from bright.net (find-cas1-cs-7.dial.bright.net [209.143.26.110])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id IAA25514;
	Mon, 13 Sep 1999 08:27:54 -0400 (EDT)
Message-ID: <37DCF24C.226ECD83@bright.net>
Date: Mon, 13 Sep 1999 08:47:08 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Brunel <brunel@nortelnetworks.com>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Problem with Multitrack
References: <37DCBBF4.B8B514C3@europem01.nt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0b3ab8bd1bd70eb23bffa3a1d58db412

Eric Brunel wrote:

> ...I installed version 3.9 of the OSS commercial driver and since
> then, every time I try to record something, Multitrack exits with the
> message "Child exited signal recieved". Every other function seems to
> work fine, including playback and vu-meter. The version of Multitrack I
> use is 2.2, on a RedHat 5.1 commercial distribution, kernel v2.0.35 (I
> think...).

I'm somewhat astonished you got it working under that system. I use RH
5.2 and can't get Multitrack working under either X or SVGA.

Anyway, I have been in contact with Boris Nagels. Our last
correspondence took place in July, at which time he said he was leaving
for a 2-week vacation. I've written to him twice since his due-back
date, but I've received no response yet. I suppose he's just as busy as
the rest of us.

I will write to him again today. Many people would like to know what's
going on with Multitrack. It should probably be a FAQ...

I will place any relevant messages on the list as soon as I know more
about what he intends to do with his software.

And if anyone can tell me how to make it work under RH 5.2 glibc, please
tell me...

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Mon Sep 13 22:07:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA20745
	for <slinkp@ulster.net>; Mon, 13 Sep 1999 22:08:55 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA02916 for linux-audio-dev-list; Mon, 13 Sep 1999 21:23:22 -0400
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id VAA02913 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 13 Sep 1999 21:23:19 -0400
Message-Id: <199909140123.VAA02913@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Re: [alsa-devel] Proposal: low-latency real-time audio processing documentation
To: alsa-devel@alsa-project.org
Date: Mon, 13 Sep 1999 21:19:13 -0400 (EDT)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
In-Reply-To: <99091017240001.00762@mtg150.upf.es> from "Maarten de Boer" at Sep 10, 99 05:12:25 pm
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 4d65221349233426ef274ce8231f66bf

Maarten de Boer wrote:
> I think that it would be a good idea if we try to put a bit of
> structure into all this and try to collect all this information
> on a webpage. It will be difficult to keep it up to date, since
> progress seems to be made very quickly, but I think we should be
> carefull that the experiences gathered don't become scattered, and
> the alternative - browsing the mailing-list archive - does not
> seem right to me.
> 
> I would be willing to take coordination of this, since low-latency
> real-time audio processing is vital for the project I am partici-
> pating in, but I am a bit short of time, so I would appreciate
> your cooperation. Starting with a request for comments. 

Sounds useful.  I can collect and htmlize information, though I can't
commit to keeping it up to date afterwards.

Tangent: would there be enough traffic for a linux-realtime list?
This stuff is not technically on topic on alsa-devel; I guess it is on
linux-audio-dev, but there ought to be non-audio interest in RT too.

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Tue Sep 14 10:43:22 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA10740
	for <slinkp@ulster.net>; Tue, 14 Sep 1999 01:32:49 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA03189 for linux-audio-dev-list; Tue, 14 Sep 1999 00:49:15 -0400
Received: from zhora.replicant.apana.org.au (replicant.apana.org.au [203.12.238.34]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA03186 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 14 Sep 1999 00:49:10 -0400
Received: (from smap@localhost)
	by zhora.replicant.apana.org.au (8.8.5/8.8.5) id OAA13083
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 14 Sep 1999 14:45:24 +1000
Received: from hexdance.replicant.apana.org.au(192.168.200.126) by zhora.replicant.apana.org.au via smap (V1.3)
	id xmaa13079; Tue, 14 Sep 99 14:45:20 +1000
Received: (from jlittler@localhost)
	by localhost.localdomain (8.9.3/8.9.3) id OAA00991
	for linux-audio-dev@ginette.musique.umontreal.ca; Tue, 14 Sep 1999 14:46:22 +1000
Date: Tue, 14 Sep 1999 14:46:21 +1000
From: John Littler <linuxmusic@crosswinds.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Proposal: low-latency real-time audio processing documentation
Message-ID: <19990914144621.B983@localhost.localdomain>
References: <99091017240001.00762@mtg150.upf.es> <199909140123.VAA02913@ginette.musique.umontreal.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
In-Reply-To: <199909140123.VAA02913@ginette.musique.umontreal.ca>; from Eli Brandt on Mon, Sep 13, 1999 at 09:19:13PM -0400
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: d5040d4303a44d44a2cc8009188f7690

 Eli Brandt spake thusly<eli@v.gp.cs.cmu.edu>:
> Maarten de Boer wrote:
> > 
> > I would be willing to take coordination of this, since low-latency
> > real-time audio processing is vital for the project I am partici-
> > pating in, but I am a bit short of time, so I would appreciate
> > your cooperation. Starting with a request for comments. 
> 
> Sounds useful.  I can collect and htmlize information, though I can't
> commit to keeping it up to date afterwards.
> 

Benno's low latency mini-howto is up at Linux MusicStation
http://www2.crosswinds.net/~linuxmusic/lowlatency.html

I'd be happy to help out with the audio processing docs too.
Cheers
John
-- 
http://linuxmusic.cjb.net

From - Tue Sep 14 10:43:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id IAA01958
	for <slinkp@ulster.net>; Tue, 14 Sep 1999 08:33:38 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id HAA03840 for linux-audio-dev-list; Tue, 14 Sep 1999 07:16:31 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA03837 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 14 Sep 1999 07:16:27 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S42078AbPINLMe>; Tue, 14 Sep 1999 14:12:34 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: jos@w3k.org
CC: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <199909122135.OAA28237@proxy3.ba.best.com> (message from Julius
	Smith on Sun, 12 Sep 1999 14:32:04 -0700)
Subject: Re: [linux-audio-dev] Re: Bandlimited interpolation suitable for realtime audio
Message-Id: <19990914111236Z42078-8255+1706@nic.funet.fi>
Date:   Tue, 14 Sep 1999 14:12:34 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 92efa43392fa3d070e3eb937adc0f275

>From:   Julius Smith <jos@w3k.org>
>
>If anyone knows how to reach 
>	Juhana Sadeharju <kouhia@nic.funet.fi>
>please forward this email (and my previous message).

I got them through linux-audio-dev mailing list. Thank you for letting
me to know about the mailing problem.

I will use the techniques you wrote about to test the interpolation
codes, thanks.

By the way, do you have reference listings on-line? They would be useful
in searching interesting papers.

Yours,

Juhana

From - Tue Sep 14 10:43:27 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id IAA01887
	for <slinkp@ulster.net>; Tue, 14 Sep 1999 08:33:15 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id HAA03849 for linux-audio-dev-list; Tue, 14 Sep 1999 07:29:50 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA03846 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 14 Sep 1999 07:29:47 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S42627AbPINLZx>; Tue, 14 Sep 1999 14:25:53 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <Pine.LNX.4.10.9909122152260.13205-100000@sculpcave.localdomain>
	(message from Kai Vehmanen on Sun, 12 Sep 1999 22:53:46 +0300 (EEST))
Subject: Re: [linux-audio-dev] Kwave
Message-Id: <19990914112558Z42627-23519+1744@nic.funet.fi>
Date:   Tue, 14 Sep 1999 14:25:53 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 93c8bbd2dc14f5d4e51bf0558168cdeb

>From:   Kai Vehmanen <kaiv@wakkanet.fi>
>
>- Does it load the sample data into memory (in otherwords; does
>  it support _large_ files)?

Either loads to memory or uses mmap.

>- Are the basic UI-features (marking, copy, cut, paste, etc) working? 

As far as I know, even I have not tried KWave myself.

>I don't have the time to take over this project, but I wish I could.

We should not worry about KWave because I'm putting all interesting
features to my wave editor. I'm sure it will have a feel of Sound Forge.

I remember KWave is written with C++. That is second reason why I don't
adopt it.

>TAON looks goods, but I've had a lot of problems with it 

They seem to have other problems too... I simply don't thrust them as
I don't thrust spammers. (Check their license/patent mess... whatever, who
cares?)

By the way:
Has anyone succeeded to compile GNU software named Out of Phase?
It seems to be both wave editor and multitrack sequencer (a la Mix).
It is at least in "ftp://ftp.funet.fi/pub/sci/audio/out-of-phase/".

Yours,

Juhana

From - Tue Sep 14 10:43:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA07383
	for <slinkp@ulster.net>; Tue, 14 Sep 1999 09:20:45 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA03934 for linux-audio-dev-list; Tue, 14 Sep 1999 08:21:21 -0400
Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA03931 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 14 Sep 1999 08:21:17 -0400
Received: from hendrix (stan94.zip.com.au [61.8.17.94])
	by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id WAA24599
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 14 Sep 1999 22:04:15 +1000 (EST)
Message-ID: <37DE3CE2.405CD41D@zip.com.au>
Date: Tue, 14 Sep 1999 22:17:38 +1000
From: Erik de Castro Lopo <erikd@zip.com.au>
Organization: Indonesian murders out of East Timor NOW!
X-Mailer: Mozilla 3.04Gold (X11; I; Linux 2.2.12 i586)
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Latency
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 269c35ac5da615226294b37f2c4b770a

Hi all,

I'm a little concerned about this term latency. To me latency
is a property of a one-shot process. An example would be interrupt
latency.

What we're talking about is getting an input, processing it 
and generating an output. We are then trying to minimise the
delay between when the input arrives and the output for said
input is generated.

Wouldn't this be more accurately be described as a "transport
delay" in line with the terminology of Control Theory? In the
terminology of DSP this would be called a linear phase shift 
but thats probably not very clear :-).

Cheers,
Erik
-- 
+-------------------------------------------------+
     Erik de Castro Lopo     erikd@zip.com.au
+-------------------------------------------------+
The National Multiple Sclerosis Society of America recently started an
advertising campaign with the slogan "MS: It's not a software company".

Seasoned IT professionals will have no trouble telling the two MS's
apart.  
One is a debilitating and surprisingly widespread affliction that
renders
the sufferer barely able to perform the simplest task. The other is a
disease.

From - Tue Sep 14 10:43:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA15731
	for <slinkp@ulster.net>; Tue, 14 Sep 1999 10:22:07 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA04044 for linux-audio-dev-list; Tue, 14 Sep 1999 09:12:16 -0400
Received: from mb3.mailbank.com (mb3.mailbank.com [209.133.104.8]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA04041 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 14 Sep 1999 09:12:13 -0400
Received: from pcbg (adial164.namen.eunet.be [195.0.23.164])
	by mb3.mailbank.com (8.9.1/8.9.1) with SMTP id GAA06323;
	Tue, 14 Sep 1999 06:08:26 -0700
Message-ID: <004401befeb1$fda26f20$25010180@pcbg>
Reply-To: "Benjamin GOLINVAUX" <golinvaux@benjamin.net>
From: "Benjamin GOLINVAUX" <golinvaux@benjamin.net>
To: <alsa-devel@alsa-project.org>
Cc: <linux-audio-dev@ginette.musique.umontreal.ca>
References: <37DE3CE2.405CD41D@zip.com.au>
Subject: Re: [linux-audio-dev] Latency [OT]
Date: Tue, 14 Sep 1999 15:06:36 +0200
Organization: Art & Magic
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: deb2a95e231d89159c86b2a9137cfa62

>I'm a little concerned about this term latency. To me latency
>is a property of a one-shot process. An example would be interrupt
>latency.
[...]
> Wouldn't this be more accurately be described as a "transport
> delay" in line with the terminology of Control Theory? In the
> terminology of DSP this would be called a linear phase shift
> but thats probably not very clear :-).

I'd prefer 'input to output latency' since 'latency' is such a widely
accepted term.

However, there is a _lot_ of confusion...

Benno's latency program clearly deals with a one-shot latency from process
to audio out.
[oops... I'm not on alsa-devel here... Different lists, same people...]

Could we safely assume that the iolatency is two times the one shot latency
with two threads, one for audio in and one for audio out ? Any sync issues ?

BTW, I'M POSTING THIS TO ALSA-DEVEL just to make sure latency-aware people
read the post...

How many of you are NOT subscribed to linux-audio-dev ????




From - Wed Sep 15 02:52:53 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA27484
	for <slinkp@ulster.net>; Tue, 14 Sep 1999 11:40:53 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA04138 for linux-audio-dev-list; Tue, 14 Sep 1999 10:22:24 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA04135 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 14 Sep 1999 10:22:21 -0400
Received: from bright.net (find-cas1-cs-47.dial.bright.net [209.143.26.150])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id KAA15493;
	Tue, 14 Sep 1999 10:17:25 -0400 (EDT)
Message-ID: <37DE5D87.8CA1E8ED@bright.net>
Date: Tue, 14 Sep 1999 10:36:55 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Maarten de Boer <maarten.deboer@iua.upf.es>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Re: Attachment: article "Multi-processing and multi-threading for 
 digital audio processing"
References: <99091415223102.01008@mtg150.upf.es> <99091415250103.01008@mtg150.upf.es>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 5be190549d0b03847d6370695572cb6c

Greetings:

  Thank you for your papers, Maarten. They read well and seem to be a
good introduction to the dimensions of the problem and its solutions. I
think a good collection of technical papers on the subject might
include:

  1. the current soundcard.h API
  2. the available & relevant ALSA docs
  3. Benno Senoner's latency test page
  4. your material
  5. Juhana Sadeharju's GASP docs
  6. ???

Thanks for mentioning my site !

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Wed Sep 15 02:52:51 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA26828
	for <slinkp@ulster.net>; Tue, 14 Sep 1999 11:36:52 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA04167 for linux-audio-dev-list; Tue, 14 Sep 1999 10:32:52 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA04164 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 14 Sep 1999 10:32:48 -0400
Received: from bright.net (find-cas1-cs-47.dial.bright.net [209.143.26.150])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id KAA02707;
	Tue, 14 Sep 1999 10:29:07 -0400 (EDT)
Message-ID: <37DE6045.E731472E@bright.net>
Date: Tue, 14 Sep 1999 10:48:37 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Juhana Sadeharju <kouhia@nic.funet.fi>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Kwave
References: <19990914112558Z42627-23519+1744@nic.funet.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 393fbc75670ff7f93ad6d523f9544a86

Juhana Sadeharju wrote:

> We should not worry about KWave because I'm putting all interesting
> features to my wave editor. I'm sure it will have a feel of Sound Forge.
> 
> I remember KWave is written with C++. That is second reason why I don't
> adopt it.

Nevertheless, it is a good piece of software with some development time
already into it. I *have* used Kwave extensively, IMO it deserves better
than to languish. The source is open and it has a nice feature set. It
makes good use of Qt graphics, and includes a number of visual editors
for various functions.
 
> Has anyone succeeded to compile GNU software named Out of Phase?
> It seems to be both wave editor and multitrack sequencer (a la Mix).
> It is at least in "ftp://ftp.funet.fi/pub/sci/audio/out-of-phase/".

I looked at it a couple of years ago and got nowhere with it. I've
downloaded it again and will check it out once more.

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Wed Sep 15 02:52:58 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA05980
	for <slinkp@ulster.net>; Tue, 14 Sep 1999 12:49:48 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA04303 for linux-audio-dev-list; Tue, 14 Sep 1999 11:45:16 -0400
Received: from proxy3.ba.best.com (proxy3.ba.best.com [206.184.139.14]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA04300 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 14 Sep 1999 11:45:14 -0400
Received: from julius (dynamic3.pm03.mv.best.com [209.24.240.131])
	by proxy3.ba.best.com (8.9.3/8.9.2/best.out) with SMTP id IAA13209;
	Tue, 14 Sep 1999 08:37:35 -0700 (PDT)
Message-Id: <199909141537.IAA13209@proxy3.ba.best.com>
X-Sender: julius@shell16.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Tue, 14 Sep 1999 08:41:14 -0700
To: Juhana Sadeharju <kouhia@nic.funet.fi>
From: Julius Smith <jos@w3k.org>
Subject: Re: [linux-audio-dev] Re: Bandlimited interpolation suitable
  for realtime audio
Cc: linux-audio-dev@ginette.musique.umontreal.ca
In-Reply-To: <19990914111236Z42078-8255+1706@nic.funet.fi>
References: <199909122135.OAA28237@proxy3.ba.best.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id MAA05980
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b3eab010a217e0568153a9499cd78804


>By the way, do you have reference listings on-line? They would be useful
>in searching interesting papers.

Here are the ones from my tutorial.  I've added a "*" by what I recommend for a first reading:

* 1 R. W. Schafer and L. R. Rabiner, ``A digital signal processing approach to
    interpolation,'' Proceedings of the IEEE, vol. 61, pp. 692-702, June 1973. 

2 R. Crochiere and L. R. Rabiner, Multirate Digital Signal Processing. 
    Englewood Cliffs, NJ: Prentice-Hall, Inc., 1983. 

3 Digital Signal Processing Committee, ed., Programs for Digital Signal
    Processing.  New York: IEEE Press, 1979. 

4 L. R. Rabiner and B. Gold, Theory and Application of Digital Signal
    Processing. Englewood Cliffs, NJ: Prentice-Hall, Inc., 1975. 

5 A. A. Goldstein, Constructive Real Analysis. 
    New York: Harper and Row, 1967. 

6 T. Schanze, ``Sinc interpolation of discrete periodic signals,'' IEEE
    Transactions on Signal Processing, vol. 43, pp. 1502-1503, June 1995. 

7 F. B. Hildebrand, Introduction to Numerical Analysis. 
    New York: Dover, 1974. 
    Second edition. 

8 P. J. Kootsookos and R. C. Williamson, ``Fir approximation of fractional
    sample delay systems,'' IEEE Transactions on Circuits and Systems--II:
    Analog and Digital Signal Processing, vol. 43, pp. 40-48, Feb 1996. 

* 9 V. Vlimki, Discrete-Time Modeling of Acoustic Tubes Using Fractional
    Delay Filters.  PhD thesis, Report no. 37, Helsinki University of Technology, Faculty of
    Electrical Engineering, Laboratory of Acoustic and Audio Signal Processing,
    Espoo, Finland, Dec. 1995. 

* 10 D. Rossum, ``Constraint based audio interpolators,'' Proceedings of the IEEE
    Workshop on Applications of Signal Processing to Audio and Acoustics, New
    Paltz, NY, 1993. 

[Superseded by tutorial] 
  11 J. O. Smith and P. Gossett, ``A flexible sampling-rate conversion method,'' in
    Proceedings of the International Conference on Acoustics, Speech, and Signal
    Processing, San Diego, vol. 2, (New York), pp. 19.4.1-19.4.2, IEEE Press,
    March 1984. 
    An expanded tutorial based on this paper and associated free software are
    available online at http://www-ccrma.stanford.edu/~jos/ . 

From - Wed Sep 15 02:53:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA30128
	for <slinkp@ulster.net>; Tue, 14 Sep 1999 15:29:00 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA04675 for linux-audio-dev-list; Tue, 14 Sep 1999 14:41:52 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA04672 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 14 Sep 1999 14:41:48 -0400
From: sbenno@gardena.net
Received: from linuxhost.localdomain (IDENT:root@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id UAA18563;
	Tue, 14 Sep 1999 20:37:53 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id WAA01154;
	Tue, 14 Sep 1999 22:38:43 +0200
To: "Benjamin GOLINVAUX" <golinvaux@benjamin.net>,
        <alsa-devel@alsa-project.org>
Subject: Re: [linux-audio-dev] Latency .. fullduplex case
Date: Tue, 14 Sep 1999 18:44:00 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: <linux-audio-dev@ginette.musique.umontreal.ca>
References: <004401befeb1$fda26f20$25010180@pcbg>
MIME-Version: 1.0
Message-Id: <99091421503905.00749@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f0c720db06a1282b675a53a87c9dd7ce

On Tue, 14 Sep 1999, Benjamin GOLINVAUX wrote:
> >I'm a little concerned about this term latency. To me latency
> >is a property of a one-shot process. An example would be interrupt
> >latency.
> [...]
> > Wouldn't this be more accurately be described as a "transport
> > delay" in line with the terminology of Control Theory? In the
> > terminology of DSP this would be called a linear phase shift
> > but thats probably not very clear :-).
> 
> I'd prefer 'input to output latency' since 'latency' is such a widely
> accepted term.
> 
> However, there is a _lot_ of confusion...
> 
> Benno's latency program clearly deals with a one-shot latency from process
> to audio out.
> [oops... I'm not on alsa-devel here... Different lists, same people...]
> 
> Could we safely assume that the iolatency is two times the one shot latency
> with two threads, one for audio in and one for audio out ? Any sync issues ?

No that is not true, IO-latency is not 2* output-latency, since
you read/write 1 fragment at time, you can just add one single fragment
to the buffer to keep things reliably.

example:
3x128 bytes =2.1ms , output latency
max peaks around 1.4ms
make the buffer one fragment larger = 4x128 bytes = 2.8ms latency

and then do the following:  ( assuming you use blocking read/write)
write 4 fragments of silence to the output, at this point
both audio input and audio output will start (or alternatively you could
trigger the start via ioctl() after the write).

now enter into main loop:

while(1)
{
  read() from dsp to buffer 
  do_processing()
  write() buffer to dsp
}

the first read should block since the write of the 4 fragments returns almost
immediately since it fits exactly into the audio buffer.
After the read returns, there are exactly 3 fragments in the output buffer
at this point you do your computations and assuming you use 90% of your CPU
for your DSP computations,
before the write() to /dev/dsp there are a bit over 2 fragments in the audio
buffer left. (if you do very little computations then there will be almost 3
fragments in the audio buffer left)

after the write() you have between 3 and 4 fragments in the buffer.
(depends from how much DSP computations you do in your do_processing()

plus add more 0.5ms for your soundcard's ADC ,
and you got a nice 3.3ms
:-)

Correct me please if I am missing something.


Benno.




From - Wed Sep 15 02:53:03 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA11517
	for <slinkp@ulster.net>; Tue, 14 Sep 1999 16:56:12 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA04834 for linux-audio-dev-list; Tue, 14 Sep 1999 16:07:06 -0400
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id QAA04831 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 14 Sep 1999 16:07:04 -0400
Message-Id: <199909142007.QAA04831@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Latency
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Tue, 14 Sep 1999 16:02:50 -0400 (EDT)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
In-Reply-To: <37DE3CE2.405CD41D@zip.com.au> from "Erik de Castro Lopo" at Sep 14, 99 10:17:38 pm
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5e3d7fffeb834211b52d4af50a05dfb8

Erik de Castro Lopo wrote:
> I'm a little concerned about this term latency. To me latency
> is a property of a one-shot process. An example would be interrupt
> latency.
>
> What we're talking about is getting an input, processing it 
> and generating an output. We are then trying to minimise the
> delay between when the input arrives and the output for said
> input is generated.

In general, we talk about one-shot latency, average latency,
worst-case latency, etc.  In the case of audio-to-audio processing all
of these are equal, so I think it's reasonable to just say "latency".

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Wed Sep 15 02:53:07 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA20415
	for <slinkp@ulster.net>; Tue, 14 Sep 1999 17:48:49 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA04955 for linux-audio-dev-list; Tue, 14 Sep 1999 17:08:31 -0400
Received: from ax-nicb.axnet.it (ax-nicb.axnet.it [194.184.60.149]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA04952 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 14 Sep 1999 17:08:22 -0400
Received: (from nicb@localhost)
	by ax-nicb.axnet.it (8.8.7/8.8.7) id XAA26162;
	Tue, 14 Sep 1999 23:03:25 +0200
Date: Tue, 14 Sep 1999 23:03:25 +0200 (CEST)
From: Nicola Bernardini <nicb@axnet.it>
To: Dave Phillips <dlphilp@bright.net>
cc: Juhana Sadeharju <kouhia@nic.funet.fi>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: out-of-phase (was Re: [linux-audio-dev] Kwave)
In-Reply-To: <37DE6045.E731472E@bright.net>
Message-ID: <Pine.LNX.4.10.9909142242580.21488-100000@ax-nicb.axnet.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 4f053dca7e99ce6defc8b808f2622660

Today, Dave Phillips mi scrisse cio` che segue:

[snip]
> > Has anyone succeeded to compile GNU software named Out of Phase?
> > It seems to be both wave editor and multitrack sequencer (a la Mix).
> > It is at least in "ftp://ftp.funet.fi/pub/sci/audio/out-of-phase/".
> 
> I looked at it a couple of years ago and got nowhere with it. I've
> downloaded it again and will check it out once more.

You got me curious enough to download the package and try compiling.
I've spent two hours with it, built three makefiles, made a couple
of patches here and there and got to the end of the compile process
(successefully). However, the linking process breaks with tons of 
undefined references which I don't know which library they belong
to. They are something like:

undefined reference to `CheckPtrExistence'
undefined reference to `GetFontHeight'
undefined reference to `LengthOfText'
undefined reference to `DrawTextLine'

etc. etc. If anybody can tell to what library these functions
belong then we've got the baby running (*if* such library is
freely available - of course). On the whole it looks like a Mac
application and I'm fairly surprised I got this far.

well, that's how I spend my last half an hour :)

Nicola
------------------------------------------------------------------------
Nicola Bernardini
E-mail: nicb@axnet.it
 
Re graphics: A picture is worth 10K words -- but only those to describe
the picture.  Hardly any sets of 10K words can be adequately described
with pictures.

From - Wed Sep 15 02:53:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA22829
	for <slinkp@ulster.net>; Tue, 14 Sep 1999 21:36:59 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA05357 for linux-audio-dev-list; Tue, 14 Sep 1999 20:56:03 -0400
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id UAA05354 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 14 Sep 1999 20:56:01 -0400
Message-Id: <199909150056.UAA05354@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Latency .. fullduplex case
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Tue, 14 Sep 1999 20:52:04 -0400 (EDT)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
In-Reply-To: <99091421503905.00749@linuxhost.localdomain> from "sbenno@gardena.net" at Sep 14, 99 06:44:00 pm
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1b25a149f4ea8b89050fe6bde125c9b8

sbenno@gardena.net wrote:
> On Tue, 14 Sep 1999, Benjamin GOLINVAUX wrote:
> > Could we safely assume that the iolatency is two times the one shot latency
> > with two threads, one for audio in and one for audio out ? Any sync issues ?
> 
> No that is not true, IO-latency is not 2* output-latency, since
> you read/write 1 fragment at time, you can just add one single fragment
> to the buffer to keep things reliably.

Let me take a whack at this as see if I get the same result.  The
important time here is the worst-case latency from when a blocking I/O
call is done to when my program gets control back.

start with input empty, output full.
        action                  timespan
read() is done                  F       fragment length in msec
return from read()              L       worst-case interrupt-to-running time
new fragment is computed        a*F     a is realtime ratio, 0 < a < 1.
call write()

total time (1+a)F + L, which approaches 2F + L.
we need N fragments buffered, where NF > 2F + L, so N > 2 + L/F.

we're using 32-frame fragments, F = 0.73 ms.
L = 1.4 ms (yeehaw).
so N > 2 + 1.92, i.e. N = 4 fragments (2.8 ms actually).
great, same result -- if you like formulas, here you got 'em.

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Thu Sep 16 01:03:11 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA04270
	for <slinkp@ulster.net>; Wed, 15 Sep 1999 15:16:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA06994 for linux-audio-dev-list; Wed, 15 Sep 1999 12:24:11 -0400
Received: from upf.es (newton.upf.es [193.145.54.60]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA06991 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 15 Sep 1999 12:23:28 -0400
Received: from mtg150.upf.es (mtg150.upf.es [193.145.44.150])
	by upf.es (8.9.0/8.9.0) with SMTP id RAA09931;
	Wed, 15 Sep 1999 17:22:38 +0200 (MET DST)
From: Maarten de Boer <maarten.deboer@iua.upf.es>
Reply-To: maarten.deboer@iua.upf.es
To: linux-audio-dev@ginette.musique.umontreal.ca, alsa-devel@alsa-project.org,
        sbenno@gardena.net, pbd@op.net, mingo@chiara.csoma.elte.hu
Subject: [linux-audio-dev] bad latency benchmark results with SMP kernel
Date: Wed, 15 Sep 1999 17:21:50 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <99091517295600.01158@mtg150.upf.es>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: dbe301cb0a26f8da4f234df4cdd238a3

Hi,

I have been running Benno's latest benchmarks 
on a Dual Pentium II 400 Mhz. (kernel 2.2.10,
N6 patch and rtc patch applied).

I got very bad results on the /proc stresstest.

After mailing with Benno, and trying all sort
of things, I finally discovered that when I 
compile my kernel without SMP support, the 
result *are* good.

This seems to mean that the N6 patch is not
working well for SMP.

Can somebody with a SMP machine confirm this ?
Or even better: fix it :-)

Ingo: maybe you don't have access to a Dual
processor machine. Can you point out where
I should look to fix the problem ?

Regards

Maarten

From - Wed Sep 15 13:57:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA13803
	for <slinkp@ulster.net>; Wed, 15 Sep 1999 12:35:19 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA06794 for linux-audio-dev-list; Wed, 15 Sep 1999 11:40:12 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA06788 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 15 Sep 1999 11:39:57 -0400
Received: from someip.ppp.op.net (d-bm2-08.ppp.op.net [209.152.194.40]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id LAA10819; Wed, 15 Sep 1999 11:36:07 -0400 (EDT)
Message-Id: <199909151536.LAA10819@renoir.op.net>
To: maarten.deboer@iua.upf.es
cc: linux-audio-dev@ginette.musique.umontreal.ca, alsa-devel@alsa-project.org,
        sbenno@gardena.net, mingo@chiara.csoma.elte.hu
Subject: [linux-audio-dev] Re: bad latency benchmark results with SMP kernel 
In-reply-to: Your message of "Wed, 15 Sep 1999 17:21:50 +0200."
             <99091517295600.01158@mtg150.upf.es> 
Date: Wed, 15 Sep 1999 11:41:21 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 2d2f1453e849150a4727265f69638df7

>This seems to mean that the N6 patch is not
>working well for SMP.

I have an dual PII-450 machine, but I'm still stuck at 2.2.7.

I would like to point out that the latency issues are not anywhere
near as much of a problem on an MP system. I can get hardware-level
latency (limited by the DMA transfer size - typically about 0.2ms) on
my system, by just binding to the processor and blocking interrupts
from that processor (oh, and using mmap(2)). 

Even so, I will make an effort to move up to 2.2.10(N6) over the next
week or so, and see what I find out.

--p

From - Wed Sep 15 13:57:31 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA14572
	for <slinkp@ulster.net>; Wed, 15 Sep 1999 12:40:54 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA06874 for linux-audio-dev-list; Wed, 15 Sep 1999 11:50:26 -0400
Received: from upf.es (newton.upf.es [193.145.54.60]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA06868 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 15 Sep 1999 11:50:06 -0400
Received: from mtg150.upf.es (mtg150.upf.es [193.145.44.150])
	by upf.es (8.9.0/8.9.0) with SMTP id RAA11371;
	Wed, 15 Sep 1999 17:45:21 +0200 (MET DST)
From: Maarten de Boer <maarten.deboer@iua.upf.es>
Reply-To: maarten.deboer@iua.upf.es
To: pbd@op.net, maarten.deboer@harrison.upf.es
Subject: [linux-audio-dev] Re: bad latency benchmark results with SMP kernel
Date: Wed, 15 Sep 1999 17:49:11 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca, alsa-devel@alsa-project.org,
        sbenno@gardena.net, mingo@chiara.csoma.elte.hu
References: <199909151536.LAA10819@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99091517524401.01158@mtg150.upf.es>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: cc79a6e9bf0ee1b9dd467bf56c1da47f

On Wed, 15 Sep 1999, pbd@op.net wrote:
> I would like to point out that the latency issues are not anywhere
> near as much of a problem on an MP system. I can get hardware-level
> latency (limited by the DMA transfer size - typically about 0.2ms) on
> my system, by just binding to the processor and blocking interrupts
> from that processor (oh, and using mmap(2)). 
Yeah, I used that method before to. Without mmap but with nonblocking
read/write. But now I am using both processors at hi load, because I 
have to do a lot of calculation in between the sound read and sound 
write. So in that case, your method doesn't work.

> Even so, I will make an effort to move up to 2.2.10(N6) over the next
> week or so, and see what I find out.
Great! Please let me know what you experience.

Maarten

From - Wed Sep 15 13:57:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA20228
	for <slinkp@ulster.net>; Wed, 15 Sep 1999 13:21:08 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA06984 for linux-audio-dev-list; Wed, 15 Sep 1999 12:21:56 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA06981 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 15 Sep 1999 12:21:50 -0400
Received: from bright.net (find-cas2-cs-18.dial.bright.net [209.143.26.172])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id MAA22363;
	Wed, 15 Sep 1999 12:18:14 -0400 (EDT)
Message-ID: <37DFCB42.18828571@bright.net>
Date: Wed, 15 Sep 1999 12:37:22 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] SVGA Multitrack
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 70bf7b8a1cf7d54ed6056a4f15d2a4ed

Greetings:

  I still haven't heard from Boris Nagels, but thanks to John Littler I
am now able to run Multitrack in X under RH 5.2 Kernel 2.0.36. I haven't
thoroughly tested it there, but I will.

  Unfortunately I am unable to get the SVGA version working properly.
Specifically, the mouse doesn't respond correctly: when I open
Multitrack the pointer is in the middle of the screen, but when I move
the mouse the pointer just jerks towards the upper left corner. It is
unresponsive, and I have to Control-C to get out of the program. No
error messages are left on-screen.

  I've tried killing the mouse, but that makes no difference. Also, I
reied using every setting for gpm that there was to try. No joy.

  So, if anyone has Multitrack working under similar conditions, maybe
you could tell me how it's done ?

  TIA !

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Wed Sep 15 13:57:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA20333
	for <slinkp@ulster.net>; Wed, 15 Sep 1999 13:21:56 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA07023 for linux-audio-dev-list; Wed, 15 Sep 1999 12:30:53 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA07020 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 15 Sep 1999 12:30:50 -0400
Received: from bright.net (find-cas2-cs-18.dial.bright.net [209.143.26.172])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id MAA03750;
	Wed, 15 Sep 1999 12:27:06 -0400 (EDT)
Message-ID: <37DFCD57.E53A4AD1@bright.net>
Date: Wed, 15 Sep 1999 12:46:15 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: =?iso-8859-1?Q?J=F3n?= I Ingimundarson <jii@oz.com>,
        LAD Mail 
	<linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Re: linux audio dev mailing list
References: <002567ED.002CAFFB.00@kansas.intranet.oz.is>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by sparticus.bright.net id MAA03750
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id NAA20333
X-Mozilla-Status: 8003
X-Mozilla-Status2: 00000000
X-UIDL: ee9f854159363381994e8d14b17cb2ce

"Jn I Ingimundarson" wrote:

> Is there an archive available of this mailing list anywhere?

Not that I know of, but it would be a good idea to have one. I've kept
most of the traffic, but you're right, an archive would be a good thing.

Damien ? Anyone ?

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Thu Sep 16 01:03:08 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA32477
	for <slinkp@ulster.net>; Wed, 15 Sep 1999 14:47:06 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA07195 for linux-audio-dev-list; Wed, 15 Sep 1999 13:55:16 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA07192 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 15 Sep 1999 13:55:13 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id NAA12446
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 15 Sep 1999 13:50:40 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id NAA13415; Wed, 15 Sep 1999 13:50:38 -0400 (EDT)
Date: Wed, 15 Sep 1999 13:50:31 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] SVGA Multitrack
In-Reply-To: <37DFCB42.18828571@bright.net>
Message-ID: <Pine.GSO.4.10.9909151345150.13226-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 62d4dadf40ee45a2f991eedd0556a755

On Wed, 15 Sep 1999, Dave Phillips wrote:

>   Unfortunately I am unable to get the SVGA version working properly.
> Specifically, the mouse doesn't respond correctly: when I open
> Multitrack the pointer is in the middle of the screen, but when I move
> the mouse the pointer just jerks towards the upper left corner. It is
> unresponsive, and I have to Control-C to get out of the program. No
> error messages are left on-screen.

That is a symptom that I used to get when trying to use a PS/2 mouse with
a bus mouse driver or vice versa.  Make sure that svgalib itself (not just
gpm and xfree86) is set to use the appropriate type of mouse.

No guarantees though; I've never had more than the most fleeting interest
in svgalib.

Div.

From - Thu Sep 16 01:03:12 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA06666
	for <slinkp@ulster.net>; Wed, 15 Sep 1999 15:32:35 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA07278 for linux-audio-dev-list; Wed, 15 Sep 1999 14:41:07 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA07275 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 15 Sep 1999 14:41:05 -0400
Received: from bright.net (find-cas2-cs-27.dial.bright.net [209.143.26.181])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id OAA08805;
	Wed, 15 Sep 1999 14:37:28 -0400 (EDT)
Message-ID: <37DFEBE6.C145BDAD@bright.net>
Date: Wed, 15 Sep 1999 14:56:38 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: David Slomin <dgslomin@CS.Princeton.EDU>
CC: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] SVGA Multitrack
References: <Pine.GSO.4.10.9909151345150.13226-100000@ux02.CS.Princeton.EDU>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 755197ad7608ea88053587cd2a1d1e1b

David Slomin wrote:

> That is a symptom that I used to get when trying to use a PS/2 mouse with
> a bus mouse driver or vice versa.  Make sure that svgalib itself (not just
> gpm and xfree86) is set to use the appropriate type of mouse.
> 
> No guarantees though; I've never had more than the most fleeting interest
> in svgalib.

Beautiful, all I had to do was revise the setting in
/etc/vga/libvga.conf and the mouse now works fine. On to the testing...

Thanks, Div !

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Thu Sep 16 01:03:10 1999
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id OAA01648
	for <slinkp@ulster.net>; Wed, 15 Sep 1999 14:57:44 -0400
Received: from bright.net (find-cas2-cs-27.dial.bright.net [209.143.26.181])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id OAA12204;
	Wed, 15 Sep 1999 14:39:50 -0400 (EDT)
Sender: root@sparticus.bright.net
Message-ID: <37DFEC74.41B8317D@bright.net>
Date: Wed, 15 Sep 1999 14:59:00 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Winkler <slinkp@ulster.net>
Subject: Re: [linux-audio-dev] Re: linux audio dev mailing list
References: <002567ED.002CAFFB.00@kansas.intranet.oz.is> <37DFCD57.E53A4AD1@bright.net> <37DFE104.EBA488C3@ulster.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: U
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: ddbcd13062e97d13fb2ff25272e9189d

Paul Winkler wrote:

> This would have to wait a little while, but I could do it. Setting up
> mhonarc is not that hard (I did it to make a local archive of csound
> list on my machine).

Sounds good, keep me informed. So far you're the only taker...
 
> I didn't cc this message to the list because the above-mentioned hosting
> person asked me not to announce it before they do... it'll be a cool
> site which you will hear about.

Ah, suspense, mystery, intrigue...

How's everything going for you these days ?

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Thu Sep 16 01:03:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA05891
	for <slinkp@ulster.net>; Wed, 15 Sep 1999 18:43:58 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA07543 for linux-audio-dev-list; Wed, 15 Sep 1999 17:50:51 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA07540 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 15 Sep 1999 17:50:48 -0400
Received: from localhost.localdomain (dialup41-4-60.swipnet.se [130.244.41.252]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id XAA09441; 
          Wed, 15 Sep 1999 23:46:17 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: eli+@cs.cmu.edu, Eli Brandt <eli@v.gp.cs.cmu.edu>
Subject: Re: [linux-audio-dev] Plug-in API design decisions; please consider
Date: Wed, 15 Sep 1999 22:30:41 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <199909062248.AAA26341@mailgw4.swip.net>
MIME-Version: 1.0
Message-Id: <99091523170802.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id XAA09441
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA05891
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5bb5821ce290a6d0a0b30fc171ed2d9f

On Tue, 07 Sep 1999, Eli Brandt wrote:
> Old message here...
> 
> David Olofson wrote:
> > .-------
> > | Are we concentrating fully on audio-only, or
> > | should we take other forms of data into account?
> > `-------
> 
> And sound in general is more than just sampled audio!  I would love to
> be able to deal with short-time spectra, LPC frames, timestamped audio
> fragments, time-varying matrices, who knows what all.  Going down this
> road does make the system unprecendentedly involved....

Again; the event system... And things like time stamped audio fragments
shouldn't be visible to normal plug-ins. They always deal with solid streams,
and things like playing audio clips should be handled by special plug-ins,
talking to a multi channel streamer/caching daemon.

An audio plug-in just processes buffers of audio samples, not structured data.
A MIDI plug-in recieves, reacts on, and transmits events. A video plug-in would
process buffers of one or more frames (look_ahead and skip_behind would still
apply, of course).

It's a matter of drawing the line between "transport layer definition" and
"data format details" - not finding out what should be supported, and then just
throwing it all into the plug-in/engine specification. Or; "Does the UNIX
file system/device driver API understand everything it can handle?" A plug-in
host should host plug-ins, not deal with details of exotic data formats. The
details of a specific data format belong inside plug-ins that
generate/process/convert data of that kind, and inside drivers/system
interface plug-ins, and I can't se many reasons to break this rule.

We're basically dealing with a real time streaming file system. There are
"applications": plug-ins, "drivers": converter/driver/system interface
plug-ins, some of which may be initegrated with the plug-in host, and there is
an "OS": the plug-in host; also know as the engine. What we need is very fast
"task switching" (for small buffer sizes), accurate time stamps, real time
guarantees and some other requirements that normal file systems cannot handle,
but other than that, the way I see the plug-in API is as a kind of interface to
a very specialized OS. However, not as specialized as only being able to handle
data formats natively known by the engine....

> If people who program streaming video think what they'd want in a
> plug-in system is the same as what we'd want for audio, sure, at least
> reserve field-space for merging it in.  I'm leery of going out and
> designing a video-processing system myself, since I don't do video and
> wouldn't want to use a video guy's idea of an audio system either.
> (Consider DirectShow, formerly known as ActiveMovie.  You can tell.)

I agree. We don't need that kind of mess, and as far as Audiality is concerned,
that much crap in between the engine and the plug-ins would render the API
useless for very low latency applictions.

> Video people have god-awful synchronization issues that I never have to
> think about.

How? Is it trivial to synchronize multiple internal and external audio and
MIDI devices? Well, good looking video frame interpolation (which is usually not
done, BTW - they just drop or repeat frames) is more complicated than
resampling of audio data, but the problems are still very similar. You have
streams of frames that should all be synchronized to a master, and you have to
do something about frame rate differences.

> Their frames are much longer than mine, so they might
> consider it reasonable to hog the CPU for 20 msec.

You get the same problem if you split audio processing over a very low latency
thread for real time synthesizing and monitoring, and a "high" latency thread
for playing and processing stuff from disk or sequencer. This is where a real
RTOS comes in handy.

> I dunno what else
> might come up.  You know, the more I think about this the more I think
> the job is quite big enough already.

Yep, but doing things where they should be done (that is, not always in the
engine implementation, or even directly supporting it in the plug-in API) will
actually make things a lot easier for everyone. Engines and plug-ins will be
more reusable, and won't have to care about stuff they won't _actively_ deal
with anyway.

You might have noticed one reason why proprietary standards are designed the
way they are: They force everything to be upgraded in parallel, which in turn
keeps up the cash flow. This is NOT one of _our_ design goals, IMO, so we
shouldn't be to quick to copy the Big Guys. Some things are not what they seem
to be...

> A counterargument is that if we ever want video/audio sync to work, we
> probably have to do the work up-front and get it right now.

Yes. So why not keep things generic up to a reasonable level, so we can turn
an audio engine into an audio/video engine by throwing in some plug-ins and
drivers/interface plug-ins, and possibly optimizing a little by making the
engine natively aware of some new data formats? Even if it requires some extra
thought now, I think it'll pay off in the long run.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Thu Sep 16 01:03:17 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA05702
	for <slinkp@ulster.net>; Wed, 15 Sep 1999 18:43:00 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA07532 for linux-audio-dev-list; Wed, 15 Sep 1999 17:46:01 -0400
Received: from chiara.csoma.elte.hu (chiara.csoma.elte.hu [157.181.71.18]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA07529 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 15 Sep 1999 17:45:58 -0400
From: mingo@chiara.csoma.elte.hu
Received: (from mingo@localhost)
	by chiara.csoma.elte.hu (8.8.8/8.8.8/c) id XAA23271;
	Wed, 15 Sep 1999 23:42:09 +0200
Date: Wed, 15 Sep 1999 23:48:10 +0200 (CEST)
To: Maarten de Boer <maarten.deboer@iua.upf.es>
cc: linux-audio-dev@ginette.musique.umontreal.ca, alsa-devel@alsa-project.org,
        sbenno@gardena.net, pbd@op.net
Subject: [linux-audio-dev] Re: bad latency benchmark results with SMP kernel
In-Reply-To: <99091517295600.01158@mtg150.upf.es>
Message-ID: <Pine.LNX.4.10.9909152341450.12876-100000@chiara.csoma.elte.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 3cdd0946562ef8ac38681ddcf5efa3fb


On Wed, 15 Sep 1999, Maarten de Boer wrote:

> I have been running Benno's latest benchmarks 
> on a Dual Pentium II 400 Mhz. (kernel 2.2.10,
> N6 patch and rtc patch applied).

> Ingo: maybe you don't have access to a Dual
> processor machine. Can you point out where
> I should look to fix the problem ?

the whole lowlatency patch was developed on SMP boxes. (FYI, i'm
maintaining a fair chunk of Linux's x86 SMP code)

the problem is lock_kernel(). the solution is quite simple, in
include/asm/smplock.h, instead of this reaquire_lock():

	spin_lock(&kernel_lock)

do something like:

	while (!spin_trylock(&kernel_lock))
		if (current->need_resched)
			schedule();

does this help? And remove the assembly code from kernel_lock(), and do:

	if (!++current->lock_depth)
		reacquire_kernel_lock(current);

let me know if you cant get it working and i'll send a patch. (but right
now i'm held up with other SMP issues.)

	Ingo

From - Thu Sep 16 15:58:25 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id FAA17164
	for <slinkp@ulster.net>; Thu, 16 Sep 1999 05:29:10 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id EAA08697 for linux-audio-dev-list; Thu, 16 Sep 1999 04:31:25 -0400
Received: from taniwha.org (d123.tnt0.paradise.net.nz [203.96.148.123]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id EAA08694 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 16 Sep 1999 04:31:16 -0400
From: bill@taniwha.org
Received: (qmail 18887 invoked from network); 16 Sep 1999 07:52:36 -0000
Received: from rusalka.taniwha.org (HELO taniwha.org) (172.16.1.3)
  by taniwha.taniwha.org with SMTP; 16 Sep 1999 07:52:36 -0000
Message-ID: <37E0AB75.682B8812@taniwha.org>
Date: Thu, 16 Sep 1999 20:33:57 +1200
X-Mailer: Mozilla 4.6 [en] (X11; U; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: alsa-devel@alsa-project.org
CC: linux-audio-dev@ginette.musique.umontreal.ca, sbenno@gardena.net,
        pbd@Op.Net, mingo@chiara.csoma.elte.hu
Subject: [linux-audio-dev] Re: [alsa-devel] bad latency benchmark results with SMP kernel
References: <99091517295600.01158@mtg150.upf.es>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 39a08506f1ad03fe42bd76d5086ce975

Maarten de Boer wrote:
> Can somebody with a SMP machine confirm this ?
> Or even better: fix it :-)

I have a dual celeron 300/450 (ie o'clocked) running 2.2.12.  As I
intend on trying this out myself when I get around to it, I'll let you
know (ie, if the patches apply).

Bill
-- 
Leave others their otherness.

From - Thu Sep 16 15:58:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA15028
	for <slinkp@ulster.net>; Thu, 16 Sep 1999 10:38:40 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA09076 for linux-audio-dev-list; Thu, 16 Sep 1999 09:38:42 -0400
Received: from goblin.flashnet.it ([194.242.217.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA09073 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 16 Sep 1999 09:38:37 -0400
Received: from localhost (localhost [[UNIX: localhost]])
	by goblin.flashnet.it (8.9.3/8.9.3) id PAA06939;
	Thu, 16 Sep 1999 15:16:08 +0200
From: Benno Senoner <benno@goblin.flashnet.it>
To: Dave Phillips <dlphilp@bright.net>, Jn I Ingimundarson <jii@oz.com>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: linux audio dev mailing list
Date: Thu, 16 Sep 1999 15:14:48 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <37DFCD57.E53A4AD1@bright.net>
MIME-Version: 1.0
Message-Id: <99091615160701.06173@goblin.flashnet.it>
X-MIME-Autoconverted: from 8bit to quoted-printable by goblin.flashnet.it id PAA06939
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id KAA15028
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d080360c56b1876fbf656def9cc73e79

On Wed, 15 Sep 1999, Dave Phillips wrote:
> "Jn I Ingimundarson" wrote:
> 
> > Is there an archive available of this mailing list anywhere?
> 
> Not that I know of, but it would be a good idea to have one. I've kept
> most of the traffic, but you're right, an archive would be a good thing.
> 
> Damien ? Anyone ?
> 
> == Dave Phillips

Why you do not add the mailinglist to

http://www.mail-archive.com   ?
It already carries linux-kernel , linux-sound , alsa-devel , .. etc.

regards,
Benno.

From - Thu Sep 16 15:58:49 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA30847
	for <slinkp@ulster.net>; Thu, 16 Sep 1999 15:58:53 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA09529 for linux-audio-dev-list; Thu, 16 Sep 1999 14:34:34 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA09526 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 16 Sep 1999 14:34:30 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46115AbPIPSaf>; Thu, 16 Sep 1999 21:30:35 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca, alsa-devel@alsa-project.org
Subject: [linux-audio-dev] GASP: update
Message-Id: <19990916183036Z46115-23519+1902@nic.funet.fi>
Date:   Thu, 16 Sep 1999 21:30:35 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 1c1cc6d8a8839ff33fa520af1c88a8c8

Hello. I updated GASP pages a bit. Following changes:

document "Multitasked Real-Time Digital Audio Processing with Linux" by
Maarten de Boer added,
document "Practical Digital Audio" by Juhana Sadeharju, [ this is actually
  uncomplete but I didn't want delay it again; rests follows soon ]
GTK book info added (programming manuals),
list of commercial resources reorganized to sections,
Yamaha O2R manual info added (commercials/mixer desks),
Kurzweil manual info added (commercials/synthesizers),
Audio engine and plug-in APIs added (commercials/APIs)

 -*-

Specially those APIs are interesting. Please take a look and let
me know if there are more of them. I can't believe VST is only
plug-in API? Oops, I have forgot DirectX's DirectSound....

Yours,

Juhana

From - Mon Sep 20 16:32:27 1999
Received: from taz.ulster.net (root@taz.ulster.net [208.148.73.10])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id VAA29313
	for <slinkp@ulster.net>; Fri, 17 Sep 1999 21:03:33 -0400
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34]) by taz.ulster.net (8.8.5/8.7.3) with SMTP id DAA01336 for <slinkp@ulster.net>; Thu, 16 Sep 1999 03:29:10 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id BAA10581 for linux-audio-dev-list; Fri, 17 Sep 1999 01:21:42 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA10578 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 17 Sep 1999 01:21:39 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id BAA00503
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 17 Sep 1999 01:16:52 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id BAA14878; Fri, 17 Sep 1999 01:16:50 -0400 (EDT)
Date: Fri, 17 Sep 1999 01:16:48 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: linux audio dev mailing list
In-Reply-To: <99091615160701.06173@goblin.flashnet.it>
Message-ID: <Pine.GSO.4.10.9909170114050.14305-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1f09fab1fc486174b10a3a0671a0ac81

On Thu, 16 Sep 1999, Benno Senoner wrote:

> Why you do not add the mailinglist to
> 
> http://www.mail-archive.com   ?
> It already carries linux-kernel , linux-sound , alsa-devel , .. etc.

Danger, Will Robinson!  Will that increase the danger of acquiring
resident spammers on the list, like those on the DSP list?

(Just asking, I'd really like for there to be an archive too; if my
poor old machine could stand up to the load, I'd volunteer it.)

Div.

From - Mon Sep 20 16:32:20 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA03353
	for <slinkp@ulster.net>; Fri, 17 Sep 1999 11:40:56 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA11341 for linux-audio-dev-list; Fri, 17 Sep 1999 10:07:53 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA11338 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 17 Sep 1999 10:07:46 -0400
Received: from bright.net (find-cas1-cs-45.dial.bright.net [209.143.26.148])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id KAA07880;
	Fri, 17 Sep 1999 10:04:02 -0400 (EDT)
Message-ID: <37E24F6F.5290F5B3@bright.net>
Date: Fri, 17 Sep 1999 10:25:51 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
CC: cmdist@ccrma.Stanford.EDU
Subject: [linux-audio-dev] Linux, Snd, LessTif, and Scheme
References: <199909171324.GAA26233@cmn14.stanford.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 47600cc3ed6bb82eab9fc3f4c88dbf63

Greetings:

  I compile Snd myself using snd.tar.gz and I've had no trouble using
'configure' or any other part of the make process. Snd appears to work
fine, except for one small (well, not so small) problem.

  I can't use the Listener. I can type in a line, but when I hit the
Enter key the cursor just sticks to the end of the line, there's no
change and nothing happens. Since I've never seen it actually work, I
assume that if the command was kosher then the cursor should drop to the
next line/prompt, right ?

  I've used three different versions of LessTif, and I don't have Motif
installed. Bill S thinks it's a LessTif problem, but I do not have this
problem with any other application I've compiled using LessTif. I have
the latest Guile installed, the configuration finds it without
complaint, and 'ldd snd' reports thusly:

	libguile.so.4 => /usr/lib/libguile.so.4 (0x40007000)
        libdl.so.2 => /lib/libdl.so.2 (0x4006a000)
        libreadline.so.3 => /usr/lib/libreadline.so.3 (0x4006d000)
        libtermcap.so.2 => /lib/libtermcap.so.2 (0x40091000)
        libm.so.6 => /lib/libm.so.6 (0x40095000)
        libMrm.so.1 => /usr/local/lib/libMrm.so.1 (0x400ae000)
        libXm.so.1 => /usr/local/lib/libXm.so.1 (0x400c0000)
        libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x401d2000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x401df000)
        libXp.so.6 => /usr/X11R6/lib/libXp.so.6 (0x401eb000)
        libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x401f2000)
        libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x401fa000)
        libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x4020e000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40253000)
        libc.so.6 => /usr/lib/libc.so.6 (0x402f8000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)


  So, my question is: Are there any Linux Snd users out there who have
worked with anything in the Listener window ? If so, how did you get it
to work ? I really need to make it happen here, I want to report on
Snd's extensibility which seems mostly to require the Listener.

  Btw, I'm running a Red Hat 5.2 system, 2.0.36 kernel, and LessTif 0.89
(the latest release).

  Any & all help will be vastly appreciated !

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Mon Sep 20 16:32:23 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA02338
	for <slinkp@ulster.net>; Fri, 17 Sep 1999 16:39:36 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA11851 for linux-audio-dev-list; Fri, 17 Sep 1999 15:43:30 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA11848 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 17 Sep 1999 15:43:25 -0400
Received: from localhost.localdomain (d212-151-89-168.swipnet.se [212.151.89.168]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id VAA23390 for <linux-audio-dev@ginette.musique.umontreal.ca>; 
          Fri, 17 Sep 1999 21:39:31 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Plug-in API progress?
Date: Fri, 17 Sep 1999 20:47:15 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <99091721453302.00461@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id VAA23390
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id QAA02338
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 33392286dc6700a650367aa548ef978a

Hi folks!

Back from Malta, and it's friday. :-)

Unfortunately, I had too many things to take care of before I left, so I didn't
get any time to get the "real" event system proposal together. I'll play some
with it this weekend.

Actually, I was just wondering if anything interesting has happened these last
two weeks, and if anyone has some nice ideas about dynamic size of events,
strings and those issues.

What I want is a system that can be handled with inline macros, or directly by
user code (clean and extensible on the _binary_ level, that is); that can be
routed between plug-ins efficiently (sorting according to destination and time
etc); that is flexible enough to handle just about any kind of message a
plug-in or a client application might want to send. And of course, it should
be fast and efficient... Simple, eh? ;-)


Just some thoughts for now:

Event port addressing. Or; "How do I find the reciever of my event, and how do
I encode that address into the event?"

So far, I've been thinking along the lines of a DNS + IP style system. That
is, when you create a plug-in, you get a full "address", derived from the
plug-in class name or ID, an instance identifier, and a real Event Port Handle.

(Actually, I'm considering separating Event Ports from plug-in instances, so
that a plug-in can have any number of ports. Not sure if *that's* the right way
to handle things like multitimbral synths, or if the MIDI-like events should
have a channel field. The later sounds better right now... Other ideas?)

Anyway, the Event Port Handle (unsigned int) is what you use to address an
event to a specific port. (It should be safe to send events to ports that don't
exist and that kind of things, to make the system more fault tolerant.)

The handles should be arranged in a way that lets you send the same event to a
group of ports, kind of like IP broadcasting. Not sure if the broadcast
addressing scheme should be multidimensional (ie multiple ways of selecting
groups existing in parallel), or if it's even truly useful. Just an idea,
this broadcasting thing... Either it's just silly, or I forgot what I had in
mind when I first thought of it. If it can't be implemented efficiently, I
think it should be dropped.


Hmm... *thinking. beware: weird ideas may follow...*

Earlier, I think I mentioned using one input buffer and one output buffer for
events. Well, I think there's a better way.

Every Event Port has an input event buffer.

That is, sending an event to some port means finding that port, finding out
where the event buffer currently ends, and then append your events there. No
routing - the sender decides where to send each event.

An event port should be a simple structure to which you can save a pointer
that's safe to use throughout the lifetime of the port. A port struct cannot be
removed before everyone have released it, of course. Performance... Sending
some events would mean some two or three pointer indirections and writing a few
bytes of data for each event.

The events in an Event Port input buffer will, in most cases, have to be sorted
according to the time stamps before scanning the buffer, but that depends on
the nature of the plug-in. Some plug-ins may do the job more efficiently by
sorting on the fly while processing (no need to process buffers from start to
end in all cases), so this should be an optional service in the plug-in host.

Oh, of course, the address field in events should still be there, as it's used
to hold the _reply_ address when the event is delivered. That reply address can
be set to just about anything, but would usually be the address of a port
belonging to the sender of the [request] event.

Unless I mentioned that before: "Request Events" are what I plan to use
instead of the set/get property system used by most plug-in systems. That is,
read/write MIDI controllers. For immediate replies, call process_events() (or
whatever) instead of process() right after sending your request events.
(BTW, process_events() is how plug-in initialization will be handled, as I'd
like to use events all the way through, while a call to process() before init
would be fatal...)


Well, now that I've caused a decent amount of chaos in your minds, I'll get on
with some actual header hacking. :-)


Regards,


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Mon Sep 20 16:32:22 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA29558
	for <slinkp@ulster.net>; Fri, 17 Sep 1999 15:49:38 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA11775 for linux-audio-dev-list; Fri, 17 Sep 1999 14:53:48 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA11772 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 17 Sep 1999 14:53:45 -0400
Received: from someip.ppp.op.net (d-bm3-0e.ppp.op.net [209.152.194.78]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id OAA04823; Fri, 17 Sep 1999 14:49:47 -0400 (EDT)
Message-Id: <199909171849.OAA04823@renoir.op.net>
To: Dave Phillips <dlphilp@bright.net>
cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>,
        cmdist@ccrma.Stanford.EDU, pbd@renoir.op.net
Subject: Re: [linux-audio-dev] Linux, Snd, LessTif, and Scheme 
In-reply-to: Your message of "Fri, 17 Sep 1999 10:25:51 EDT."
             <37E24F6F.5290F5B3@bright.net> 
Date: Fri, 17 Sep 1999 14:55:27 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4b5420938c372562837f7e7561efccbb

Dave - I use snd-3 with the latest LessTif 0.89, and I get the same
behaviour as you. This doesn't help much, but I thought a confirmation
would be nice.

BTW, Bill has my patches to add ALSA support to snd. There's no
support for the mixer (its way to complex right now), but record and
playback work just fine.

--yours in snd-itude (imagine orson welles saying: "probably the best
	                                  sound editor on the planet")
--p

From - Mon Sep 20 16:32:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA19945
	for <slinkp@ulster.net>; Fri, 17 Sep 1999 19:34:44 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA12184 for linux-audio-dev-list; Fri, 17 Sep 1999 18:47:29 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id SAA12181 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 17 Sep 1999 18:47:22 -0400
From: est@hyperreal.org
Received: (qmail 23452 invoked by uid 162); 17 Sep 1999 22:42:17 -0000
Message-ID: <19990917224217.23451.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] Linux, Snd, LessTif, and Scheme
In-Reply-To: <37E24F6F.5290F5B3@bright.net> from Dave Phillips at "Sep 17, 1999
 10:25:51 am"
To: Dave Phillips <dlphilp@bright.net>
Date: Fri, 17 Sep 1999 15:42:17 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4739f191cb34c6c7cbc9a9ffbfe9a630

Dave Phillips discourseth:
> Greetings:
> 
>   I compile Snd myself using snd.tar.gz and I've had no trouble using
> 'configure' or any other part of the make process. Snd appears to work
> fine, except for one small (well, not so small) problem.
> 
>   I can't use the Listener.

Bill suggested using the statically linked binary on the ftp site.
You'll need glibc-2.1 though.

Eric

From - Mon Sep 20 16:32:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA19359
	for <slinkp@ulster.net>; Sat, 18 Sep 1999 12:06:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA13617 for linux-audio-dev-list; Sat, 18 Sep 1999 11:12:15 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA13614 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 18 Sep 1999 11:12:12 -0400
Received: from trkkazulu (d212-151-170-150.swipnet.se [212.151.170.150]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id RAA04354; 
          Sat, 18 Sep 1999 17:08:12 +0200 (MET DST)
Message-ID: <000d01bf01ea$e16aa160$96aa97d4@trkkazulu>
From: "Jair-Rohm" <gtc@mbox200.swipnet.se>
To: <linux-audio-dev@ginette.musique.umontreal.ca>,
        "java list" <to.java-list@vinny.bridgeport.edu>
Subject: [linux-audio-dev] digital audio app...
Date: Sat, 18 Sep 1999 17:30:35 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000A_01BF01FB.842E2920"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 36f20ddab7de79d472d14bdc432e4e3c

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01BF01FB.842E2920
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

High;

I'm trying to write an application that will be able to process digital =
audio in real time. I'm kind of new to Java programming so i'm =
struggling every step of the way. I would really like to do this =
application in Java rather than C/C++ because (after doing a comparison =
of the three languages) i believe Java has tremendous advantages over =
most modern programming languages.=20

Now to the point of this posting...

I started this project as an application. I am beginning to wonder if it =
is possible (using the .sun classes) to perform manipulations on an =
audio file such as play it backwards. As far as i can ascertain, i would =
have to convert the sound (AudioDataStream) to a ByteArrayInputStream in =
order to have the sound available as an array of bytes that i may later =
have my way with. Unfortunately, i've not been able to mange this =
conversion. Is it possible that this type of manipulation is only =
possible from within an Applet? I'm developing in Blackdown 1.1.7 using =
GNU Emacs with the JDE.

Any insights, suggestions and/or help would be greatly appreciated.=20

Thanks;

Jair-Rohm

------=_NextPart_000_000A_01BF01FB.842E2920
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#c0c0c0>
<DIV><FONT color=3D#000000>High;</FONT></DIV>
<DIV><FONT color=3D#000000></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000>I'm trying to write an application that will =
be able to=20
process digital audio in real time. I'm kind of new to Java programming =
so i'm=20
struggling every step of the way. I would really like to do this =
application in=20
Java rather than C/C++ because (after doing a comparison of the three =
languages)=20
i believe Java has tremendous advantages over most modern programming =
languages.=20
</FONT></DIV>
<DIV><FONT color=3D#000000></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000>Now to the point of this =
posting...</FONT></DIV>
<DIV><FONT color=3D#000000></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000>I started this project as an application. I =
am=20
beginning to wonder if it is possible (using the .sun classes) to =
perform=20
manipulations on an audio file such as play it backwards. As far as i =
can=20
ascertain, i would have to convert the sound (AudioDataStream) to a=20
ByteArrayInputStream in order to have the sound available as an array of =
bytes=20
that i may later have my way with. Unfortunately, i've not been able to =
mange=20
this conversion. Is it possible that this type of manipulation is only =
possible=20
from within an Applet? I'm developing in Blackdown 1.1.7 using GNU Emacs =
with=20
the JDE.</FONT></DIV>
<DIV><FONT color=3D#000000></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000>Any insights, suggestions and/or help would =
be greatly=20
appreciated. </FONT></DIV>
<DIV><FONT color=3D#000000></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000>Thanks;</FONT></DIV>
<DIV><FONT color=3D#000000></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000>Jair-Rohm</FONT></DIV></BODY></HTML>

------=_NextPart_000_000A_01BF01FB.842E2920--

From - Mon Sep 20 16:32:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA05303
	for <slinkp@ulster.net>; Sat, 18 Sep 1999 15:59:30 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA14005 for linux-audio-dev-list; Sat, 18 Sep 1999 15:26:57 -0400
Received: from vcn.bc.ca (vcn.bc.ca [207.102.64.2]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA14002 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 18 Sep 1999 15:26:53 -0400
Received: from localhost (ivar@localhost)
	by vcn.bc.ca (8.9.2/8.9.2) with ESMTP id MAA11491;
	Sat, 18 Sep 1999 12:23:00 -0700 (PDT)
Date: Sat, 18 Sep 1999 12:23:00 -0700 (PDT)
From: Ivar Vasara <ivar@vcn.bc.ca>
To: Jair-Rohm <gtc@mbox200.swipnet.se>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] digital audio app...
In-Reply-To: <000d01bf01ea$e16aa160$96aa97d4@trkkazulu>
Message-ID: <Pine.GSO.4.10.9909181209350.6201-100000@vcn.bc.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0d33dd3d537b1fde6b797a0fcc29263e

	If you're interested in creating sound applications under Java,
it's highly recommended that you use Java 1.2 as there is a 'new' sound
API.. though you might want to keep an eye on the jdk1.3 with even
more sound extensions (though it will be a while before it comes out on
Linux since 1.2 isn't even out of beta..)
	Also there's the new Java Media Framework 2.0 that was very
recently released.. it has a plugin ability that provide all kinds of
interesting tools (ie: quicktime, real media G2, etc..) to play with in one's
quest for the ultimate audio app.. no native MP3 support announced though
:( 

Java Media Framework FAQ
http://java.sun.com/products/java-media/jmf/forDevelopers/jmffaq.html

Java Sound API
http://java.sun.com/products/java-media/sound/

Regards,
	Ivar

From - Mon Sep 20 16:32:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA10321
	for <slinkp@ulster.net>; Sun, 19 Sep 1999 00:08:56 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA14606 for linux-audio-dev-list; Sat, 18 Sep 1999 23:23:27 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA14603 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 18 Sep 1999 23:23:25 -0400
Received: from sin.CS.Princeton.EDU (sin [128.112.4.5])
	by CS.Princeton.EDU (8.9.3/8.9.3) with SMTP id XAA16623
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 18 Sep 1999 23:18:23 -0400 (EDT)
Received: from localhost by sin.CS.Princeton.EDU (8.6.12) id XAA22080; Sat, 18 Sep 1999 23:18:22 -0400
Date: Sat, 18 Sep 1999 23:18:13 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] digital audio app...
In-Reply-To: <000d01bf01ea$e16aa160$96aa97d4@trkkazulu>
Message-ID: <Pine.OSF.4.04.9909182302170.22054-100000@sin.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 140cde043449f18660061d850d11ba17

On Sat, 18 Sep 1999, Jair-Rohm wrote:

> I started this project as an application. I am beginning to wonder if
> it is possible (using the .sun classes) to perform manipulations on an
> audio file such as play it backwards. As far as i can ascertain, i
> would have to convert the sound (AudioDataStream) to a
> ByteArrayInputStream in order to have the sound available as an array
> of bytes that i may later have my way with. Unfortunately, i've not
> been able to mange this conversion. Is it possible that this type of
> manipulation is only possible from within an Applet? I'm developing in
> Blackdown 1.1.7 using GNU Emacs with the JDE.

You're in for quite a lot of pain if you want to do audio with pure Java.
You proposed using the sun.audio* classes, but they are (1) only available
when running on a true Sun branded JVM (not Borland, Microsoft, Symantec,
etc); (2) only availble in applications, not applets; (3) not documented,
promised for future compatibility, or officially supported by Sun; (4)
severely limited by an arbitrarily low maximum sampling rate; and (5) only
good for sample playback, not for streaming or sample manipulation.  If
you absolutely must use them, then only use them for post-mixdown
playback; ie: read the sound files manually using your own parser, do your
manipulations on them as byte arrays, then convert to sun.audio*
structures at the last minute (writing out temp files and reading them
back in using the sun.audio* API if necessary).  

If this sounds as terrible to you as it did to me, you might be tempted
to switch to the "new" Java Media Framework.  This, however, has been
promised by Sun for a minimum of three years and was never delivered.  I
have given up all hope of them ever making good on this vaporware.

Sadly, JNI starts to look attractive in this situation, even though that
breaks with the nice run-anywhere dream.

A little disclaimer: my data on all I just said is somewhat out of date...
as I said, I gave up on Sun fixing the problems some time back, after they
slowrolled too long.  Hopefully the situation is not as bad today as it
was when I last grappled with it.

I wish you the best of luck,
Div.

P.S.  I haven't given up on Java, and I'm still using it to write music
apps.  However, I no longer have any illusions about being able to do it
without JNI.

From - Mon Sep 20 16:32:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA00621
	for <slinkp@ulster.net>; Sun, 19 Sep 1999 07:17:32 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA15072 for linux-audio-dev-list; Sun, 19 Sep 1999 06:42:34 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA15069 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 19 Sep 1999 06:42:30 -0400
Received: from trkkazulu (d212-151-169-193.swipnet.se [212.151.169.193]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id MAA18669 for <linux-audio-dev@ginette.musique.umontreal.ca>; 
          Sun, 19 Sep 1999 12:38:30 +0200 (MET DST)
Message-ID: <001901bf028e$6047e800$c1a997d4@trkkazulu>
From: "Jair-Rohm" <gtc@mbox200.swipnet.se>
To: <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: SV: [linux-audio-dev] digital audio app...
Date: Sun, 19 Sep 1999 13:01:01 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id HAA00621
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: bae44b20eadaf0e07ba6818e5028cd5e

This is interesting...

Just as i suspected, it isn't possible to manipulate .sun.audio sound files. So much for a stand-alone digital audio app. Then again, there are ways to run an Applet as an application. Could that be a "best of both worlds situation"? What about the latest version of the JMF: is it possible to download these classes and use them with my Blackdown 1.1.3 or 1.1.7?

Have you posted any of your Java music apps? Have you done anything with dsp under Java? Do you use JNI for all of the actual "dirty work" and just use Java for the GUI? Which version of Java are you using under Linux? Have you worked with 1.2 on any other platforms? 


Thanks;

Jair-Rohm 


-----Ursprungligt meddelande-----
Frn: David Slomin <dgslomin@CS.Princeton.EDU>
Till: linux-audio-dev@ginette.musique.umontreal.ca <linux-audio-dev@ginette.musique.umontreal.ca>
Datum: Sunday, September 19, 1999 05:21
mne: Re: [linux-audio-dev] digital audio app...


>On Sat, 18 Sep 1999, Jair-Rohm wrote:
>
>> I started this project as an application. I am beginning to wonder if
>> it is possible (using the .sun classes) to perform manipulations on an
>> audio file such as play it backwards. As far as i can ascertain, i
>> would have to convert the sound (AudioDataStream) to a
>> ByteArrayInputStream in order to have the sound available as an array
>> of bytes that i may later have my way with. Unfortunately, i've not
>> been able to mange this conversion. Is it possible that this type of
>> manipulation is only possible from within an Applet? I'm developing in
>> Blackdown 1.1.7 using GNU Emacs with the JDE.
>
>You're in for quite a lot of pain if you want to do audio with pure Java.
>You proposed using the sun.audio* classes, but they are (1) only available
>when running on a true Sun branded JVM (not Borland, Microsoft, Symantec,
>etc); (2) only availble in applications, not applets; (3) not documented,
>promised for future compatibility, or officially supported by Sun; (4)
>severely limited by an arbitrarily low maximum sampling rate; and (5) only
>good for sample playback, not for streaming or sample manipulation.  If
>you absolutely must use them, then only use them for post-mixdown
>playback; ie: read the sound files manually using your own parser, do your
>manipulations on them as byte arrays, then convert to sun.audio*
>structures at the last minute (writing out temp files and reading them
>back in using the sun.audio* API if necessary).  
>
>If this sounds as terrible to you as it did to me, you might be tempted
>to switch to the "new" Java Media Framework.  This, however, has been
>promised by Sun for a minimum of three years and was never delivered.  I
>have given up all hope of them ever making good on this vaporware.
>
>Sadly, JNI starts to look attractive in this situation, even though that
>breaks with the nice run-anywhere dream.
>
>A little disclaimer: my data on all I just said is somewhat out of date...
>as I said, I gave up on Sun fixing the problems some time back, after they
>slowrolled too long.  Hopefully the situation is not as bad today as it
>was when I last grappled with it.
>
>I wish you the best of luck,
>Div.
>
>P.S.  I haven't given up on Java, and I'm still using it to write music
>apps.  However, I no longer have any illusions about being able to do it
>without JNI.
>
>

From - Wed Sep 22 01:29:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA18815
	for <slinkp@ulster.net>; Tue, 21 Sep 1999 12:21:34 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA20272 for linux-audio-dev-list; Tue, 21 Sep 1999 11:10:56 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA20269 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 21 Sep 1999 11:10:52 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S9927AbPIUPGe>; Tue, 21 Sep 1999 18:06:34 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: alsa-devel@alsa-project.org, linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <19990921103237.A370@nevermind.tu-berlin.de> (message from
	Carsten Pfeiffer on Tue, 21 Sep 1999 10:32:37 +0200)
Subject: [linux-audio-dev] Re: [alsa-devel] AudioServer Standard? (fwd)
Message-Id: <19990921150636Z9927-16539+2266@nic.funet.fi>
Date:   Tue, 21 Sep 1999 18:06:34 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: e591895aba3dacbb2057bcd2d7df5afe

>both KDE and GNOME are looking for/working on an audioserver - maybe the
>gnome-kde-list would be a good place to discuss all those
>audioserver-issuses that recently arose here?

Please forward discussions to linux-audio-dev or to here alsa-dev.

People there seem to talk which existing program would be used as
audio server. I really hope they will discuss about possible the API
standard and not just satisfy to existing ones.

I suggest the discussion is moved to linux-audio-devel list too.
Please notify KDE/GNOME people.

Yours,

Juhana

From - Wed Sep 22 01:29:36 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA20575
	for <slinkp@ulster.net>; Tue, 21 Sep 1999 12:33:19 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA20304 for linux-audio-dev-list; Tue, 21 Sep 1999 11:40:57 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA20301 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 21 Sep 1999 11:40:54 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S10025AbPIUPg3>; Tue, 21 Sep 1999 18:36:29 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <99091721453302.00461@localhost.localdomain> (message from David
	Olofson on Fri, 17 Sep 1999 20:47:15 +0200)
Subject: Re: [linux-audio-dev] Plug-in API progress?
Message-Id: <19990921153635Z10025-16539+2267@nic.funet.fi>
Date:   Tue, 21 Sep 1999 18:36:29 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 381176ecfd48937c10e588ddc431c0e9

>From:   David Olofson <audiality@swipnet.se>
>
>Back from Malta, and it's friday. :-)

Welcome back! I have updated my GASP pages to have a list of commercial
API resources (see the section "APIs" in the list of commercial softwares;
http://www.funet.fi/~kouhia/gasp/).

I have an idea: the discussion goes to quite deep matters but we could
in the first place make a quite simplified plug-in API. So that, it
doesn't take two years yet again before we have the plug-in API.

We basically need input and output connections. For audio data, they
will be buffers of the given length -- processing is done from input
buffer to output buffer. For control data, they will be either buffers,
event lists, or static data.

Some commercial plug-ins indeed have a GUI for drawing curves and so on.
We could agree type of those curves and curves would be given to the
plug-in (as static data or as event at run-time) instead of plug-in
allowing the user to draw them.

We could assume the plug-ins are included at compile time. So, no GUI
or names are needed. The programmer looks the inputs and outputs from
the plug-in reference book.

This would be easy to do and the plug-in development could go on
immediately. At least Quasimodo needs GPLed opcodes to replace the
original opcodes and this would be a good place to make the opcodes
available for any audio software.

Here is my rough try on this. This looks so simple that you should look
if I just have goofed. This is *not* the final version we have to think
about good structure and field names and their final types.


#define PLUGIN_INOUTTYPE_NONE 0
#define PLUGIN_INOUTTYPE_BUFFER 1
#define PLUGIN_INOUTTYPE_EVENTLIST 2
#define PLUGIN_INOUTTYPE_STATIC 3

struct {
  int begintimeoftheplugincall;
  int inouttype;
  char *buffer;
  int numberofsamplesinbuffer;
  event **eventlist; /* buffer of pointers to events */
  int numberofevents;
  void *static;
} inout;

struct {
  int time;
        what to put here?? int idata, float fdata, char *anydata?
} event;


The effect has a data structure:
  f = (filter *)malloc(sizeof(filter));
and default values:
  filter_setsamplerate(f,44100);
  filter_setfreq(f,400.0);
  filter_setboost(f,-20.0);
and if plug-in is general:
  filter_setchannels(f,2);
  filter_sampletype(f,SAMPLETYPE_FLOAT);

The runtime call would be
  filter_do(f,inout *input, inout *output, inout *freq, inout *boost);
where input and output would get buffers and where freq and boost would
get events.

We could agree the static and event curve data is a polyline, and that
the plug-in decides if the curve is actually polyline or spline. So that
it is safe for a plug-in to send polylines to parameter port of the next
plug-in.

By anyway, if this discussion made you think a better simple plug-in API,
will it be only good because we need fast suggestions for this quickly
written simple plug-in API.

I propose that we *end the discussion* on this simple plug-in API
at **October 11**. Then I will write my current set of filters to conform
this simple API and will call plug-in writers.

October 11, that is it!

Yours,

Juhana

From - Wed Sep 22 01:30:01 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA17934
	for <slinkp@ulster.net>; Tue, 21 Sep 1999 19:02:05 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA21028 for linux-audio-dev-list; Tue, 21 Sep 1999 18:17:35 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA21025 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 21 Sep 1999 18:17:31 -0400
Received: from localhost.localdomain (d212-151-32-55.swipnet.se [212.151.32.55]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA14354; 
          Wed, 22 Sep 1999 00:13:25 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Juhana Sadeharju <kouhia@nic.funet.fi>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Plug-in API progress?
Date: Tue, 21 Sep 1999 22:56:19 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <19990921153635Z10025-16539+2267@nic.funet.fi>
MIME-Version: 1.0
Message-Id: <99092200193603.00438@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id AAA14354
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA17934
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 741c0dd6fc60e4736ff755d8cf506d64

On Tue, 21 Sep 1999, Juhana Sadeharju wrote:
> >From:   David Olofson <audiality@swipnet.se>
> >
> >Back from Malta, and it's friday. :-)
> 
> Welcome back!

Thanks!

> I have updated my GASP pages to have a list of commercial
> API resources (see the section "APIs" in the list of commercial softwares;
> http://www.funet.fi/~kouhia/gasp/).

I'll have a look. :-)

> I have an idea: the discussion goes to quite deep matters but we could
> in the first place make a quite simplified plug-in API. So that, it
> doesn't take two years yet again before we have the plug-in API.

...and when we have finally finished this ultimate API, we realize it's too
complex, too inefficient, and just not good! *hehe*

Yes, I think developing a basic API to get started is a good idea. We'll get
some actual code to test our ideas on, and we'll also get a chance to get more
real life facts rather than making important design decisions through qualified
guessing...

> We basically need input and output connections. For audio data, they
> will be buffers of the given length -- processing is done from input
> buffer to output buffer. For control data, they will be either buffers,
> event lists, or static data.

Conditional code is complex and expensive. I think the low level data flow
should consist of only two data types: raw data and events. What actual data
formats we're really dealing with will be hardcoded in the plug-ins anyway, and
there's not really any other way to do it without wasting performance, and
complicating the code. And the engine only needs to keep track of buffer sizes
and events, as it's not supposed to mess with the data directly.

Static data? Isn't a single out-of-band event enough, or are we thinking about
different things?

(Anyway, we're perhaps thinking along the same lines - I just want to make sure
we reduce the API to the "narrowest cut", if you know what I mean... Few
but useful features.)

> Some commercial plug-ins indeed have a GUI for drawing curves and so on.
> We could agree type of those curves and curves would be given to the
> plug-in (as static data or as event at run-time) instead of plug-in
> allowing the user to draw them.

Basically, GUI is a different part of the system. I think defining the GUI API
as a subset of the plug-in API (most importantly featuring the event system)
would be a pretty flexible way to do it, as that means the developers only need
to learn one API. The GUI engine would be very similar to an in-application
plug-in host. It would be possible to hack a standard GUI plug-in that works
somewhat like the simple string based user interface stuff of VST, so that
plug-ins can instantiate, initialize and control basic GUIs via the event
system. Whether you want to hack that GUI control code directly into the
processing code, or into a separate module is up to you.

The point is that this way, it can all be done without extendning the plug-in
API. All you have to do is allowing certain kinds of plug-ins to use
functionality outside the plug-in API. GUI plug-ins can use X, while processing
plug-ins aren't allowed to touch *anything* but the stuff defined in the
plug-in API. First of all good programming style, but it also happens to fit
well with real time programming in general, and RTLinux programming in
particular. (That is, plug-ins will compile and run under RTL right away if
that rule is followed.)

> We could assume the plug-ins are included at compile time. So, no GUI
> or names are needed. The programmer looks the inputs and outputs from
> the plug-in reference book.

Saves some work perhaps, but I'm not sure. (Ok, there is a problem with .so
linking and name space...)

> This would be easy to do and the plug-in development could go on
> immediately. At least Quasimodo needs GPLed opcodes to replace the
> original opcodes and this would be a good place to make the opcodes
> available for any audio software.

Yes, anything to make reuse of code easier is very good, even if it's just on
the source level for now.

> Here is my rough try on this. This looks so simple that you should look
> if I just have goofed. This is *not* the final version we have to think
> about good structure and field names and their final types.
> 
> 
> #define PLUGIN_INOUTTYPE_NONE 0

For padding or what...?

> #define PLUGIN_INOUTTYPE_BUFFER 1
> #define PLUGIN_INOUTTYPE_EVENTLIST 2

Another way to handle Event Ports (as I call them for now) is like something
you create during the instantiation of a plug-in (create any number you need).
Don't know if there's really much point in having multiple event inputs on a
single plug-in... (With my system, you can see where events come from anyway,
if your plug-in needs to keep track of multiple event sources.)

> #define PLUGIN_INOUTTYPE_STATIC 3

> struct {
>   int begintimeoftheplugincall;
>   int inouttype;
>   char *buffer;

Do you put multiple channels in the same buffer here?

>   int numberofsamplesinbuffer;
>   event **eventlist; /* buffer of pointers to events */
>   int numberofevents;
>   void *static;
> } inout;
> 
> struct {
>   int time;
>         what to put here?? int idata, float fdata, char *anydata?
> } event;

How about
	int	time;
	int	code;		/* What is this? */
	int	from;		/* Who is this from? */
	int	size;		/* Number of data bytes */
	/* dynamic size data follows... */
?

Or we could just leave out the dynamic size part for now and throw in a couple
of ints or something. But I think I'll get something useful together this week,
so we might be able to have dynamic event size from the start. (Less to change
in the plug-in code, but it is a little more complex, of course. I'll hack some
nice macros to encapsulate it, though, so it might not make much of a
difference in the end.)

(Benno: I'm starting to think one time stamp/event is pretty reasonable in most
real life situations...)

> The effect has a data structure:
>   f = (filter *)malloc(sizeof(filter));
> and default values:
>   filter_setsamplerate(f,44100);
>   filter_setfreq(f,400.0);
>   filter_setboost(f,-20.0);
> and if plug-in is general:
>   filter_setchannels(f,2);
>   filter_sampletype(f,SAMPLETYPE_FLOAT);

One of my latest wild ideas it to replace this entirely with the event system.
No struct, just a callback function that the engine asks about properties when
instantiating a plug-in, or just wants some general info anout the plug-in
class. Very flexible, and no structure to extend as new things must be
supported... (And of course, it's yet another ++usecount for my Universal
Solution; the Event System. ;-)

> The runtime call would be
>   filter_do(f,inout *input, inout *output, inout *freq, inout *boost);
> where input and output would get buffers and where freq and boost would
> get events.

I think
	filter_do(f, void **inputs, void **outputs, event **events);
will do.

The plug-in won't have to check and decode the contents of a structure for
each buffer and call - the engine will send events to tell the plug-in about
any buffer size changes and that kind of things.

Also, no output buffer for events. You'll just have to keep track of the Event
Ports you want to send to occasionally, unless you're just going to reply to
events you recieve.

> We could agree the static and event curve data is a polyline, and that
> the plug-in decides if the curve is actually polyline or spline. So that
> it is safe for a plug-in to send polylines to parameter port of the next
> plug-in.

Yeah, but there's a slight timing problem here; how do you know where you're
headed before you've recieved the next point? Staying one or two events behind
isn't exactly good timing... It'll have to be events with destination values
and times, and prediction for true real time. How the curves are rendered is of
course up to the plug-in.

> By anyway, if this discussion made you think a better simple plug-in API,
> will it be only good because we need fast suggestions for this quickly
> written simple plug-in API.

Well, even if my event system might be more complex than what you had in mind,
I think we'll save time if we can use it as the single way of communication
except for raw data. And, perhaps there's a better chance we'll come closer to
the final API that way, as we won't have structures with lots of fields
describing the details about things that are likely to change.

But I'll hack on, and see how it turns out...

> I propose that we *end the discussion* on this simple plug-in API
> at **October 11**. Then I will write my current set of filters to conform
> this simple API and will call plug-in writers.
> 
> October 11, that is it!

Sounds reasonable, I think.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Sep 22 01:29:58 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA12574
	for <slinkp@ulster.net>; Tue, 21 Sep 1999 18:28:22 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA20946 for linux-audio-dev-list; Tue, 21 Sep 1999 17:43:04 -0400
Received: from gauss.deltav.hu (gauss.deltav.hu [194.9.64.225]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA20943 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 21 Sep 1999 17:43:00 -0400
Received: from cerealbox (84.dial02.deltav.hu [194.9.64.84])
          by gauss.deltav.hu (Netscape Messaging Server 3.6)  with ESMTP
          id AAA42FA for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Tue, 21 Sep 1999 23:42:06 +0200
Received: from reactor by cerealbox with local (Exim 1.92 #1 (Debian))
	id 11TXif-000060-00; Tue, 21 Sep 1999 23:45:01 +0200
Message-ID: <19990921234501.A365@cerealbox>
Date: Tue, 21 Sep 1999 23:45:01 +0200
From: reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] gAlan
Reply-To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.91.2
Organization: CTP media laboratories
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: b0ad8d1b773bd2a5745fe32e8f224b5c

yo!

has anyone tried gAlan? it seems like the project i wanted to make.
my only problem is, that it segfaults on anything i do :)))))
it contains plugins, maybe the source is worth checking out.

url: http://homepages.ihug.co.nz/~surazal/galan-0.2.0.tar.gz

-- 

  Mt Rcz a.k.a. reactor  -  http://linux.gyakg.u-szeged.hu/~reactor/
   CTP media - since 1995   -  http://ctpmedia.scene.hu/

From - Wed Sep 22 01:29:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA10911
	for <slinkp@ulster.net>; Tue, 21 Sep 1999 18:17:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA20887 for linux-audio-dev-list; Tue, 21 Sep 1999 17:12:48 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA20884 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 21 Sep 1999 17:12:40 -0400
Received: from someip.ppp.op.net (d-bm3-1d.ppp.op.net [209.152.194.93]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id RAA25555 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 21 Sep 1999 17:08:22 -0400 (EDT)
Message-Id: <199909212108.RAA25555@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: Plug-in API progress? 
In-reply-to: Your message of "Tue, 21 Sep 1999 18:36:29 +0300."
             <19990921153635Z10025-16539+2267@nic.funet.fi> 
Date: Tue, 21 Sep 1999 18:04:06 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: b5c9adbbda7394cd9f2793f64892bdc8

>Here is my rough try on this. This looks so simple that you should look
>if I just have goofed. This is *not* the final version we have to think
>about good structure and field names and their final types.

I think you should look more closely at Csound (and by extension,
Quasimodo's) call interface for opcodes, which is very similar to the
one used by SuperCollider.  The generic name for it is "closures". A
closure is a piece of memory that contains all the information
necessary to run a function.

You allocate a piece of heap (size specified by the functions call
interface), then stick pointers to the arguments arguments into
the heap so that it vaguely resembles a stack. Then you pass this
closure to the function. You keep the closure around for further
calls. 

Its phenomenally efficient. Note that all this has been done already
in Csound and Quasimodo. There are more than 400 "plugins" in both
systems that use this kind of interface. It can be done neater than
Csound did it, because there is no need for source-level
compatibility. But the basic idea of a closure is well worth checking
out, and needs a strong argument (IMHO) if it is not to be used.

--p

ps. Going slightly off the wall, I think that you handle the GUI element
of a plugin API by dynamically compiling the plugin. That is, a plugin
consists of at least one .c and zero or more .h files. Any machine
fast enough to run this kind of stuff can compile this kind of code is
a second or less. Then, the plugin can use native GUI code (eg. Gnome,
or GTK or whatever), and not be limited by whatever facilities the
engine provides in this regard. This is a feature I would like to add
to Quasimodo in the distant future.

pps. here's some more details. This doesn't take care of some of the
global stuff that Juhana's API suggestion contains - thats intended to
be handled by the basic_closure struct, which can contain anything you
want. 

As an example, consider a delay plugin with a two parameters: the
delay in msecs (as a float) and the wet/dry ratio as a float from 0 to
1.

Using a mix of C, C++ and psuedo-code:

struct delay_args : struct basic_closure {
       float dtime;
       float msecs;
       .
       .
       .
};

{ "delay", delay, sizeof (delay_args), "ff" }
  
  ^^^^^^
  name of plugin

           ^^^^^^
	   function to call 


		 ^^^^^^^^^^^^^^^^^^^^
		 closure size
		                      ^^^^^^
				      argument format

So, to use this plugin you:

1) allocate storage for its parameters ("ff") (the GUI aspect has
   to define human-usable names for them; we'll use "dtime" and "mix")
2) allocate sizeof(delay_args) bytes
3) setup the basic_closure portion of the closure:

       closure->func = delay;
       closure->size = sizeof (delay_args) + sizeof (basic_closure);
       closure->output_buffer = output_buf;
       closure->input_buffer = input_buf;
       .
       .
       .  

	/* whatever else all closures need */  
 
4) marshall the args:

       argnum = 0;

       switch (interface->arg_format[i]) {

              case 'f':
               ((float *) &(((unsigned char) closure)+
	                     sizeof(basic_closure)+(sizeof (float)*argnum))) 
			     = ??;
       
5) then, whenever its necessary to invoke it:

       *(closure->func)(closure);

Inside the function "delay", the code looks like this:

void
delay (delay_args *ptr)

{
	float dtime;
	float msecs;
	sample_t *output_buf;
	sample_t *input_buf;
	.
	.
	.

	dtime = *ptr->dtime;
	msecs = *ptr->msecs;

	/* do something useful, put results in ptr->output_buf */

}

From - Wed Sep 22 01:30:11 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA23374
	for <slinkp@ulster.net>; Tue, 21 Sep 1999 19:38:12 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA21057 for linux-audio-dev-list; Tue, 21 Sep 1999 18:45:56 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA21054 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 21 Sep 1999 18:45:49 -0400
Received: from localhost.localdomain (d212-151-32-55.swipnet.se [212.151.32.55]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA05726; 
          Wed, 22 Sep 1999 00:41:41 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Date: Wed, 22 Sep 1999 00:29:48 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199909212108.RAA25555@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99092200475204.00438@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id AAA05726
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA23374
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3240cf0272f92f543481309201f59b65

On Wed, 22 Sep 1999, Paul Barton-Davis wrote:
[...]
> ps. Going slightly off the wall, I think that you handle the GUI element
> of a plugin API by dynamically compiling the plugin.

That's useful, but it mustn't under any circumstances be the only way to do it,
as that rules out proprietary plug-ins. I hardly think it will be easier to get
the Big Guys to port plug-ins if they have to release even the GUI source.

However, some hybrid solution might be a way to get fast native GUIs without
the need for real source code... And there's always to "multiple binaries"
solution, which could still be a lot nicer than what developers have to face
with existing systems. Needing only to compile (and not rewrite) the GUI code
for different platforms would be a big improvement.

[...closure based plug-in example...]

I like it. And it kind of fits well together with the fully event based
instantiation procedure I had in mind... The details of how the plug-in wants
to keep track of state info etc can be hidden from the engine, which means
that the public part of a closure (previously: plugin instance struct) can be
kept very simple without limiting the capabilities of the plug-in API. Have to
think more about this... But I'll post some more ideas on the event system
first.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Sep 22 01:30:18 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA08508
	for <slinkp@ulster.net>; Tue, 21 Sep 1999 21:28:31 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA21220 for linux-audio-dev-list; Tue, 21 Sep 1999 20:44:10 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA21217 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 21 Sep 1999 20:44:06 -0400
Received: from localhost.localdomain (d212-151-32-55.swipnet.se [212.151.32.55]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA00413 for <linux-audio-dev@ginette.musique.umontreal.ca>; 
          Wed, 22 Sep 1999 02:40:04 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Some Event stuff for now...
Date: Wed, 22 Sep 1999 02:26:14 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <99092202461305.00438@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id CAA00413
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA08508
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 368c873156f64f27498abdf58b08b386

Hi...

Here's a part of the current version of my Event System proposal. I think the
stuff I'm building around this will be more interesting, but I really have to
get some sleep now, so this will have to do for now... Hope you get the idea.

Perhaps I should point out that I intend to use an optimized memory allocation
system with allocation + "flush all" operations per heap buffer only. There
will be no dealocation, and no fragmentation. (The engine/plug-in host is
responsible for setting up heaps for sub-nets, so that it can flush them once
per buffer period, or whatever fits the scheduling algorithm.) The heap
definition will be a public structure + macros/inlines for performance, and
should be viewed more like an output buffer on steroids than a real memory
manager.

The reason for using arrays of pointers rather than just events as raw data
written sequentially into the output buffer is on the engine side - merging of
events from multiple sources etc...

/*
 * The engine encode time stamps as samples from
 * start of the timing master buffer, which can be
 * selected by the plug-in.
 * (Alternatively, this could be a float, but I
 * think that should be optional for performance
 * reasons.)
 */
typedef unsigned int event_time_t;

/* For efficient decoding, events are grouped as
 * system, control, gui, custom etc... (Custom is
 * a group that's reserved for private talk between
 * GUI and process() code, and should *not* be used
 * for anything that could make sense to use standard
 * events for.)
 *
 * The EV_FLAGS field is used for telling requests
 * from replies and that kind of things.
 *
 * EV_KIND is the actual event code. Event kinds
 * should be declared as enums for good optimization
 * possibilities in switch() decoding. (That's why
 * there's a CLASS field.)
 */
typedef unsigned int event_code_t;
#define EV_CLASS_MASK    0xff000000 /* TIMING, SYSTEM, CONTROL,... */
#define EV_FLAGS_MASK    0x00ff0000 /* EVENT, REQUEST, REPLY... */
#define EV_KIND_MASK     0x0000ffff /* Exactly what event is this? */

struct event_t;

struct event_port_t {
	int	events;		/* Number of events currently in the buffer */
	int	maxevents;	/* Size of the buffer */
	event_t	**buffer;
};

struct event_t {
	event_time_t	time;
	event_code_t	code;		/* What is this? */
	/* This 'from' field being a pointer to the
	 * Event Port struct of the sender might be
	 * a bit dangerous. (I'm thinking Event Port
	 * lifetime...)
	 */
	event_port_t	*from;		/* Who is this from? */
	int		size;		/* Number of data bytes */
};


(event_t is of course just the header - any number of bytes of data may follow.)

Any ideas about the from field? What I mean is, a simple way of making sure that
no one tries to reply to an event from a port that was just removed? (I think
it'll become clear when dealing with the life time of event buffers. When all
buffers with events from a certain port have been flushed, it's safe to delete
the port - unless some plug-in decides to remember a reply port address for
later use... That should probably not be allowed.)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Sep 22 01:30:23 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA13590
	for <slinkp@ulster.net>; Tue, 21 Sep 1999 21:58:56 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA21320 for linux-audio-dev-list; Tue, 21 Sep 1999 21:17:19 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA21317 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 21 Sep 1999 21:17:16 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id VAA29721
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 21 Sep 1999 21:12:52 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id VAA01962; Tue, 21 Sep 1999 21:12:50 -0400 (EDT)
Date: Tue, 21 Sep 1999 21:12:48 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: SV: [linux-audio-dev] digital audio app...
In-Reply-To: <001901bf028e$6047e800$c1a997d4@trkkazulu>
Message-ID: <Pine.GSO.4.10.9909212050550.28680-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 97357196ddaecc11f8ad1c5a2c2f9285

On Sun, 19 Sep 1999, Jair-Rohm wrote:

> Just as i suspected, it isn't possible to manipulate .sun.audio sound
> files. So much for a stand-alone digital audio app. Then again, there
> are ways to run an Applet as an application. Could that be a "best of
> both worlds situation"? What about the latest version of the JMF: is
> it possible to download these classes and use them with my Blackdown
> 1.1.3 or 1.1.7?

It is indeed possible to have a stand-alone audio app, "simply" by not
using any of Sun's audio classes; write your own using JNI.  If you feel
you must, it is also actually possible to call the "applet-only" sun.audio
classes from an application, but the method of doing so is not documented
nor officially supported.  I used to have an URL for the instructions, but
unfortunately I long since lost it; try an AltaVista search (grin).

I haven't tried the JMF.  I actually didn't know they had any code for you
to download except for an old Windows-only thing from Intel.  Sun's been
posting "proposed specifications" for JFM for years, and I've yet to see
anything usable.

> Have you posted any of your Java music apps? Have you done anything
> with dsp under Java? Do you use JNI for all of the actual "dirty work"
> and just use Java for the GUI? Which version of Java are you using
> under Linux? Have you worked with 1.2 on any other platforms?

Most of my Java/music programming is MIDI related, not audio, so it
probably wouldn't fit your needs.  I have a number of half-finished
efforts strewn around backup disks, but I'm only now closing in on
something releasable in that category, a MIDI sequencer called SongPad.

Recent work I've done has enabled me to actually write the sequencer in
pure Java, sending MIDI messages over sockets rather than trying to talk
directly to the hardware or using a non-portable API.  Unfortunately, this
is not a practical option for audio, which seems to be your primary
interest.  In any event, I'll most likely end up doing it with native
methods anyway, since I don't trust Java's performance.  

My development setup on Linux, OSF, Solaris, and Windows alike is JDK 1.1
with Swing 1.1 added onto it.  I haven't yet played with non-Swing parts
of the "Java 2" platform, so I'm afraid I can't give any recommendations
about whether the other new bits will work with Blackdown; Swing works
fine.

Div.

From - Wed Sep 22 01:30:16 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA08370
	for <slinkp@ulster.net>; Tue, 21 Sep 1999 21:27:47 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA21231 for linux-audio-dev-list; Tue, 21 Sep 1999 20:48:27 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA21228 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 21 Sep 1999 20:48:24 -0400
Received: from someip.ppp.op.net (d-bm3-14.ppp.op.net [209.152.194.84]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id UAA13671 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 21 Sep 1999 20:44:20 -0400 (EDT)
Message-Id: <199909220044.UAA13671@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress? 
In-reply-to: Your message of "Wed, 22 Sep 1999 00:29:48 +0200."
             <99092200475204.00438@localhost.localdomain> 
Date: Tue, 21 Sep 1999 21:40:06 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ebba8db4f7c9e02d41f76ecec9b1b1c5

In message <99092200475204.00438@localhost.localdomain>you write:
>On Wed, 22 Sep 1999, Paul Barton-Davis wrote:
>[...]
>> ps. Going slightly off the wall, I think that you handle the GUI element
>> of a plugin API by dynamically compiling the plugin.

>That's useful, but it mustn't under any circumstances be the only way
>to do it , as that rules out proprietary plug-ins. I hardly think it
>will be easier to get the Big Guys to port plug-ins if they have to
>release even the GUI source.

Agreed. And in fact, on reflection, I now think that dynamic
compilation for the GUI side is unnecessary as long as you define some
incredibly basic UI-related objects that the engine can hand over to
the plugin. The most obvious X example would be the connection to the
server. The plugin can then do anything it wants with that connection
(except close it, presumably - hard to enforce, perhaps).

>[...closure based plug-in example...]
>
>I like it. And it kind of fits well together with the fully event based
>instantiation procedure I had in mind... The details of how the plug-in wants
>to keep track of state info etc can be hidden from the engine, which means
>that the public part of a closure (previously: plugin instance struct) can be
>kept very simple without limiting the capabilities of the plug-in API. Have to
>think more about this... But I'll post some more ideas on the event system
>first.

\begin{advertisement}

There are a lot of lessons that I think you can learn from Quasimodo
here, even though that program isn't even finished yet. Last week,
Quasimodo became a shared library. The main() function now looks like
this:

  #include <iostream>
  
  #include "quasimodo.h"
  #include "gtk_ui.h"
  
  main (int argc, char *argv[])
  
  {
  	Gtk_UI *gtk_ui;
  	Quasimodo *q;
  
  	q = new Quasimodo (&argc, argv);
  
  	if (!q->ok()) {
  		cerr << "Could not create Quasimodo engine" << endl;
  		return 1;
  	}
  
  	gtk_ui = new Gtk_UI (&argc, &argv);
  	gtk_ui->run ();
  
  	return 0;
  }

That is, there is total separation of Quasimodo-the-engine from the
UI. Given that Quasimodo's engine is now capable of scaling to any
number of processors, shares opcodes with the most significant music
programming language around, already runs on Linux and IRIX, and will
soon have both a Python and command line UI (thanks to Stephane
Conversey for these two) to encourage porting to any other platform,
it has a number of reasons to take it seriously.

In writing Quasimodo, I struggled with the same problems of separating
the "guts" of a plugin (called a module in Q) from its visual
interface (if indeed there is one). Its a very difficult problem. On
the one hand, I am a little remorseful that its hard to make Q modules
as attractive as some of the TDM plugins for protools or the VST ones
floating around. On the other hand, the code separation that Q
embodies makes multiple UI's relatively trivial to implement, and, in
the case of the cmdline interface, demonstrates that you don't even
need a *G*UI to make something useful. Someone in the UK wants to use
Quasimodo for something related to blind people producing computer
music - no GUI's there!

\end{advertisement}

I don't know enough about the internals of VST or the TDM plugin
schemes to understand who or what is generating the GUI and responding
to its manipulation, but given that it will be rare for anyone to say
"give me a 250msec stereo delay" - they will more likely say "give me
a delay and let me play with the timing" - defining a control method
for the parameters of each plugin is not a side-issue, its critical. 

Just to float an idea: instead of having the GUI run by anything
related to the engine, put the parameters in shared memory (*). Then
the plugin becomes a standalone application which does 2 things. First
of all, it contacts the engine to request insertion of the "guts" of
the plugin. Then it runs a (possibly multithreaded) GUI to allow
manipulation and possibly display of the parameters and other data,
accessed via shared memory. Benno will love this idea, I'm sure :)

You could choose whether or not termination of the GUI would trigger
removal of the "guts" of the plugin.

--p

(*) this is in Quasimodos TODO list, BTW :)

From - Wed Sep 22 01:30:25 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA18568
	for <slinkp@ulster.net>; Tue, 21 Sep 1999 22:32:05 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA21365 for linux-audio-dev-list; Tue, 21 Sep 1999 21:49:10 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA21362 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 21 Sep 1999 21:49:07 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id VAA02551
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 21 Sep 1999 21:44:19 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id VAA02876; Tue, 21 Sep 1999 21:44:17 -0400 (EDT)
Date: Tue, 21 Sep 1999 21:44:13 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Weekend developments (NetMIDI is no longer vaporware)
Message-ID: <Pine.GSO.4.10.9909212113100.28680-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 1631f86518cd25991d11cfd596e33130


Hi guys --

  I didn't get much further with Songpad, but I did code up some stuff
that will play very well with it...

  I'm happy to say that NetMIDI (remember that?!) is no longer vaporware.  
Based on the success of my little MIDI-messages-over-pipes toys, I decided
that my non-timestamped, raw-MIDI-messages-over-***-transport model really
worked, at least for my own home experiments.  People who need extreme
precision will be busy installing Audiality anyway, right?

   Thus, I wrote a pair of programs.  One listens on a pipe (named or
stdin) and writes to a socket.  The other listens on a socket and writes
to a pipe (named or stdout).  You can use these in conjunction with any of
my other MIDI toys to send MIDI between computers in realtime without MIDI
cables.  I even started work on a Windows program (let's all get together
in a rousing Bronx cheer for MFC; to keep my sanity I had to switch to Wx)
that translates between NetMIDI and Windows MME MIDI, so my FIFO-MIDI toys
can mix and match with Cakewalk.  When I finish the Windows one, I'll
write up a decent web page for the stuff, but for now, you can download
the new toys from my transfer directory...
"http://patriot.altavista-software.com/~div/xfr/".

   The actual implementation of NetMIDI turned out to be much less complex
than what I talked about on the NetMIDI web site
("http://patriot.altavista-software.com/~div/projects/netmidi/").  I
decided not to use a central coordinating server.  Rather, a NetMIDI
connection is a one-way TCP connection, very similar to a pipe (no, I
don't use some funky TCP option to do this, I just don't use the other
direction).  Any "MIDI in" thus listens on a TCP port, and a "MIDI out"
makes a TCP connection to it directly.  There is no handshake phase of the
session; it starts sending data immediately, just like with a pipe.

   Now that I have this, I could potentially write Songpad in pure Java.  
I could have done it with FIFO-MIDI in pure Java (since FIFOs can be used
via Java's generic file I/O routines), but most non-Unix platforms don't
have FIFOs, so I wouldn't get very far with that.  However, sockets work
fine from Java on all platforms, so with NetMIDI it would work.  That
said, I'll still probably do it in native code for performance reasons,
but I'll probably ship with both, so you can choose at runtime.

Div.

P.S.  Here and there I've heard mention of something called "netcat" which
sounds somewhat similar to my little pipe-to-socket programs.  Has anybody
tried this?  Have an URL?

From - Thu Sep 23 00:18:47 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id EAA14763
	for <slinkp@ulster.net>; Wed, 22 Sep 1999 04:33:17 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id DAA21899 for linux-audio-dev-list; Wed, 22 Sep 1999 03:27:44 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA21896 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 22 Sep 1999 03:27:40 -0400
Received: from localhost.localdomain (d212-151-32-19.swipnet.se [212.151.32.19]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id JAA19846; 
          Wed, 22 Sep 1999 09:23:33 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Date: Wed, 22 Sep 1999 08:52:41 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199909220044.UAA13671@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99092209294600.00438@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id JAA19846
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id EAA14763
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 96669a753362da7cca58112d8a347d98

On Wed, 22 Sep 1999, Paul Barton-Davis wrote:
[...]
> In writing Quasimodo, I struggled with the same problems of separating
> the "guts" of a plugin (called a module in Q) from its visual
> interface (if indeed there is one). Its a very difficult problem. On
> the one hand, I am a little remorseful that its hard to make Q modules
> as attractive as some of the TDM plugins for protools or the VST ones
> floating around. On the other hand, the code separation that Q

Why do you get GUI limitations here? Related to the separation?

> I don't know enough about the internals of VST or the TDM plugin
> schemes to understand who or what is generating the GUI and responding
> to its manipulation, but given that it will be rare for anyone to say
> "give me a 250msec stereo delay" - they will more likely say "give me
> a delay and let me play with the timing" - defining a control method
> for the parameters of each plugin is not a side-issue, its critical. 

I don't know the details about TDM, but VST 2.0 uses 3 different methods.

1) The simple host UI: Parameter names, values and unit are strings that the
host can request and display any way it prefers.

2) Native GUI built into the plug-in. (100% Platform dependent...)

3) The new VST GUI; a "powerful" cross platform toolkit. Used for building GUIs
within the plug-in, but platform independent as opposed to 2).

In short, I don't like it, as it doesn't support any real form of GUI
separation whatsoever.

> Just to float an idea: instead of having the GUI run by anything
> related to the engine, put the parameters in shared memory (*). Then
> the plugin becomes a standalone application which does 2 things. First
> of all, it contacts the engine to request insertion of the "guts" of
> the plugin. Then it runs a (possibly multithreaded) GUI to allow
> manipulation and possibly display of the parameters and other data,
> accessed via shared memory. Benno will love this idea, I'm sure :)
> 
> You could choose whether or not termination of the GUI would trigger
> removal of the "guts" of the plugin.

Two problems: Synchronization of the GUI and processing code, and network
transparency. But other than that, it does give plug-in developers full control
over their plug-in <-> GUI communication. What I *don't* like is that this kind
of solution results in plug-ins needing dual interfaces (at least) - one for
the GUI and one for automation.

With an event based system, you get automation virtually for free. Many
plug-ins won't even need to use custom events for their processing <-> GUI
communications, which means they can just send their "parameter change" events
and let the engine record the communication if desired. Custom events could be
split into two groups - "automation enabled" and "private".

As the event interface needs to be very flexible, efficient and well thought out
anyway, I don't see much reason not to use it for this as well... And it does
solve sync problems and allows true network transparency as well. And it makes
it possible for applications to host plug-ins while leaving most of the event
processing work (automation, routing, distributed processing...) to a central
system engine. (I want applications to run as clients - not hosts - in the
normal case, but I don't want that to be the only way to do it, as is the case
with most similar solutions - dedicated DSP systems included.)

What you'd need for a UI module (library, task, whatever...) is 1) a connection
to the event system and 2) any UI you like (X, console, serial port, MIDI
port...) You may then hack away pretty much any way you like, but of course, a
more civilized approach is probably desirable for the average
VST/TDM/DirectX/... GUI style plug-in.

We could propose a GUI API to use for this, but 1) that would have to be
implemented on all platforms we want to support, 2) it has to be powerful to
gain any acceptance among serious developers and 3) there are already lots of
"standard" toolkits... GTK+ is nice, but I would prefer something like
wxWindows for portability reasons. But no matter what, it's probably close to
impossible not ending up where VST is; forcing developers to either accept the
limited VST GUI, or hack platform specific GUI code if they need more control.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Thu Sep 23 00:18:52 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA05365
	for <slinkp@ulster.net>; Wed, 22 Sep 1999 09:29:06 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA22440 for linux-audio-dev-list; Wed, 22 Sep 1999 08:33:09 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA22437 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 22 Sep 1999 08:33:06 -0400
Received: from bright.net (find-cas1-cs-25.dial.bright.net [209.143.26.128])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id IAA24603;
	Wed, 22 Sep 1999 08:21:05 -0400 (EDT)
Message-ID: <37E8B6D2.E98B0558@bright.net>
Date: Wed, 22 Sep 1999 07:00:34 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
CC: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] gAlan
References: <19990921234501.A365@cerealbox>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 82d1e4a72f51f2a985b3ee9a9c831efb

reactor/CTPmedia wrote:

> has anyone tried gAlan? it seems like the project i wanted to make.
> my only problem is, that it segfaults on anything i do :)))))
> it contains plugins, maybe the source is worth checking out.
> 
> url: http://homepages.ihug.co.nz/~surazal/galan-0.2.0.tar.gz

I have it running on my system (RH 5.2, kernel 2.0.36, OSS/Linux
drivers). It works fine, and I plan on checking out the tutorial today.
Seems like a neat program...

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Thu Sep 23 00:19:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA21129
	for <slinkp@ulster.net>; Wed, 22 Sep 1999 11:08:57 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA22622 for linux-audio-dev-list; Wed, 22 Sep 1999 09:53:10 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA22618 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 22 Sep 1999 09:53:06 -0400
Received: from someip.ppp.op.net (d-bm2-1b.ppp.op.net [209.152.194.59]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id JAA24589 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 22 Sep 1999 09:49:00 -0400 (EDT)
Message-Id: <199909221349.JAA24589@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress? 
In-reply-to: Your message of "Wed, 22 Sep 1999 08:52:41 +0200."
             <99092209294600.00438@localhost.localdomain> 
Date: Wed, 22 Sep 1999 10:44:54 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3d69a5b2d091296a453e21e699760afd

David writes:

>On Wed, 22 Sep 1999, Paul Barton-Davis wrote:
>[...]
>> In writing Quasimodo, I struggled with the same problems of separating
>> the "guts" of a plugin (called a module in Q) from its visual
>> interface (if indeed there is one). Its a very difficult problem. On
>> the one hand, I am a little remorseful that its hard to make Q modules
>> as attractive as some of the TDM plugins for protools or the VST ones
>> floating around. On the other hand, the code separation that Q
>
>Why do you get GUI limitations here? Related to the separation?

Because, like the new VST GUI, Quasimodo provides its own GUI language
that the plugins use to specify their interface. This currently
provides for about a dozen or so visual elements along with way to
position them and control their ranges/values etc. However, I'm
working right now, for example, on a dynamics module which does
compression/expansion/limiting in a single unit (since they're really
all the same thing). There is no way to do this without writing the
whole widget in the native UI language (e.g. Gtk-- or Python), because
the internal UI stuff is just too limited to handle it. The end result
is a new UI element that can be used by other modules - it will be
some kind of customized curve-drawing widget with range controls,
etc. The same applies to my rather funky (and I think very cool :)
envelope UI element which started out as a necessary item for the
sampling oscillator module, and is now part of the UI element suite.

So no, there is no fundamental limitation, more just a trade-off
between always writing new visual elements in the native UI form, or
using a more limited subset. its pretty much like VST in that regard.

The existing subset could get to look pretty nice, if and when someone
(me, someone else) has the time to spend a week or so futzing with the
GIMP to get it that way.

[ ... VST ... ]

>2) Native GUI built into the plug-in. (100% Platform dependent...)

How does this work ? What is handling GUI event callbacks ? Is the
plugin a separate thread or task ? Or is it all running as part of the
engine ?

>Two problems: Synchronization of the GUI and processing code, and
>network transparency. 

Network transparency is an illusory goal (for audio) in my
opinion. However, even if you want to pursue a more limited form of
it, note that by using X and simply forcing the plugin's cycles to run
on the same host as the engine, you do have a certain polarity of
network transparency.

As for the sync problem - I don't believe there is a sync
problem. This is precisely what Quasimodo does now: the UI runs
in a different thread than the DSP emulation, and it fiddles randomnly
with the data used by the DSP; there is *no* synchronization between
them at all. I have had no problems with this, and I cannot find a
theoretical reason why there should be, because of the atomicity of
the instructions to store and load floats and integers (which is what
a parameter change fundamentally reduces to). So I think this is a
non-issue too. The only sense in which I worry about this is if
Quasimodo was ever ported to run on an on-card DSP, access to the
parameter memory might not be so straightforward. But with the new AMD
Athlon/K7 out in a month or two, on-card DSP's are not looking very
attractive any more :)
		       
>		       But other than that, it does give plug-in
>developers full control over their plug-in <-> GUI
>communication. What I *don't* like is that this kin d of solution
>results in plug-ins needing dual interfaces (at least) - one for the
>GUI and one for automation.

>With an event based system, you get automation virtually for free. Many
>plug-ins won't even need to use custom events for their processing <-> GUI
>communications, which means they can just send their "parameter change" events
>and let the engine record the communication if desired. Custom events could be
>split into two groups - "automation enabled" and "private".

yes, this is certainly a nice feature, but I am afraid that its too
slow. if changing the values of a parameter involves any more than
just a fairly low-cost function call (and particularly if it involves
a context switch between the UI thread and the engine thread), I have
some real concerns (based on experiences with Quasimodo) that you
can't do it fast enough. 

Particularly not if you hook up the UI to an external controller/fader
box, which I do all the time. I *sometimes* end up with a full MIDI
wire (8 MIDI faders all ramped to zero and then back up again to a
7bit value). This can translate into about 1 thousand parameter
changes per second, and this is supposed to be handled asynchronously
with the engine.

You're not going to be able to handle this by making an IPC call from
the UI thread to the engine, and if its checking for parameter changes
a thousand times a second in some shared memory queue, its going to be
wasting a lot of cycles that would otherwise be used for DSP. I don't
understand what kind of event system other than some kind of IPC that
you might be envisaging ....

I am currently investigating the XRecord extension for automation of
Quasimodo. I don't see any need to reinvent the wheel here -
automation of X interfaces is something that has been worked on for 10
years or so. The X model is fairly nice because the server will buffer
your events for you until you are ready to handle them, to a
point. So, you can go through a huge burst of UI changes, and then
pick up the event stream for automation recording once things calm
down.

>We could propose a GUI API to use for this, but 1) that would have to be
>implemented on all platforms we want to support, 2) it has to be powerful to
>gain any acceptance among serious developers and 3) there are already lots of
>"standard" toolkits... GTK+ is nice, but I would prefer something like
>wxWindows for portability reasons. But no matter what, it's probably close to
>impossible not ending up where VST is; forcing developers to either accept the
>limited VST GUI, or hack platform specific GUI code if they need more control.

Well, I think you should start by handing the plugin a connection to
the X server and leave it at that. Any native GUI API worth anything
can take such a connection and get started from there.

--p

From - Thu Sep 23 00:19:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA03804
	for <slinkp@ulster.net>; Wed, 22 Sep 1999 12:41:04 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA22899 for linux-audio-dev-list; Wed, 22 Sep 1999 11:35:05 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA22896 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 22 Sep 1999 11:35:01 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S42689AbPIVPaP>; Wed, 22 Sep 1999 18:30:15 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <99092200193603.00438@localhost.localdomain> (message from David
	Olofson on Tue, 21 Sep 1999 22:56:19 +0200)
Subject: Re: [linux-audio-dev] Plug-in API progress?
Message-Id: <19990922153016Z42689-23519+2339@nic.funet.fi>
Date:   Wed, 22 Sep 1999 18:30:15 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 64699d739670eb254ef8326903ddd7fa

>From:   David Olofson <audiality@swipnet.se>
>
>Conditional code is complex and expensive. I think the low level data flow
>should consist of only two data types: raw data and events. What actual data
>formats we're really dealing with will be hardcoded in the plug-ins anyway

I were thinking that some might want keep the gain (say) constant,
changing time to time, changing constantly. If the plug-in fixes the
type, then should we have N+1 different version of the same plug-in?
Or how?

>Static data? Isn't a single out-of-band event enough, or are we thinking
>about different things?

Anything the particular instantiation of the plug-in might use.

>> #define PLUGIN_INOUTTYPE_NONE 0
>
>For padding or what...?

The plug-in will use the default value if the gain parameters has no input.
I think NULL as a function call argument does the same.

>> #define PLUGIN_INOUTTYPE_BUFFER 1
>> #define PLUGIN_INOUTTYPE_EVENTLIST 2
>
>Another way to handle Event Ports (as I call them for now) is like something
>you create during the instantiation of a plug-in (create any number you need).
>Don't know if there's really much point in having multiple event inputs on a
>single plug-in...

If a plug-in has both the frequency and boost parameter in the function
call, you need two eventlists (if events are used on those parameters).
The event actually means "change the gain to value <event value>".

There is no any target info on the events so that the events such as
"gain please! change yourself to <event value>" cannot be sent (to that
unique port).

If we later add such a target system, then the targets can be parsed
at building time and be hardcoded the above way at run-time.

>Do you put multiple channels in the same buffer here?

Good question. I planned to provide the number of channels, samplerates,
etc. as one static input. It is the matter of building time and not
of run-time.

The samples are interleaved in the buffer. Event should also have
simultaneous data for all channels if the parameter affect to all
channels.

>How about
>	int	time;
>	int	code;		/* What is this? */

Leave this out because it is hardcoded at network building time.
We know it already.

>	int	from;		/* Who is this from? */

Hardcoded. Or no need to know.

>	int	size;		/* Number of data bytes */
>	/* dynamic size data follows... */

Hardcoded. Basically the time and arbitrary data (which the plug-in knows
how to cast) are needed.

>so we might be able to have dynamic event size from the start.

Yep.

>>   f = (filter *)malloc(sizeof(filter));
>> and default values:
>>   filter_setsamplerate(f,44100);
>
>One of my latest wild ideas it to replace this entirely with the
>event system.

Above calls are not called by the engine but the network builder.

>No struct, just a callback function that the engine asks about properties
>when instantiating a plug-in, or just wants some general info anout the
>plug-in class.

I would layer the data this way:
 -the things needed when the plug-in flows the audio;
 -the things needed to add the plug-in to the network.

The simple API I were thinking would let the second part to the
programmer of the application. He would know early all the plug-ins.

Because we are including only the audio flow data structures to simple
API, the more complex system can be build over the simple API.
I think even the random access wave editor plug-ins would use the flow API
for the actual processing when and if possible.

>> The runtime call would be
>>   filter_do(f,inout *input, inout *output, inout *freq, inout *boost);
>> where input and output would get buffers and where freq and boost would
>> get events.
>
>I think
>	filter_do(f, void **inputs, void **outputs, event **events);
>will do.

No if we hardcode the event paths.

>Also, no output buffer for events.

They are in my system.

>Yeah, but there's a slight timing problem here; how do you know where you're
>headed before you've recieved the next point?

If you need to know the curve very well, it can be edited in the editor
and given to plug-in as static data. If sent as events or buffers, we
face the same latency problems as with audio or MIDI data.

>Well, even if my event system might be more complex than what you had
>in mind

I would like to go the simple hardcoded way and only later look at the
general event system.

I think we will use the closures as used in Csound and in Quasimodo. They
are quite the same what I proposed but less parameters at function calls.

Paul, I now notice that I use the f in function call
   filter_do(f,inout *input, inout *output, inout *freq, inout *boost);
to carry sample rates, default values and all such infos. I guess forgot
it myself and described something else to you in my private mail.

Yours,

Juhana

From - Thu Sep 23 00:19:06 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA08122
	for <slinkp@ulster.net>; Wed, 22 Sep 1999 13:04:27 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA22967 for linux-audio-dev-list; Wed, 22 Sep 1999 12:09:11 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA22964 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 22 Sep 1999 12:09:07 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S42525AbPIVQEE>; Wed, 22 Sep 1999 19:04:04 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <199909220044.UAA13671@renoir.op.net> (message from Paul
	Barton-Davis on Tue, 21 Sep 1999 21:40:06 -0400)
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Message-Id: <19990922160416Z42525-32561+2434@nic.funet.fi>
Date:   Wed, 22 Sep 1999 19:04:04 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c588c4ecbca04df469a842c81b98d299

>From:   Paul Barton-Davis <pbd@Op.Net>
>
>Just to float an idea: instead of having the GUI run by anything
>related to the engine, put the parameters in shared memory (*).

In my list too. I actully made the playline position transfer via shared
memory in my improved XWave2. There were some problems... it was like
the shared memory would have some delay before showing in another process.
I printed the content of the shared memory play position and it was
 -1 for a long time even the engine updated the position (I heard the audio).
Then when the value was finally available (after 1 to 2 seconds) in GUI
process, the value was jumped to the current position (I never saw the
earlier positions). Perhaps Linux did something weird paging stuff, who
knows?

The code is available at "http://www.funet.fi/~kouhia/waves". Look at
files audio.c (play file stuff) and... and graphics.c (the play button
stuff). I'm not responsible to the complete mess in those files. The code
is very messy and a reason why I started to write my own editor and
not to continue improving the XWave. (My wave editor is not yet available
even I'm using it already --- I need to complete my major audio engine first.)

>manipulation and possibly display of the parameters and other data,
>accessed via shared memory. Benno will love this idea, I'm sure :)

Me too! If GUI peaks the signal level (say) from one memory address, then
there is no buffers or event queues which could freeze the system or cause
delay (of the length of buffer) if GUI freezes for a moment.
Ok, the engine would not freeze at all (if message queues are used for
events, the engine should use nonblocking mode).

Yours,

Juhana

From - Thu Sep 23 00:19:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA21619
	for <slinkp@ulster.net>; Wed, 22 Sep 1999 14:28:43 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA23070 for linux-audio-dev-list; Wed, 22 Sep 1999 12:56:47 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA23067 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 22 Sep 1999 12:56:43 -0400
Received: from someip.ppp.op.net (d-bm3-18.ppp.op.net [209.152.194.88]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id MAA15494 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 22 Sep 1999 12:52:35 -0400 (EDT)
Message-Id: <199909221652.MAA15494@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] For Juhana
In-reply-to: Your message of "Wed, 22 Sep 1999 18:30:15 +0300."
             <19990922153016Z42689-23519+2339@nic.funet.fi> 
Date: Wed, 22 Sep 1999 13:48:30 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 901ef000896cfe686512183f0bc3fd99

Juhana -

your email address is broken, and it impossible to reply to you. Your
SMTP server reports "User Unknown".

--p

From - Fri Sep 24 11:19:48 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA04963
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 07:43:10 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA26050 for linux-audio-dev-list; Thu, 23 Sep 1999 06:22:35 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA26044 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 06:22:27 -0400
Received: from gardena.net ([194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id MAA09561;
	Thu, 23 Sep 1999 12:18:03 +0200
Received: from localhost (localhost [[UNIX: localhost]])
	by gardena.net (8.9.3/8.9.3) id AAA06905;
	Thu, 23 Sep 1999 00:18:34 +0200
From: Benno Senoner <sbenno@gardena.net>
To: David Olofson <audiality@swipnet.se>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Re: Some Event stuff for now...
Date: Wed, 22 Sep 1999 23:45:05 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <99092202461305.00438@localhost.localdomain>
MIME-Version: 1.0
Message-Id: <99092300183403.00699@goblin.flashnet.it>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: dede3c6daa3c155703e75d950cca02c5

On Wed, 22 Sep 1999, David Olofson wrote:
> Hi...
> 
> Here's a part of the current version of my Event System proposal. I think the
> stuff I'm building around this will be more interesting, but I really have to
> get some sleep now, so this will have to do for now... Hope you get the idea.
> 
> Perhaps I should point out that I intend to use an optimized memory allocation
> system with allocation + "flush all" operations per heap buffer only. There
> will be no dealocation, and no fragmentation. (The engine/plug-in host is
> responsible for setting up heaps for sub-nets, so that it can flush them once
> per buffer period, or whatever fits the scheduling algorithm.) The heap
> definition will be a public structure + macros/inlines for performance, and
> should be viewed more like an output buffer on steroids than a real memory
> manager.

David,
I'm still missing a clear picture of the event buffer.
David, you say that you want to flush the buffer on each buffer period.
Do you plan to use per-plugin event buffers ?
Sorry if I dont understand this, but I often have to think in terms of pratical
examples.

Assume a simple sampler-plugin:  
input: MIDI NoteOn / NoteOff events  (to specify triggering and pitch)
output: sample-stream in float format

assume that there are 2 sequencers bombarding the poor sampler-plugin
with Note-on events.
Of course you want to allow timestamped events, therefore the plugin has to
schedule to events in right order.
When do you know to free the buffers ?
You said "flushing on the next buffer period", but what if the timestamped
event has to be scheduled several periods later.
Do you need an additional buffer to queue up timestamped events ?

Ok, you can advance the heap pointer for non-timestamped data, but
for timed events you have to take an other buffer flushing mechanis.
But since David does have a diabolic mind, he has already solved this issue.
:-)


> 
> The reason for using arrays of pointers rather than just events as raw data
> written sequentially into the output buffer is on the engine side - merging of
> events from multiple sources etc...

Ok, but these pointer have to point so some useful data, and you must 
alloc/free the data at some point, and this must be implemented using fast
routines.
Again in the case of timestamped events you have to pay attention when
to free the structs.
Or is this problem already solved ?

> 
> /*
>  * The engine encode time stamps as samples from
>  * start of the timing master buffer, which can be
>  * selected by the plug-in.
>  * (Alternatively, this could be a float, but I
>  * think that should be optional for performance
>  * reasons.)

Yes, but what if the samplerate changes ?
Or will the API provide a fuction like
event_time=time_2_event_time(float time)   time in secs with fracions, or maybe 
struct tv like


> 
> struct event_t;
> 
> struct event_port_t {
> 	int	events;		/* Number of events currently in the buffer */
> 	int	maxevents;	/* Size of the buffer */
> 	event_t	**buffer;
> };


what is exactly an event_port ?
A place where you can send events ?
in the sample-player-plugin case:
it the input-port of the plugin where you send the MIDI events ? 

> 
> struct event_t {
> 	event_time_t	time;
> 	event_code_t	code;		/* What is this? */
> 	/* This 'from' field being a pointer to the
> 	 * Event Port struct of the sender might be
> 	 * a bit dangerous. (I'm thinking Event Port
> 	 * lifetime...)
> 	 */
> 	event_port_t	*from;		/* Who is this from? */
> 	int		size;		/* Number of data bytes */
> };


> 
> 
> (event_t is of course just the header - any number of bytes of data may follow.)
> 
> Any ideas about the from field? What I mean is, a simple way of making sure that
> no one tries to reply to an event from a port that was just removed? (I think
> it'll become clear when dealing with the life time of event buffers. When all
> buffers with events from a certain port have been flushed, it's safe to delete
> the port - unless some plug-in decides to remember a reply port address for
> later use... That should probably not be allowed.)

What about to require the event-senders to notify the event-receivers 
that they want to exit ?
Maybe we could use double indirection:
the **from is a pointer to a function pointer which gets the real from address.
This function pointer arrays could be static (maybe with some garbage collection
for reallocation).
Therefore if an event-sender wants to exit, then it should just set the *from
address to a fake port which is called NO_PORT or so,
therefore in the case that the event-receiver wants to query data about the 
event-sender, there will be a function which will return PORT_NOT_PRESENT (=
plugin exited or so),
with no crashes due to inexistent pointer deferences etc.
And since the port-pointer will take only 4 bytes, even with a very lazy
allocation/garbage collection scheme we will not run out of memory too soon.
:-)

Opinions ?

Benno.

From - Fri Sep 24 11:19:46 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA04394
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 07:36:01 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA26041 for linux-audio-dev-list; Thu, 23 Sep 1999 06:22:25 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA26038 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 06:22:17 -0400
Received: from gardena.net ([194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id MAA09556;
	Thu, 23 Sep 1999 12:17:52 +0200
Received: from localhost (localhost [[UNIX: localhost]])
	by gardena.net (8.9.3/8.9.3) id BAA06931;
	Thu, 23 Sep 1999 01:04:38 +0200
From: Benno Senoner <sbenno@gardena.net>
To: David Olofson <audiality@swipnet.se>, Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: [l Re: Plug-in API progress?
Date: Thu, 23 Sep 1999 00:25:52 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <99092209294600.00438@localhost.localdomain>
MIME-Version: 1.0
Message-Id: <99092301043804.00699@goblin.flashnet.it>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: d468cb1d9b012f1ff0e030458e8aacfe

On Wed, 22 Sep 1999, David Olofson wrote:
> 
> I don't know the details about TDM, but VST 2.0 uses 3 different methods.
> 
> 1) The simple host UI: Parameter names, values and unit are strings that the
> host can request and display any way it prefers.
> 
> 2) Native GUI built into the plug-in. (100% Platform dependent...)
> 
> 3) The new VST GUI; a "powerful" cross platform toolkit. Used for building GUIs
> within the plug-in, but platform independent as opposed to 2).

We should too allow 2) and 3),
like quasimodo does we should provide a nice description-language
for providing the most commn audio-GUI elements (faders,knobs,buttons, labels
etc)
maybe Paul's proposed XML-style description language would be nice.
We should provide a way to allow a combination of internal GUI elements,
and custom GUI code.
An example could be a mixer with a custom FFT display.
You could implement all the mixer elements (volume and pan faders),
by using the standard description language, and code the FFT analyzer
using your favorite toolkit. ( Gtk,Qt etc).

I would opt for the following approach:
run the entire description-language GUI part in one thread,
and the custom GUI part as a separate thread, by linking .so modules,
and calling the object's constructors/destructors to show/delete the GUI
elements.
That means the standard GUI code would hardly crash, since it's
interpreted/precompiled.
If an element of the custom GUI code crashes, than it will take down all other
custom GUI elements, (assume you have the buggy FFT-analyzer and a bug-free
custom Scope module, that means if the FFT crashes, the scope will disappear
too)  but as soon the engine detects this, it could restart this
thread which would result in a short flashing of some GUI elements on the
screen, but without real implications. (as long your FFT plugin doesn't crash
every second).

An other solution could having a separate thread for each plugin-GUI-panel.
In this case if one of the plugin-panels crashes, the rest would be unaffected.
But I strongly dislike the idea of having 30 threads running only for doing GUI
handling.

The ideal would be a way to handle several toolkits.
Since it would perhaps very hard to mix 2 toolkits in one thread,
we could implement for example implement a GTK-GUI handler and a Qt-GUI
handler.
This would keep the number of running threads low while allowing maximum
flexibiliy.
Isn't that nice ?

> > Just to float an idea: instead of having the GUI run by anything
> > related to the engine, put the parameters in shared memory (*). Then
> 
> Two problems: Synchronization of the GUI and processing code, and network
> transparency. But other than that, it does give plug-in developers full control
> over their plug-in <-> GUI communication. What I *don't* like is that this kind
> of solution results in plug-ins needing dual interfaces (at least) - one for
> the GUI and one for automation.

Yes,

> 
> With an event based system, you get automation virtually for free. Many
> plug-ins won't even need to use custom events for their processing <-> GUI
> communications, which means they can just send their "parameter change" events
> and let the engine record the communication if desired. Custom events could be
> split into two groups - "automation enabled" and "private".

Agreed, I like this idea,
for example the volume-slider (the GUI part) of a gain-control plugin just
installs an event-sending port and sends the events to the plugin DSP code.
Plus the DSP code installs an event-sending port and connect the event-receiver
port of the volume-slider.
That means if someone (a sequencer/ or arbitrary plugin) changes the gain value,
the fader would move automagically in the correct position.
Or is this suboptimal ?


Do you plan network-transparency to high bandwidth streams too or only
for the event system.
networked evens make sense to me, like sending MIDI events over network.
But sending 60 tracks over the net is a bit harder.
We should take an approach similar to X:
it we are forced to use the network use it,
if there are better alternatives like shmem, use the latter.

> 
> We could propose a GUI API to use for this, but 1) that would have to be
> implemented on all platforms we want to support, 2) it has to be powerful to
> gain any acceptance among serious developers and 3) there are already lots of
> "standard" toolkits... GTK+ is nice, but I would prefer something like
> wxWindows for portability reasons. But no matter what, it's probably close to
> impossible not ending up where VST is; forcing developers to either accept the
> limited VST GUI, or hack platform specific GUI code if they need more control.

Agreed, but keep a door open for multiple toolkits (see my proposed multiple
GUI handlers), since I wouldn't code in GTK afer falling in love with Qt.
:-)

If you need a writer for the Qt-GUI handler .. I'm here ...
:-)

Benno.

From - Thu Sep 23 00:19:16 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA07416
	for <slinkp@ulster.net>; Wed, 22 Sep 1999 19:59:57 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA23735 for linux-audio-dev-list; Wed, 22 Sep 1999 19:06:19 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA23732 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 22 Sep 1999 19:06:07 -0400
Received: from localhost.localdomain (d212-151-89-66.swipnet.se [212.151.89.66]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA03503; 
          Thu, 23 Sep 1999 01:01:52 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Date: Thu, 23 Sep 1999 00:28:28 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199909221349.JAA24589@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99092301080504.00441@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id BAA03503
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA07416
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 920093b228a4b6bf3994e33f95a2191f

On Wed, 22 Sep 1999, Paul Barton-Davis wrote:
> [ ... VST ... ]
> 
> >2) Native GUI built into the plug-in. (100% Platform dependent...)
> 
> How does this work ? What is handling GUI event callbacks ? Is the
> plugin a separate thread or task ? Or is it all running as part of the
> engine ?

Platform dependent. The "average" description:

1) Somehow, you get a window handle. (You may have to create the window
yourself.)

2) Event handling is done the normal native GUI way. (AFAIK, the plug-in is
expected to handle GUI/processing communication sync issues. No explicit API
for that.)

3) All plug-in GUIs seems to run in the host application's GUI thread, but it's
possible to implement that in other ways. (*Everything* may actually run in the
same thread on non real time hosts...)

> >Two problems: Synchronization of the GUI and processing code, and
> >network transparency. 
> 
> Network transparency is an illusory goal (for audio) in my
> opinion. However, even if you want to pursue a more limited form of
> it, note that by using X and simply forcing the plugin's cycles to run
> on the same host as the engine, you do have a certain polarity of
> network transparency.

What I have in mind here is using one machine to run the client application
and another machine, or possibly a cluster to do the processing. Distributing
GUI code all over the place gets a bit too messy for my taste... And it
requires the GUI code to actually work on the same system as the DSP code -
while you most probably don't want to load Qt, GTK+ or whatever on every node
of a Beowulf. And what if you decide to build a cluster of Alpha or PPC boxes?

> As for the sync problem - I don't believe there is a sync
> problem. This is precisely what Quasimodo does now: the UI runs
> in a different thread than the DSP emulation, and it fiddles randomnly
> with the data used by the DSP; there is *no* synchronization between
> them at all. I have had no problems with this, and I cannot find a
> theoretical reason why there should be, because of the atomicity of
> the instructions to store and load floats and integers (which is what
> a parameter change fundamentally reduces to). So I think this is a
> non-issue too.

Not if you plan to support more complex data types than integers and floats.
Which is the case with the new plug-in API...

And, what about timing? How do you handle sample accuracy without going to
single sample buffers? Events handle that in a clean and low cost way.

> The only sense in which I worry about this is if
> Quasimodo was ever ported to run on an on-card DSP, access to the
> parameter memory might not be so straightforward. But with the new AMD
> Athlon/K7 out in a month or two, on-card DSP's are not looking very
> attractive any more :)

Agree. I hope things will keep evolving in this direction, so we can all
concentrate on getting the code to do what we want, rather than fiddling with
lots of different little processors everywhere. :-) (I got pretty tired of that
kind of programming on the Amiga. Fun for a while, but then you start to
realize that a faster CPU is always more flexible. At least with an RTOS...)

> >		       But other than that, it does give plug-in
> >developers full control over their plug-in <-> GUI
> >communication. What I *don't* like is that this kin d of solution
> >results in plug-ins needing dual interfaces (at least) - one for the
> >GUI and one for automation.
> 
> >With an event based system, you get automation virtually for free. Many
> >plug-ins won't even need to use custom events for their processing <-> GUI
> >communications, which means they can just send their "parameter change" events
> >and let the engine record the communication if desired. Custom events could be
> >split into two groups - "automation enabled" and "private".
> 
> yes, this is certainly a nice feature, but I am afraid that its too
> slow. if changing the values of a parameter involves any more than
> just a fairly low-cost function call (and particularly if it involves
> a context switch between the UI thread and the engine thread), I have
> some real concerns (based on experiences with Quasimodo) that you
> can't do it fast enough. 

It doesn't even involve a function call per event. Events are written to Event
Ports using inline code and dynamic memory allocation is done from heaps with
limited life time; also using inline code. The only context switches/sync
points are the global ones for client/engine communication.

> Particularly not if you hook up the UI to an external controller/fader
> box, which I do all the time. I *sometimes* end up with a full MIDI
> wire (8 MIDI faders all ramped to zero and then back up again to a
> 7bit value). This can translate into about 1 thousand parameter
> changes per second, and this is supposed to be handled asynchronously
> with the engine.

Shouldn't be a problem. Also note that the events can be handled with sample
accuracy no matter what buffer size you use. If the MIDI interface plug-in can
extract exact timing info from the MIDI data, that can be used to timestamp the
events, so that plug-ins may use the information if desired.

> You're not going to be able to handle this by making an IPC call from
> the UI thread to the engine, and if its checking for parameter changes
> a thousand times a second in some shared memory queue, its going to be
> wasting a lot of cycles that would otherwise be used for DSP. I don't
> understand what kind of event system other than some kind of IPC that
> you might be envisaging ....

I'll try to get a more detailed spec together this week. Basically, it's about
writing events to buffers that are handled pretty much like audio buffers, and
it certainly doesn't involve any IPC calls at all in itself - on sync point for
the whole client/engine interface, as I said.

(That is, the word "Event" might be a bit missleading, considering the
underlying infrastructure...)

> I am currently investigating the XRecord extension for automation of
> Quasimodo. I don't see any need to reinvent the wheel here -
> automation of X interfaces is something that has been worked on for 10
> years or so. The X model is fairly nice because the server will buffer
> your events for you until you are ready to handle them, to a
> point. So, you can go through a huge burst of UI changes, and then
> pick up the event stream for automation recording once things calm
> down.

Well, that actually reminds a lot of my event system... (Although I hardly think
the X event system would be the right thing for anything lower level than the
GUI.)

[...GUI API...]
> Well, I think you should start by handing the plugin a connection to
> the X server and leave it at that. Any native GUI API worth anything
> can take such a connection and get started from there.

Yes, I think so too. Most Open Source developers will probably use GTK+ or Qt,
but I'd guess most proprietary plug-ins would use other toolkits, and/or do a
lot of work directly on X. It's a strange world...

My point is; we'd probably just be wasting time designing something, or build
it around some existing toolkit; there's just too big a risk it won't ever be
used. Plain X should do.

(BTW, wonder if developers are actually using the VST 2.0 GUI stuff for
release plug-ins...)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Thu Sep 23 00:19:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA14330
	for <slinkp@ulster.net>; Wed, 22 Sep 1999 20:44:31 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA23803 for linux-audio-dev-list; Wed, 22 Sep 1999 19:57:23 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA23800 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 22 Sep 1999 19:57:02 -0400
Received: from localhost.localdomain (d212-151-89-66.swipnet.se [212.151.89.66]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA26475; 
          Thu, 23 Sep 1999 01:52:50 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Juhana Sadeharju <kouhia@nic.funet.fi>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Plug-in API progress?
Date: Thu, 23 Sep 1999 01:09:04 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <19990922153016Z42689-23519+2339@nic.funet.fi>
MIME-Version: 1.0
Message-Id: <99092301590405.00441@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id BAA26475
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA14330
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 89f33c4a0d7484c117236863cdc78529

On Wed, 22 Sep 1999, Juhana Sadeharju wrote:
> >From:   David Olofson <audiality@swipnet.se>
> >
> >Conditional code is complex and expensive. I think the low level data flow
> >should consist of only two data types: raw data and events. What actual data
> >formats we're really dealing with will be hardcoded in the plug-ins anyway
> 
> I were thinking that some might want keep the gain (say) constant,
> changing time to time, changing constantly. If the plug-in fixes the
> type, then should we have N+1 different version of the same plug-in?
> Or how?

Events... They are decoded with optimized case statements (any decent compiler
generates jump tables), and as you *have* to check for some stuff anyway,
supporting extra events comes for free.

If you don't want to change anything, just don't send any events...

> >Static data? Isn't a single out-of-band event enough, or are we thinking
> >about different things?
> 
> Anything the particular instantiation of the plug-in might use.

Ok.

> >> #define PLUGIN_INOUTTYPE_NONE 0
> >
> >For padding or what...?
> 
> The plug-in will use the default value if the gain parameters has no input.
> I think NULL as a function call argument does the same.

Conditionals that can't be optimized away... With an internal copy of the
parameter, and events to change it, no extra tests are needed.

> >> #define PLUGIN_INOUTTYPE_BUFFER 1
> >> #define PLUGIN_INOUTTYPE_EVENTLIST 2
> >
> >Another way to handle Event Ports (as I call them for now) is like something
> >you create during the instantiation of a plug-in (create any number you need).
> >Don't know if there's really much point in having multiple event inputs on a
> >single plug-in...
> 
> If a plug-in has both the frequency and boost parameter in the function
> call, you need two eventlists (if events are used on those parameters).
> The event actually means "change the gain to value <event value>".
> 
> There is no any target info on the events so that the events such as
> "gain please! change yourself to <event value>" cannot be sent (to that
> unique port).

Ok...

> If we later add such a target system, then the targets can be parsed
> at building time and be hardcoded the above way at run-time.

Hmm... I kind of like the hardcoding idea. But I doubt that it'll pay off:
Have a look at the engine side... And what if you have say 15 parameters of
which you may automate any few? That's a veeeeery long stack frame, most of
which will be unused most of the time. (Or am I missing the point?)

> >Do you put multiple channels in the same buffer here?
> 
> Good question. I planned to provide the number of channels, samplerates,
> etc. as one static input. It is the matter of building time and not
> of run-time.
> 
> The samples are interleaved in the buffer. Event should also have
> simultaneous data for all channels if the parameter affect to all
> channels.

Sounds a bit inflexible to me...

> >How about
> >	int	time;
> >	int	code;		/* What is this? */
> 
> Leave this out because it is hardcoded at network building time.
> We know it already.

Ok. (See above - "many parameters".)

How do we access parameters (that are used less frequently) if they're not
"registered" as an event input in the current net? (And BTW, if the code is
supposed to be recompiled to get rid of the conditionals, we're in serious
trouble. Such a restriction can never be removed without completely redesigning
the system, which I think defeats the whole point with this "prerelease" API.)

> >	int	from;		/* Who is this from? */
> 
> Hardcoded. Or no need to know.

Not if all code is always present, and the work is supposed to be done at run
time. Unfortunately, there's probably no way to avoid the fact that plug-ins
must be possible to deliver as closed source binaries...

> >	int	size;		/* Number of data bytes */
> >	/* dynamic size data follows... */
> 
> Hardcoded. Basically the time and arbitrary data (which the plug-in knows
> how to cast) are needed.

Same thing... BUT, the event size *can* be hardcoded in the meaning that only
the sender and the reciever of the event needs to know the actual size. Sending
event buffers as arrays of pointers to events eliminates the need for the
engine to know about event sizes.

> >so we might be able to have dynamic event size from the start.
> 
> Yep.
> 
> >>   f = (filter *)malloc(sizeof(filter));
> >> and default values:
> >>   filter_setsamplerate(f,44100);
> >
> >One of my latest wild ideas it to replace this entirely with the
> >event system.
> 
> Above calls are not called by the engine but the network builder.

And that's the way it should be. The point is just getting rid of one of two
similar interfaces...

> >No struct, just a callback function that the engine asks about properties
> >when instantiating a plug-in, or just wants some general info anout the
> >plug-in class.
> 
> I would layer the data this way:
>  -the things needed when the plug-in flows the audio;
>  -the things needed to add the plug-in to the network.

Yes.

> The simple API I were thinking would let the second part to the
> programmer of the application. He would know early all the plug-ins.

He can just send some request events to the plug-ins init function. The event
system code is there anyway, and the ability to generate answers at run time is
interesting. (Remember the buffer size and sample rate restrictions
discussion...?)

> Because we are including only the audio flow data structures to simple
> API, the more complex system can be build over the simple API.

Well, my idea was to make the basic system even simpler, so we have less
functionality that will be removed or changed. Perhaps doing nearly everything
with the event system isn't optimal, but once the system is there, it's very
simple to implement stuff on top of it. I'd rather start with that, and then
move things out to the structures later on, if required for performance reasons
or otherwise.

> I think even the random access wave editor plug-ins would use the flow API
> for the actual processing when and if possible.

Yes, as long as the headers make everything look nice on both sides (and not
only on the plug-in side, as with most existing SDKs...), there's not really
any excuse not to use it. Preferably, you should only need to include one or
two header files, hack a few lines and then fill in your code to get started.
(The default settings should be well defined and reasonable, so that most
plug-ins won't have to answer most of the standard init questions from the
engine or net builder. I think this beast a struct where you can use default
values for some of the fields...)

> >> The runtime call would be
> >>   filter_do(f,inout *input, inout *output, inout *freq, inout *boost);
> >> where input and output would get buffers and where freq and boost would
> >> get events.
> >
> >I think
> >	filter_do(f, void **inputs, void **outputs, event **events);
> >will do.
> 
> No if we hardcode the event paths.

True, but I think that kind of stuff belongs in a control signal system - not
an event system. (Control signals can be implemented as audio streams.)

> >Also, no output buffer for events.
> 
> They are in my system.

That is, an event output buffer is always sent directly to an input of some
other plug-in?

> >Yeah, but there's a slight timing problem here; how do you know where you're
> >headed before you've recieved the next point?
> 
> If you need to know the curve very well, it can be edited in the editor
> and given to plug-in as static data. If sent as events or buffers, we
> face the same latency problems as with audio or MIDI data.

I don't like the distinction. Too many subsystems and data types...

> >Well, even if my event system might be more complex than what you had
> >in mind
> 
> I would like to go the simple hardcoded way and only later look at the
> general event system.

I'm afraid that will result in two interfaces/subsystems that overlap too
much... And is your event system really that much simpler to implement?

> I think we will use the closures as used in Csound and in Quasimodo. They
> are quite the same what I proposed but less parameters at function calls.

Kind of like a way of making better use of the plug-in instance struct. And the
less data that needs to be moved to the stack for each call (ie explicitly
regarded as "data that will be used anyway" - which may not always be true),
the more chances of optimizing the plug-in code.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Sep 24 11:19:50 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA05042
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 07:44:19 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA26051 for linux-audio-dev-list; Thu, 23 Sep 1999 06:22:36 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA26045 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 06:22:29 -0400
Received: from gardena.net ([194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id MAA09552;
	Thu, 23 Sep 1999 12:17:41 +0200
Received: from localhost (localhost [[UNIX: localhost]])
	by gardena.net (8.9.3/8.9.3) id BAA06960;
	Thu, 23 Sep 1999 01:38:58 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Date: Thu, 23 Sep 1999 01:11:03 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: audiality@swipnet.se
References: <199909221349.JAA24589@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99092301385705.00699@goblin.flashnet.it>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: bd3e578eced197c6a76c118ca50fb36e

On Wed, 22 Sep 1999, Paul Barton-Davis wrote:
> David writes:
>> 
> Because, like the new VST GUI, Quasimodo provides its own GUI language
> that the plugins use to specify their interface. This currently
> provides for about a dozen or so visual elements along with way to
> position them and control their ranges/values etc. However, I'm
> working right now, for example, on a dynamics module which does
> compression/expansion/limiting in a single unit (since they're really
> all the same thing). There is no way to do this without writing the
> whole widget in the native UI language (e.g. Gtk-- or Python), because
> the internal UI stuff is just too limited to handle it. The end result
> is a new UI element that can be used by other modules - it will be
> some kind of customized curve-drawing widget with range controls,
> etc. The same applies to my rather funky (and I think very cool :)
> envelope UI element which started out as a necessary item for the
> sampling oscillator module, and is now part of the UI element suite.
> 
> So no, there is no fundamental limitation, more just a trade-off
> between always writing new visual elements in the native UI form, or
> using a more limited subset. its pretty much like VST in that regard.

Agreed, IMHO the best is to take advantage of both,
if the modules is available in the UI language use it,
if not, do your custom UI but only for the needed elements.

> 
> >2) Native GUI built into the plug-in. (100% Platform dependent...)
> 
> How does this work ? What is handling GUI event callbacks ? Is the
> plugin a separate thread or task ? Or is it all running as part of the
> engine ?

I'd prefer to separate the things , or you will end up with low-latency
problems.
A GUI hasn't to be very realtime therefore, run the GUI thread just
with normal priority. 
> 
> Network transparency is an illusory goal (for audio) in my
> opinion. However, even if you want to pursue a more limited form of
> it, note that by using X and simply forcing the plugin's cycles to run
> on the same host as the engine, you do have a certain polarity of
> network transparency.

Yea, it would be nice to be able to walk around the studio,
and have a way to fire up your mixer GUI on your preferred workstation,
while the audio engine still runs on the BIG-BOSS machine
( 4way K7 @ 800Mhz  :-) ).

But for low-latency distributed processing you are rights,
the network latency is too high, which makes Quasimodo on beowulf
not very flexible.
But distributing harddisk audio track among multiple machines could
work well, since you don't need low-latency, just like on the local disk case.
IMHO it's a waste of resources to dedicate a 2nd machine to
just recording/playing additional audio tracks.

> 
> As for the sync problem - I don't believe there is a sync
> problem. This is precisely what Quasimodo does now: the UI runs
> in a different thread than the DSP emulation, and it fiddles randomnly
> with the data used by the DSP; there is *no* synchronization between
> them at all. I have had no problems with this, and I cannot find a
> theoretical reason why there should be, because of the atomicity of
> the instructions to store and load floats and integers (which is what
> a parameter change fundamentally reduces to). So I think this is a
> non-issue too. The only sense in which I worry about this is if
> Quasimodo was ever ported to run on an on-card DSP, access to the
> parameter memory might not be so straightforward. But with the new AMD
> Athlon/K7 out in a month or two, on-card DSP's are not looking very
> attractive any more :)

Agreed I can't wait for the K7,
but meanwhile I will get a dual Celeron @ 550 to do my multithreaded DSP hacks.
nice DSP power at 1.1GHz ?
:-)

> >With an event based system, you get automation virtually for free. Many
> >plug-ins won't even need to use custom events for their processing <-> GUI
> >communications, which means they can just send their "parameter change" events
> >and let the engine record the communication if desired. Custom events could be
> >split into two groups - "automation enabled" and "private".
> 
> yes, this is certainly a nice feature, but I am afraid that its too
> slow. if changing the values of a parameter involves any more than
> just a fairly low-cost function call (and particularly if it involves
> a context switch between the UI thread and the engine thread), I have
> some real concerns (based on experiences with Quasimodo) that you
> can't do it fast enough. 
> 
> Particularly not if you hook up the UI to an external controller/fader
> box, which I do all the time. I *sometimes* end up with a full MIDI
> wire (8 MIDI faders all ramped to zero and then back up again to a
> 7bit value). This can translate into about 1 thousand parameter
> changes per second, and this is supposed to be handled asynchronously
> with the engine.

IMHO the GUI thread should queue up incoming events (parameter changes),
and it the event stream gets too dense, just thin out the stream or evaluate
only the most recent events.
It makes no sense to me to send 1000parameter changes/sec to a GUI fader
while the graphics card refresh rate is only 70Hz or so.
I know that you can't ignore all events like volume fader changes.
But with a smart system even when there will be dense event streams,
you can keep the GUI still snappy.

> 
> You're not going to be able to handle this by making an IPC call from
> the UI thread to the engine, and if its checking for parameter changes
> a thousand times a second in some shared memory queue, its going to be
> wasting a lot of cycles that would otherwise be used for DSP. I don't
> understand what kind of event system other than some kind of IPC that
> you might be envisaging ....

The DSP would of course run at higher priority as the GUI thread, therefore
the dense event streams would not have may impact on DSP performance,
but would slow down other processes running at regular priorities.
( thin out the events or keep track only of the most recent events) 

Just for curiousity: what does Quasimodo actually to display the changes ?
polling at regular intervals ?

> 
> I am currently investigating the XRecord extension for automation of
> Quasimodo. I don't see any need to reinvent the wheel here -
> automation of X interfaces is something that has been worked on for 10
> years or so. The X model is fairly nice because the server will buffer
> your events for you until you are ready to handle them, to a
> point. So, you can go through a huge burst of UI changes, and then
> pick up the event stream for automation recording once things calm
> down.

Interesting, but IMHO the GUI elements should be passive , thant means,
the audio engine's automation should drive the elements through sending events.

> 
> Well, I think you should start by handing the plugin a connection to
> the X server and leave it at that. Any native GUI API worth anything
> can take such a connection and get started from there.

see my GUI toolkit-handler proposal ..
I would opt for this.

regards,
Benno.

From - Fri Sep 24 11:19:44 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA03502
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 07:24:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA26036 for linux-audio-dev-list; Thu, 23 Sep 1999 06:22:01 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA26033 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 06:21:54 -0400
Received: from gardena.net ([194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id MAA09548;
	Thu, 23 Sep 1999 12:17:32 +0200
Received: from localhost (localhost [[UNIX: localhost]])
	by gardena.net (8.9.3/8.9.3) id BAA06965;
	Thu, 23 Sep 1999 01:45:14 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Juhana Sadeharju <kouhia@nic.funet.fi>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Date: Thu, 23 Sep 1999 01:40:25 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <19990922160416Z42525-32561+2434@nic.funet.fi>
MIME-Version: 1.0
Message-Id: <99092301451306.00699@goblin.flashnet.it>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 47b3766bfa3e2f92a04cb75eb0ea2e8f

On Wed, 22 Sep 1999, Juhana Sadeharju wrote:
> >From:   Paul Barton-Davis <pbd@Op.Net>
> >
> >Just to float an idea: instead of having the GUI run by anything
> >related to the engine, put the parameters in shared memory (*).
> 
> In my list too. I actully made the playline position transfer via shared
> memory in my improved XWave2. There were some problems... it was like
> the shared memory would have some delay before showing in another process.
> I printed the content of the shared memory play position and it was
>  -1 for a long time even the engine updated the position (I heard the audio).
> Then when the value was finally available (after 1 to 2 seconds) in GUI
> process, the value was jumped to the current position (I never saw the
> earlier positions). Perhaps Linux did something weird paging stuff, who
> knows?

Hmm that sounds very very strange to me ...
Shared memory is shared memory that means if your write to this area,
reading from another process MUST give you the same value.

> >manipulation and possibly display of the parameters and other data,
> >accessed via shared memory. Benno will love this idea, I'm sure :)
> 
> Me too! If GUI peaks the signal level (say) from one memory address, then
> there is no buffers or event queues which could freeze the system or cause
> delay (of the length of buffer) if GUI freezes for a moment.
> Ok, the engine would not freeze at all (if message queues are used for
> events, the engine should use nonblocking mode).

Yes, it the GUI freezes a moment that isn't too tragic, but
if the DSP engine freezes that would mean unsuitable for pro-audio.
But thanks to Ingo, this is a non-issue now.

Benno.

From - Fri Sep 24 11:19:31 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id EAA27900
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 04:57:25 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id EAA25832 for linux-audio-dev-list; Thu, 23 Sep 1999 04:01:45 -0400
Received: from aino.wakkanet.fi (aino.wakkanet.fi [194.157.35.1]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA25828 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 04:01:40 -0400
Received: from localhost (kaiv@localhost)
	by aino.wakkanet.fi (8.9.3/8.9.3) with ESMTP id KAA29341;
	Thu, 23 Sep 1999 10:57:24 +0300
Date: Thu, 23 Sep 1999 10:57:22 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
To: Juhana Sadeharju <kouhia@nic.funet.fi>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
In-Reply-To: <19990922160416Z42525-32561+2434@nic.funet.fi>
Message-ID: <Pine.LNX.4.10.9909231054580.29203-100000@aino.wakkanet.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f4be3ccab81415d4c39feb9e93211175

On Wed, 22 Sep 1999, Juhana Sadeharju wrote:

> not to continue improving the XWave. (My wave editor is not yet available
> even I'm using it already --- I need to complete my major audio engine first.)

Hmm, how functional your editor is now? Maybe a limited beta-release?
I'd be happy to help in testing (and possibly w/ development). 

--
 Kai Vehmanen (kaiv@wakkanet.fi)
 Webmaster, Wakkanet Oy

 

From - Fri Sep 24 11:19:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id FAA29353
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 05:27:00 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id EAA25875 for linux-audio-dev-list; Thu, 23 Sep 1999 04:20:55 -0400
Received: from zapfhahn.bone.twc.de (zapfhahn.bone.twc.de [193.158.34.194]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA25872 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 04:20:50 -0400
Received: from space.twc.de (IDENT:stefan@space.twc.de [193.158.34.195])
	by zapfhahn.bone.twc.de (8.9.3/8.9.3) with ESMTP id KAA06403;
	Thu, 23 Sep 1999 10:14:57 +0200
Received: (from stefan@localhost)
	by space.twc.de (8.8.7/8.8.7) id KAA22182;
	Thu, 23 Sep 1999 10:15:01 +0200
Message-ID: <19990923101501.15227@space.twc.de>
Date: Thu, 23 Sep 1999 10:15:01 +0200
From: Stefan Westerfeld <stefan@space.twc.de>
To: Havoc Pennington <hp@redhat.com>
Cc: gnome-kde-list@gnome.org, linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: AudioServer Standard?
References: <19990918125024.57053@space.twc.de> <Pine.LNX.4.10.9909201005370.6254-100000@icon.labs.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.85e
In-Reply-To: <Pine.LNX.4.10.9909201005370.6254-100000@icon.labs.redhat.com>; from Havoc Pennington on Mon, Sep 20, 1999 at 10:10:39AM -0400
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 65750451f60c1cc4f251ff84e831da33

   Hi!

(I was asked to CC that discussion to linux-audio-devel... however
please make sure that the replies arrive still at the gnome-kde list, as
we're trying to discuss whether aRts is suitable as a common audio server
solution for KDE & Gnome).

On Mon, Sep 20, 1999 at 10:10:39AM -0400, Havoc Pennington wrote:
> On Sat, 18 Sep 1999, Stefan Westerfeld wrote:
> > 
> > Currently, there were some discussions on kde-core-devel regarding what
> > should be the audio server for KDE 2.0. I suggested aRts (well, I wrote
> > it, so I think it's a great thing... ;), another solution would be
> > KAudioServer2 and the third solution would be ESD.
> > 
> 
> We are looking for an ESD replacement or at least a rewrite, and
> apparently it has some technical shortcomings (don't ask me for details, I
> don't know anything about sound). I _definitely_ want to have KDE and
> GNOME using the same sound system.

Yes, that would be just perfect.

> If KDE is for sure going to use aRts and people-who-know say it is
> technically better than esound, I'm one of the C++ nerds over here in
> GNOME-land so I'll try to look at porting the client side to C for us and
> hooking it up via ORBit. I don't think we care if the application itself
> is in C++, though stranger things have happened. :-)

Well, that of course would actually be a nice solution, since it would
allow everyone to use the aRts capabilities fully in desktop applications.

It isn't possible right now to say "KDE is switching to aRts for sure",
because some issues that raised in the discussion on kde-core-devel are
not adressed right now. But I think it can be done, and I'll work on it.
Probably we can get some discussion (definite descision?) about that on
the upcoming KDE II developer meeting, that would be until 10. October.

> Can you tell us about the features of aRts or point us to a web page or
> something?

So, here again a listing of features that aRts has. You'll find some good
information on the aRts web page, in the manual, for instance at

  http://arts.linuxbox.com/doc/manual/index.html

(read section 11, which talks specifically about aRts vs. esd). The 
homepage URL is

  http://linux.twc.de/arts

Of course, the web pages are mainly focused on explaining how aRts is used
as synthesizer, since thats what most people will do with it right now. It
doesn't cover too technical details, too. 

So I tried to make a technical feature list here, hoping some insight in
why I think aRts is the right thing for an audio server (or if you like,
audio framework, audio middleware, multimedia subsystem or something like
that).


== Overview: aRts and its features

+ the core idea: signal flow

  aRts is a signal flow system. That means, that it is based on the assumption
  that multimedia tasks generally can be described as flow graphs with
  components. Arts manages the signal flow between the components.

  Currently the signal flow is assumed to happen always realtime. Further
  enhancements of aRts could also handle non-realtimed signal processing.

+ implementation as CORBA server

  On the other hand, aRts is designed to be a server. That is, it will run,
  and different applications will tell aRts what things to start for signal
  flow evaluation.

  That means that multiple applications share the same signal flow system.
  You could for instance play an mp3 (with a standard, arts compliant mp3
  player) and record the result with your hard disk recording system which
  also runs on the same aRts server.

  If you like, you could also add some midi synthesis.

+ modularity

  The components that are running inside the signal flow evaluation are
  implemented as small modules that are linked to the server (a shared-
  library interface would be no problem for that).

  So if you need a new wave form, a new filter, a new effect, a new sample
  format etc. you simply write a new module.

  Through the signal flow system, it is also possible to draw a signal
  flow (aRts calls that a structure), and reuse that as module in other
  signal flows.

  So you could for instance implement a reverb effect out of some delays
  and some arithmetic modules (and perhaps some filters).

+ fast scheduling

  aRts uses very small components, and schedules them with very little
  overhead. So you don't have some processes which do signal processing
  and connect them with TCP streams (which would really cosume lots of 
  CPU power).

  Instead, all modules are running in one adress space. They are connected
  by ring buffers, which allows you to run 300 modules at a time on a
  PII-350.

+ network transparency

  Since aRts uses CORBA for almost everything, it is network transparent.
  On the other hand, some audio server functionality that has been
  implemented in aRts use TCP to transfer the signal for instance from your
  external (non-arts-module-like) mp3 player to aRts. This TCP stuff is
  also network transparent.

+ gui suppprt

  aRts can build modular GUIs with the same component system (signal flows,
  structures, etc) that is used for building audio stuff. So the GUIs have
  the same features regarding modularity, flexibility, recombination,...
  as the core synthesis.

+ synthesis implemented GUI independant

  All the synthesis modules aRts uses (such as Synth_STD_EQUALIZER) don't
  know anything from the GUI at all. They use no Qt and no whatever. They
  are only connected to the GUI through the same signal flow mechanisms
  that are used for everthing else

+ distribution

  Arts is somewhat ready for distributing flow graphs across an arbitary
  number of servers. Currently, the standard aRts systems run with one
  server that handles audio signal flow (all Synth_* components running
  there), and one server that handles the gui stuff (all Gui_* components
  run there).

  That may be an option for further work on that, either allowing aRts to
  run for instance multiple servers together for signal flow, or add more
  servers for video flow, or add certain selected applications (such as
  your midi sequencer) as own server with own components.

+ availability

  Arts is under development since nearly two years now. It works all the
  time. The flow system is well tested, and the realtime performance is fine.
  It's not some "here I have specs that you might want to read"-project, but
  something that is implemented and known to work.

== Summary

Well, I'll try to end with a brief feature listing, while marking

+ is implemented, can be done with the current (or next) aRts release
? should be possible, but isn't in the code yet
- might be a problem

== features
+ signal flow system
  + realtime
  ? non-realtime
+ consequent server design
+ modularity
+ fast scheduling
+ distribution
+ gui support
+ synthesis is implemented gui & toolkit independant
+ network transparency


== usage scenarios
+ abstraction of /dev/dsp for all applications
  + mix outgoing streams
  + postprocess outgoing streams with effects
  ? get incoming streams (audio recording)
  + full duplex operation (record, process, write)
+ play wavs (for instance for window manager sound)
? hard disk recording
+ realtime midi (sequencer) -> audio conversion
  + timidity style sample based conversion
  + midi synthesis

== possibilities after extending to other media streams
? midi processing
? video processing
    
== problems
- incompatibilities with other solutions such as esd, GMF, NAS,
  KAudioServer1/2, and perhaps some ALSA concepts
- not really designed to be an audio server
- larger as esd for instance
  - code
  - memory
- more CPU load as esd for instance
- requires root (suid or similar) for realtime operation
- uses mico C++ bindings with BOA
- only flow graph editor/gui server for Qt available

Well, thats a brief summary - the best thing to do to see more is to
download a version and play a little with it. And of course - please ask
anything that isn't clear after reading this mail.

  Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-

From - Fri Sep 24 11:20:05 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA31805
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 11:07:14 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA26420 for linux-audio-dev-list; Thu, 23 Sep 1999 09:29:17 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA26417 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 09:29:10 -0400
Received: from gardena.net ([194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id PAA12306;
	Thu, 23 Sep 1999 15:23:53 +0200
Received: from localhost (localhost [[UNIX: localhost]])
	by gardena.net (8.9.3/8.9.3) id OAA00888;
	Thu, 23 Sep 1999 14:49:56 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Stefan Westerfeld <stefan@space.twc.de>, Havoc Pennington <hp@redhat.com>
Subject: Re: [linux-audio-dev] Re: AudioServer Standard?
Date: Thu, 23 Sep 1999 14:23:45 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: gnome-kde-list@gnome.org, linux-audio-dev@ginette.musique.umontreal.ca,
        audiality@swipnet.se
References: <19990923101501.15227@space.twc.de>
MIME-Version: 1.0
Message-Id: <99092314495603.00533@goblin.flashnet.it>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 57a295630409ddc9e9adf49b729d468e

On Thu, 23 Sep 1999, Stefan Westerfeld wrote:
> 
> On Mon, Sep 20, 1999 at 10:10:39AM -0400, Havoc Pennington wrote:
> > On Sat, 18 Sep 1999, Stefan Westerfeld wrote:
> > > 
> > > Currently, there were some discussions on kde-core-devel regarding what
> > > should be the audio server for KDE 2.0. I suggested aRts (well, I wrote
> > > it, so I think it's a great thing... ;), another solution would be
> > > KAudioServer2 and the third solution would be ESD.
> > > 
> > 
> > We are looking for an ESD replacement or at least a rewrite, and
> > apparently it has some technical shortcomings (don't ask me for details, I
> > don't know anything about sound). I _definitely_ want to have KDE and
> > GNOME using the same sound system.
> 
> Yes, that would be just perfect.

Agreed, but I think the definitive audio/multimedia interface will be
Audiality designed from the ground up.
The API is still in the design stage, since we are thinking about
how to implement the most flexible, performant sound engine which scales from
games to highend pro-audio stuff.

Of course KDE and GNOME need a standardized audio sever now,
therefore audiality can't help now, since there is no code yet.
I think a good solution is to support /dev/dsp virtualization like esddsp does.
That means old audio applications will still work, while new apps can take
advantage of the high performance API, which uses for example less membandwidth
using smart IPC techniques like shmem etc.

Later when audiality will be fully fuctional we could provide a compatibility
layer for esd or arts-enabled sound apps.
Right, David ?

> Of course, the web pages are mainly focused on explaining how aRts is used
> as synthesizer, since thats what most people will do with it right now. It
> doesn't cover too technical details, too. 
> 
> So I tried to make a technical feature list here, hoping some insight in
> why I think aRts is the right thing for an audio server (or if you like,
> audio framework, audio middleware, multimedia subsystem or something like
> that).

It shares many concepts with audiality, but I don't know anything about the
design.

> 
> 
> == Overview: aRts and its features
> 
> + the core idea: signal flow
> 
>   aRts is a signal flow system. That means, that it is based on the assumption
>   that multimedia tasks generally can be described as flow graphs with
>   components. Arts manages the signal flow between the components.

the concept is ok.

> 
>   Currently the signal flow is assumed to happen always realtime. Further
>   enhancements of aRts could also handle non-realtimed signal processing.
> 
> + implementation as CORBA server
> 
>   On the other hand, aRts is designed to be a server. That is, it will run,
>   and different applications will tell aRts what things to start for signal
>   flow evaluation.
> 
>   That means that multiple applications share the same signal flow system.
>   You could for instance play an mp3 (with a standard, arts compliant mp3
>   player) and record the result with your hard disk recording system which
>   also runs on the same aRts server.

The audiality idea is similar, you can route audio/multimedia events sources to
arbitrary destinations

> > + modularity
> 
>   The components that are running inside the signal flow evaluation are
>   implemented as small modules that are linked to the server (a shared-
>   library interface would be no problem for that).
> 
>   So if you need a new wave form, a new filter, a new effect, a new sample
>   format etc. you simply write a new module.

also called plugins
:-)

> 
>   Through the signal flow system, it is also possible to draw a signal
>   flow (aRts calls that a structure), and reuse that as module in other
>   signal flows.

supporting multiple instances of the plugin is a required feature for a decent
plugin system.

> 
>   aRts uses very small components, and schedules them with very little
>   overhead. So you don't have some processes which do signal processing
>   and connect them with TCP streams (which would really cosume lots of 
>   CPU power).

Yes calling the Process() function for each plugin is the fastest way to do it,
since you have no process scheduling overhead.
All plugin APIs like VST do this to achieve maximum performance.

> 
>   Instead, all modules are running in one adress space. They are connected
>   by ring buffers, which allows you to run 300 modules at a time on a
>   PII-350.
depens how much CPU each plugin uses.
Try to run 300 instances of Waves Trueverb on a PII350.
:-)

> 
> + network transparency
> 
>   Since aRts uses CORBA for almost everything, it is network transparent.
>   On the other hand, some audio server functionality that has been
>   implemented in aRts use TCP to transfer the signal for instance from your
>   external (non-arts-module-like) mp3 player to aRts. This TCP stuff is
>   also network transparent.

tenwork transparency is ok, but we need to separate the things,
that means if source and destination are on the same machine,
use IPC/shmem to exchange data,
if not then use sockets or so.
But Corba seems a bit slow to me for a high performance event system.

> 
> + synthesis implemented GUI independant
> 
>   All the synthesis modules aRts uses (such as Synth_STD_EQUALIZER) don't
>   know anything from the GUI at all. They use no Qt and no whatever. They
>   are only connected to the GUI through the same signal flow mechanisms
>   that are used for everthing else

Of course the DSP stuff must be separate from the GUI stuff, and the engine and
the GUI should comunicate through a fast event system.

> 
> Well, thats a brief summary - the best thing to do to see more is to
> download a version and play a little with it. And of course - please ask
> anything that isn't clear after reading this mail.

Quite clear your mail.
I will check out arts , seems nice to me.
> 
>   Cu... Stefan
> -- 

tschuess,
Benno.

From - Fri Sep 24 11:20:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA10949
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 12:24:10 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA26620 for linux-audio-dev-list; Thu, 23 Sep 1999 10:56:01 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA26617 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 10:55:57 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46019AbPIWOva>; Thu, 23 Sep 1999 17:51:30 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <99092301590405.00441@localhost.localdomain> (message from David
	Olofson on Thu, 23 Sep 1999 01:09:04 +0200)
Subject: Re: [linux-audio-dev] Plug-in API progress?
Message-Id: <19990923145137Z46019-23519+2383@nic.funet.fi>
Date:   Thu, 23 Sep 1999 17:51:30 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 62a5513beec1519115f64f1c645ff569

>From:   David Olofson <audiality@swipnet.se>
>
>Hmm... I kind of like the hardcoding idea. But I doubt that it'll pay off:
>Have a look at the engine side... And what if you have say 15 parameters of
>which you may automate any few? That's a veeeeery long stack frame, most of
>which will be unused most of the time. (Or am I missing the point?)

Yep. But it is quite rare that all 15 channels are sent interleaved
through one channel.

I see my plug-in suggestion needs an improvement in the cases we want
send many channels to one plug-in. The function call would need to have
variable number of arguments and thus the closure system seems to be
much better. Besides I already moved to closure system.

>How do we access parameters (that are used less frequently) if they're not
>"registered" as an event input in the current net?

Parameters are part of the network. The network will have both the audio
network and the control network mixed together.

>(And BTW, if the code is supposed to be recompiled

No recompilation is needed. The plug-in indeed has to test what kind of
input/output systems (buffer, events, static) it should use.

If you want avoid the test, then write specialized plug-ins: only
buffer inputs and outputs are allowed (such as in Csound). It is up
to plug-in author. I just wanted to provide more than one choise.

>Unfortunately, there's probably no way to avoid the fact that plug-ins
>must be possible to deliver as closed source binaries...

Those works very well in the suggested system.

>He can just send some request events to the plug-ins init function.

Ok.

>Well, my idea was to make the basic system even simpler,

Your system sounds more complicated than my system... yes it does. :-)

>That is, an event output buffer is always sent directly to an input of some
>other plug-in?

Yes.
The engine firing the plug-ins will make sure the next plug-in gets only
the events relevant to the possible audio buffer the next plug-in also gets.

>I'm afraid that will result in two interfaces/subsystems that overlap too
>much... And is your event system really that much simpler to implement?

How would you implement the curve delivery in your system? Both static
predefined curve and the real-time curve coming from other part of the flow
network?

Yours,

Juhana

From - Fri Sep 24 11:20:16 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA21615
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 13:37:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA26532 for linux-audio-dev-list; Thu, 23 Sep 1999 10:16:37 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA26529 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 10:16:30 -0400
Received: from op.net (d-bm3-17.ppp.op.net [209.152.194.87]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id KAA25188 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 10:12:13 -0400 (EDT)
Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id LAA08323; Thu, 23 Sep 1999 11:08:22 -0400
Date: Thu, 23 Sep 1999 11:08:22 -0400
Message-Id: <199909231508.LAA08323@op.net>
From: Paul Barton-Davis <pbd@Op.Net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] signal flow in Quasimodo
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 0edbc36898c0124a9d4577c2eb0c2125

Juhana had written privately to me:

>About that earlier mail on the flow algorithm: I indeed were looking
>for the info how the signal is made to flow. Particularly I'm interested
>in how a feedback loop is handled. Simply setting nodes and initially empty
>arcs doesn't work because a node might get input from a second node which
>gets input from the first node.
>
>I solved the problem by having delay elements to output their delay samples
>to their output arcs. Only generator elements and delay elements have outputs
>without getting any input first.

this is essentially how Quasimodo (and Csound) work as well. but to
clarify:

1) all output is written to a staging area via the opcodes out, outs,
   outq outh, etc. (these write 1, 2, 4 and 8 channels
   respectively). Each of the "out" opcodes sets a flag saying that
   output has been produced. At the end of each DSP control cycle, if
   the output flag is set, the output is sent to the DAC; otherwise, a
   control-cycle's worth of silence is sent.

2) all input from a hardware source is read into a staging area from
   where it can be retrieved by the opcodes in, ins, inq, inh etc
   (analogs to the "out" series).

   all input from a soundfile is requested explicitly by an opcode. 
   input files are shared across all modules and opcodes, and each may
   be reading from separate areas of the file.

3) delay lines and other opcodes needing their own signal flow do something
   described in Csound as an "auxilliary allocation". That is, their closure
   contains a pointer like this:

	      AUX *delay_line;

   and during the constructor/initializer for the opcode (run at
   "i-time") a function is called to allocate memory and store the
   location in this pointer. the engine also notes the allocation, and
   associates it with the module. when the module is deleted, the
   memory is deleted too - its basically an internal heap system. The
   opcode can do anything it wants with this memory - it is ignored to
   the "engine" except with regards to allocation and cleanup. this is
   how delay lines work.

   Quasimodo is mostly identical: we just use a more C++-like syntax
   and semantics.  Its called DynamicMemory, and the C++ compiler
   ensures that it gets cleaned up instead of the engine
   code. Quasimodo also has some hooks to allow allocation of enormous
   disk-based delay lines, so that we do delays of several minutes if
   necessary. I'm an experimental musician :)

4) there is no way to control signal flow ordering except through the
   alphanumeric sorting by name of modules in the DSP work queue. that
   is, if you have a signal generator named "xxx" and a delay line
   called "aaa", then on the first control cycle, only silence will
   emerge, because the signal generator will run *after* the delay
   line. there will be a similar overrun at the end, unless the end
   is caused by deleting the generator module, which instantly sets
   its outputs to zero.

   This may change at some point.

Another matter: do you have any material that you think would be good
to include in my "Why Linux?" brochure for AES this weekend ?

--p

From - Fri Sep 24 11:20:11 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA16191
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 13:00:32 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA26735 for linux-audio-dev-list; Thu, 23 Sep 1999 11:52:06 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA26732 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 11:52:03 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46412AbPIWPra>; Thu, 23 Sep 1999 18:47:30 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <199909231508.LAA08323@op.net> (message from Paul Barton-Davis on
	Thu, 23 Sep 1999 11:08:22 -0400)
Subject: Re: [linux-audio-dev] signal flow in Quasimodo
Message-Id: <19990923154736Z46412-8255+2372@nic.funet.fi>
Date:   Thu, 23 Sep 1999 18:47:30 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 261725202aac6dd76212bb0574f91723

>From:   Paul Barton-Davis <pbd@Op.Net>
>
>   is, if you have a signal generator named "xxx" and a delay line
>   called "aaa", then on the first control cycle, only silence will
>   emerge, because the signal generator will run *after* the delay
>   line.

Hmm.. the delay will anyway produce some silence in the first place.
Do you mean extra silence? That is, if the delay is N and control period C,
then the actual silence is N+C and not N as should be?

That is handled correctly in my system.

Good luck to AES. I think there is no need to tell everything but
at least that Linux is able to have minimal latencies and that there
are N+1 possible users for their products. A quick list of existing
audio software could do fine for end users.

Please, if possible, don't stand at the doors and stick a paper note to
people's hand. Instead, go through every commercial software producer
and start talking if they have plans to go for Linux, then give that
paper note to them if they really want it. Let the crackpots only stand
at the doors! Try avoid "I love Linux" T-shirt at that day...

Yours,

Juhana

From - Fri Sep 24 11:20:12 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA16632
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 13:03:49 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA26770 for linux-audio-dev-list; Thu, 23 Sep 1999 12:02:15 -0400
Received: from mailserver2.hrz.tu-darmstadt.de (mailserver2.hrz.tu-darmstadt.de [130.83.22.129]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA26766 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 12:02:04 -0400
Received: from sun27.hrz.tu-darmstadt.de (sun27.hrz.tu-darmstadt.de [130.83.253.1])
	by mailserver2.hrz.tu-darmstadt.de (8.9.1a/8.9.1) with ESMTP id RAA01279;
	Thu, 23 Sep 1999 17:54:38 +0200 (MET DST)
Received: (from news@localhost) by sun27.hrz.tu-darmstadt.de (8.7.1/8.7.1.2pm+udb) id RAA29999; Thu, 23 Sep 1999 17:56:08 +0200 (MET DST)
To: comp.os.linux.misc@tu-darmstadt.de
Path: news.tu-darmstadt.de!news.hrz.uni-kassel.de!fu-berlin.de!logbridge.uoregon.edu!hearst.acc.Virginia.EDU!murdoch.acc.Virginia.EDU!not-for-mail
From: "David J. Topper" <topper@virginia.edu>
Newsgroups: comp.os.linux.portable,comp.os.linux.misc
Subject: [linux-audio-dev] Neomagic audio test (please try)
Date: Thu, 23 Sep 1999 11:49:45 -0400
Organization: UVA - VCCM
Lines: 21
Message-ID: <37EA4C19.D770FF97@virginia.edu>
NNTP-Posting-Host: jangle.music.virginia.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i686)
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>,
        uva-lsp@virginia.edu, dlphilp@bright.net, info@opensound.com
Xref: news.tu-darmstadt.de comp.os.linux.portable:6323 comp.os.linux.misc:399346
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: d0ec4b6215260131e3cf82a9215941d2

Hi all,

I've been trying to buy a laptop with very little luck lately.  The work
I'm doing seems to limit my choices to the Crystal Sound/Audio
chipsets.  But I'm really curious if ESS and Neomagic chips can do full
duplex audio under Linux with OSS.

So, I've rigged up a pretty simple test for folks to try out.  I'm
really interested to know.  See the following URL for simple
instructions:

	http://presto.music.virginia.edu/topper/delay_test.html

Thanks all,

DT
--
Technical Director, Virginia Center for Computer Music
Programmer / Analyst, Dean's Office (School of A&S)
http://www.people.virginia.edu/~djt7p
(804) 924-6887

From - Fri Sep 24 11:20:15 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA17829
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 13:11:45 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA26729 for linux-audio-dev-list; Thu, 23 Sep 1999 11:50:24 -0400
Received: from mail.virginia.edu (mail.Virginia.EDU [128.143.2.9]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id LAA26726 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 11:50:20 -0400
Received: from neon.mail.virginia.edu by mail.virginia.edu id aa15529;
          23 Sep 99 11:46 EDT
Received: from virginia.edu (djt7p@jangle.music.Virginia.EDU [128.143.140.24])
	by neon.mail.Virginia.EDU (8.8.7/8.8.7) with ESMTP id LAA12901;
	Thu, 23 Sep 1999 11:45:24 -0400 (EDT)
Message-ID: <37EA4C19.D770FF97@virginia.edu>
Date: Thu, 23 Sep 1999 11:49:45 -0400
From: "David J. Topper" <topper@virginia.edu>
Organization: UVA - VCCM
X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i686)
MIME-Version: 1.0
Newsgroups: comp.os.linux.portable,comp.os.linux.misc
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>,
        uva-lsp@virginia.edu, dlphilp@bright.net, info@opensound.com
Subject: [linux-audio-dev] Neomagic audio test (please try)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 925c6583ed8ca409bdbe5d8dd2c925d3

Hi all,

I've been trying to buy a laptop with very little luck lately.  The work
I'm doing seems to limit my choices to the Crystal Sound/Audio
chipsets.  But I'm really curious if ESS and Neomagic chips can do full
duplex audio under Linux with OSS.

So, I've rigged up a pretty simple test for folks to try out.  I'm
really interested to know.  See the following URL for simple
instructions:

	http://presto.music.virginia.edu/topper/delay_test.html

Thanks all,

DT
--
Technical Director, Virginia Center for Computer Music
Programmer / Analyst, Dean's Office (School of A&S)
http://www.people.virginia.edu/~djt7p
(804) 924-6887

From - Fri Sep 24 11:20:13 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA16917
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 13:05:30 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA26783 for linux-audio-dev-list; Thu, 23 Sep 1999 12:04:35 -0400
Received: from upf.es (newton.upf.es [193.145.54.60]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA26780 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 12:04:30 -0400
Received: from mtg150.upf.es (mtg150.upf.es [193.145.44.150])
	by upf.es (8.9.0/8.9.0) with SMTP id RAA15020;
	Thu, 23 Sep 1999 17:59:56 +0200 (MET DST)
From: Maarten de Boer <maarten.deboer@iua.upf.es>
Reply-To: maarten.deboer@iua.upf.es
To: kouhia@nic.funet.fi, linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] signal flow in Quasimodo
Date: Thu, 23 Sep 1999 18:06:35 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <19990923154736Z46412-8255+2372@nic.funet.fi>
MIME-Version: 1.0
Message-Id: <99092318073003.11430@mtg150.upf.es>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4d10a1514a39423d35a0678e88d9b0f4

Juhana wrote:
> at the doors! Try avoid "I love Linux" T-shirt at that day...

But maybe that's the only clothing he has ;-)

Maarten

From - Fri Sep 24 11:20:21 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA23764
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 13:49:23 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA26880 for linux-audio-dev-list; Thu, 23 Sep 1999 12:42:02 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA26877 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 12:41:58 -0400
Received: from someip.ppp.op.net (d-bm3-17.ppp.op.net [209.152.194.87]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id MAA11268 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 12:37:46 -0400 (EDT)
Message-Id: <199909231637.MAA11268@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress? 
In-reply-to: Your message of "Thu, 23 Sep 1999 00:28:28 +0200."
             <99092301080504.00441@localhost.localdomain> 
Date: Thu, 23 Sep 1999 13:33:57 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: bff65251d26b1d9dfe856aabad11eac3

>> >Two problems: Synchronization of the GUI and processing code, and
>> >network transparency. 
>> 
>> Network transparency is an illusory goal (for audio) in my
>> opinion. However, even if you want to pursue a more limited form of
>> it, note that by using X and simply forcing the plugin's cycles to run
>> on the same host as the engine, you do have a certain polarity of
>> network transparency.
>
>What I have in mind here is using one machine to run the client application
>and another machine, or possibly a cluster to do the processing. Distributing
>GUI code all over the place gets a bit too messy for my taste... And it

Thats not what I was suggesting. We need to get some clear terminology
here, because multithreading and X creates an additional layer of
(potential) complexity not present in the VST/TDM/EASI worlds. I
humbly suggest:

* master

     - an application that runs the [engine] and [plugins]

* engine
     
     - 1 or more threads running as part of the [master] that handles
       the actual numerical processing done to input and output
       signals, along with scheduling etc.

* ui-thread

     - 1 thread (because X is still not really multi-threaded) that
       (in most cases) interacts with an X server, and is responsible
       for (1) altering the UI to reflect information received from
       the engine (2) sending requests to the engine that reflect
       information from the user interface.

* plugin
  
     - a program in some (unspecified) language that contains
       (1) a part that will be run by the engine and (2) a part that
       will be run by the ui-thread

* display 
  
     - the screen where the user interface can be seen. Under X, this
       may not be attached to the same machine as the one running the 
       [master]

Using this terminology, what I was suggesting was that the ui-thread
{c,w,sh}ould run on the same machine as the engine, but that because
of X, this didn't prevent you from the display being on some other
machine.

BTW, I don't think we're ready to consider clusters yet. The latency,
by which I mean the delay in sending a message onto a previously empty
wire, is too great for audio synchronization.

>requires the GUI code to actually work on the same system as the DSP code -
>while you most probably don't want to load Qt, GTK+ or whatever on every node
>of a Beowulf. And what if you decide to build a cluster of Alpha or PPC boxes?

GTK is ported to these platforms. But thats beside the point. The UI
code *has* to run on the same host if you want low-latency interaction
between the interface and the engine. If you don't care about that,
then you have to devise a network IPC protocol to relay changes in the
UI to the master. This seems silly.


>> As for the sync problem - I don't believe there is a sync
>> problem. This is precisely what Quasimodo does now: the UI runs
>> in a different thread than the DSP emulation, and it fiddles randomnly
>> with the data used by the DSP; there is *no* synchronization between
>> them at all. I have had no problems with this, and I cannot find a
>> theoretical reason why there should be, because of the atomicity of
>> the instructions to store and load floats and integers (which is what
>> a parameter change fundamentally reduces to). So I think this is a
>> non-issue too.
>
>Not if you plan to support more complex data types than integers and floats.
>Which is the case with the new plug-in API...

Sorry, but I don't think so. When you add two numbers, you are adding
floats or integers. If you are proposing something of the form:

       res->a = src->a + src->b;

I again suggest that you read the opcode source to Csound, even though
this can be a painful experience. This is not how you code realtime
DSP functions. This is also why Csound makes a (permeable) distinction
between variables that can change at different rates. In Csound, if a
variable is only ever set once per instantiation of the, errr, plugin
:), then you do this:

	      struct my_closure : struct basic_closure {
		     float *a;
		     float *b;


		     float _a;
		     float _b;		     
	      };

and in the initialization stage of the plugin, you do this:

             closure->_a = *closure->a;	     
             closure->_b = *closure->b;	     

If the variable can change more rapidly than that, then certainly
there is a potential problem with:

        res->a = src->a + src->b

if the UI can twiddle with src->a and src->b directly. But the
twiddling is still atomic, and besides, there is no computer-based UI
that will allow you to alter two things simultaneously. So in reality,
a or b alway change independently.

the only case i can imagine where this is not true is when a single
on-screen control element actually affects two internal variables, but
thats just bad design of the plugin, IMHO.

>And, what about timing? How do you handle sample accuracy without going to
>single sample buffers? Events handle that in a clean and low cost way.

No they don't. You can't do sample accuracy without reducing the size
of the engine control cycle (the number of samples it generates
between checking for a new event in some way) to 1.

>kind of programming on the Amiga. Fun for a while, but then you start to
>realize that a faster CPU is always more flexible. At least with an RTOS...)

and with Ingo on your side, you realize than a faster non-RTOS is always more
flexible, too :)

>> yes, this is certainly a nice feature, but I am afraid that its too
>> slow. if changing the values of a parameter involves any more than
>> just a fairly low-cost function call (and particularly if it involves
>> a context switch between the UI thread and the engine thread), I have
>> some real concerns (based on experiences with Quasimodo) that you
>> can't do it fast enough. 
>
>It doesn't even involve a function call per event. Events are written to Event
>Ports using inline code and dynamic memory allocation is done from heaps with
>limited life time; also using inline code. The only context switches/sync
>points are the global ones for client/engine communication.

this makes no sense to me. lets say i want to change the delay time on
a delay line. i tweak a virtual on-screen knob to do this. what does
the ui-thread do to cause the delay time to change ? how does the
engine know that it has happened, if indeed it has to (in Quasimodo,
it has no idea - the value at a certain memory location just gets
altered). this seems fundamental to me, and i simply don't understand
from what you've written so far how the event system can do this - it
seems based (both in terms of its name and the API) on a polling
system. This is not going to work, or at least, it can't do the things
I want Quasimodo to do. There is no polling in Quasimodo: the ui
thread has direct access to the memory containing the variables used
by the DSP thread. There is no communication between them, and the DSP
code does not "poll"/look-at/check any memory locations to see if
anything has been changed, ever.

>Shouldn't be a problem. Also note that the events can be handled with
>sample accuracy no matter what buffer size you use. If the MIDI
>interface plug-in can extract exact timing info from the MIDI data,
>that can be used to timestamp the events, so that plug-ins may use
>the information if desired.

i don't know what you're thinking of here. MIDI interfaces don't do
timestamping. the MTC messages are of way too coarse a resolution for
timing purposes, though they could be used for certain kinds of sync.

From - Fri Sep 24 11:20:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA30048
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 18:06:07 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA27313 for linux-audio-dev-list; Thu, 23 Sep 1999 17:08:23 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA27308 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 17:08:20 -0400
Received: from localhost.localdomain (dialup57-1-28.swipnet.se [130.244.57.28]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id XAA05654; 
          Thu, 23 Sep 1999 23:04:01 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Benno Senoner <sbenno@gardena.net>, Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: [l Re: Plug-in API progress?
Date: Thu, 23 Sep 1999 21:23:53 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <99092301043804.00699@goblin.flashnet.it>
MIME-Version: 1.0
Message-Id: <99092322073700.00442@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id XAA05654
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA30048
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 7db1e2b2691cbc6ec0254b7768fca7fa

On Thu, 23 Sep 1999, Benno Senoner wrote:
[...]
> > With an event based system, you get automation virtually for free. Many
> > plug-ins won't even need to use custom events for their processing <-> GUI
> > communications, which means they can just send their "parameter change" events
> > and let the engine record the communication if desired. Custom events could be
> > split into two groups - "automation enabled" and "private".
> 
> Agreed, I like this idea,
> for example the volume-slider (the GUI part) of a gain-control plugin just
> installs an event-sending port and sends the events to the plugin DSP code.
> Plus the DSP code installs an event-sending port and connect the event-receiver
> port of the volume-slider.
> That means if someone (a sequencer/ or arbitrary plugin) changes the gain value,
> the fader would move automagically in the correct position.
> Or is this suboptimal ?

Well, with the event system I'm working on is based on Recieve Ports only. That
is, you don't write all your events with destination addresses to a single
output buffer for dispatching by the engine, as in the design I might have
mentioned earlier. (Perhaps I'll move back to that kind of design, but I'd
really like some realistic processing net models with traffic statistics first.)

What you get is an input buffer of events from multiple sources. Each event
has a reference to the port that the sender would like to have any responses
posted to.

That is, there's no way to broadcast, or even send a single event to more than
one port. You have to create one instance of the event, and write the pointer
to it to the buffer of each recipient. Something like that will have to be
done somewhere anyway - I'm just not sure there's a point in demanding that
functionality from engine implementations.

There's one trick that *could* be done at virtually no cost though -
sending the same buffer to multiple recipients. What I'm getting at is this: If
the DSP <-> GUI communication is based on the two sending events directly to
each other's event ports, the automation system could tap data from those
communication paths by scanning the GUI -> DSP buffers for input, and sending
it's output to both the GUI and the DSP code.

> Do you plan network-transparency to high bandwidth streams too or only
> for the event system.
> networked evens make sense to me, like sending MIDI events over network.
> But sending 60 tracks over the net is a bit harder.

Not a hardware problem, but what I have in mind isn't really networking - it's
about building clusters using 100 MB or gigabit ethernet with RTLinux RT
communication drivers. More like extending connecting the machines into
something like a huge SMP box, than building a network...

Anyway, I still think there are uses for higher latency and lower bandwidth
streaming over networks, perhaps with Rether or a similar protocol. (Rether is
like "RTLinux for ethernet" - it provides a real time protocol with guaranteed
maximum latency and bandwidth allocation, and runs TCP/IP on the unallocated
time slots.) "Office multimedia streaming" isn't exactly my biggest interest,
but I don't think we should eliminate the possibilities to support that kind of
things.

> We should take an approach similar to X:
> it we are forced to use the network use it,
> if there are better alternatives like shmem, use the latter.

Yes, optimize for the situation where the speed is really needed, and just keep
in mind that it should be possible to extend it to support other environments.
Trying to support *everything* right in the basic protocols is bound to fail.
"Sub nets & gateways" philosophy rules here, I think...

[...GUI...]
> Agreed, but keep a door open for multiple toolkits (see my proposed multiple
> GUI handlers), since I wouldn't code in GTK afer falling in love with Qt.
> :-)

If you just create a window and hand over the X connection (as Paul
Barton-Davis suggested), you shouldn't really need much toolkit support from
the GUI engine, I think... It's much like running Qt, GTK+, Tk, <whatever>
applications under a window manager.

> If you need a writer for the Qt-GUI handler .. I'm here ...
> :-)

<legal stuff>
Speaking of Qt; I came up with an interesting licencing problem a while ago.

Let's say we define a GUI markup language for the plug-in API, and developers
start developing proprietary, closed source plug-ins for it. And then someone
hacks a host that uses Qt to render GUIs for plug-ins using our API... Who pays
the developer's licence for the closed source plug-ins?

Reading the QPL, I get the impression that developing closed source code that
uses QPL in *any* way requires the $$$ license. (The IANAL disclaimer applies.)
But the plug-in developers didn't intend their plug-ins to run under a Qt host,
or perhaps didn't even know that something like that could be written. Does
that mean that the end user - by loading a closed source plug-in from a
developer without a Qt developer's license on the Qt host - is guilty of
breaking the QPL?
</legal stuff>


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Sep 24 11:20:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA24811
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 17:31:03 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA27260 for linux-audio-dev-list; Thu, 23 Sep 1999 16:30:57 -0400
Received: from heroine.tampa.fl.us (alpha-iota97.resnet.usf.edu [131.247.220.97]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id QAA27257 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 16:30:54 -0400
Received: (qmail 13425 invoked from network); 23 Sep 1999 20:08:38 -0000
Received: from localhost (HELO earthling.net) (root@127.0.0.1)
  by localhost with SMTP; 23 Sep 1999 20:08:38 -0000
Message-ID: <37EA88C6.52F8A3B3@earthling.net>
Date: Thu, 23 Sep 1999 16:08:38 -0400
From: Adam Williams <broadcast@earthling.net>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Example plugin solution
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: ca8abf30a6bde24e946c1fe5099f7c52

The way I've been doing it for 2 years is fork one instance of the
plugin as a GUI and fork a seperate instance of the plugin for every
channel as a DSP engine.  The GUI does one thing only: whenever the
user changes a widget, it sends its configuration to the plugin
server.  The plugin server then propogates the configuration data to
the DSP instances.  The DSP instances simply handle two events:  buffer
process and reconfigure.  Now you're going to need to spend some time
on the handshaking.  If you want to parallelize the DSP you're better
off parallelizing at the plugin level and running each plugin
sequentially.  Maybe enable the most time consuming plugins to process
multiple channels over several CPUs but make the light plugins single
channel, single processor.  If you parallelize at the render level
you can't share plugins between channels or bounce tracks, pure and
simple.
-- 
                               Heroine Virtual
                        freeyellow.com/members4/heroine
                      Render the impossible into reality

From - Fri Sep 24 11:20:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA29257
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 18:01:04 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA27316 for linux-audio-dev-list; Thu, 23 Sep 1999 17:08:35 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA27312 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 17:08:23 -0400
Received: from localhost.localdomain (dialup57-1-28.swipnet.se [130.244.57.28]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id XAA05695; 
          Thu, 23 Sep 1999 23:04:05 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Benno Senoner <sbenno@gardena.net>, Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Date: Thu, 23 Sep 1999 22:31:21 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <99092301385705.00699@goblin.flashnet.it>
MIME-Version: 1.0
Message-Id: <99092323050002.00442@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id XAA05695
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA29257
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: fa620b2b4b948f33dedbef9bc0d8f905

On Thu, 23 Sep 1999, Benno Senoner wrote:
[...]
> > >2) Native GUI built into the plug-in. (100% Platform dependent...)
> > 
> > How does this work ? What is handling GUI event callbacks ? Is the
> > plugin a separate thread or task ? Or is it all running as part of the
> > engine ?
> 
> I'd prefer to separate the things , or you will end up with low-latency
> problems.
> A GUI hasn't to be very realtime therefore, run the GUI thread just
> with normal priority. 

Not only that: With such a design (apart from it being plain wrong according
to many schools of design), you *can't* port your plug-ins to dedicated DSP
systems, nor some kinds of RT kernel based engines, as you can't execute, or
even load+link GUI code in the same environment as the DSP code runs in.
(Personally, I don't even think GUI and processing code should be allowed to be
in the same address space...)

> > Network transparency is an illusory goal (for audio) in my
> > opinion. However, even if you want to pursue a more limited form of
> > it, note that by using X and simply forcing the plugin's cycles to run
> > on the same host as the engine, you do have a certain polarity of
> > network transparency.
> 
> Yea, it would be nice to be able to walk around the studio,
> and have a way to fire up your mixer GUI on your preferred workstation,
> while the audio engine still runs on the BIG-BOSS machine
> ( 4way K7 @ 800Mhz  :-) ).

And I certainly DON'T want to listen to the cooling compressors and fans of a
machine like that, so remote GUI is not only cool, but *required* for any
serious high end applications. Preferably, the X terminal should have a flash
disk (if any disk at all), and no fans. The Big Cool Box should be in the next
room.

> But for low-latency distributed processing you are rights,
> the network latency is too high, which makes Quasimodo on beowulf
> not very flexible.

The latency is quite low with decent NICs and real time capable drivers and
protocols. It's probably not good enough to get below the 3 ms limit now, but
in a big hard disk recording system, up to 50 ms latency for track insert
effects isn't all that bad. The real low latency stuff and final master mixing
should be done on the machine with the audio cards, of course.

The point: 50 ms latency is a lot better than having to resort to off-line
processing. True, the bus on an SMP system is faster than ethernet with RT
drivers, but can anyone tell me how to build a 16-way Celeron 500...? ;-)

[...]
> IMHO the GUI thread should queue up incoming events (parameter changes),
> and it the event stream gets too dense, just thin out the stream or evaluate
> only the most recent events.
> It makes no sense to me to send 1000parameter changes/sec to a GUI fader
> while the graphics card refresh rate is only 70Hz or so.
> I know that you can't ignore all events like volume fader changes.
> But with a smart system even when there will be dense event streams,
> you can keep the GUI still snappy.

A classic and simple solution is to run the GUI's event parsing until the
buffers are empty, and then update the display. That way, you can't overload
the GUI, but will still reach the maximum refresh rate the video system can cope
with. (Somewhat like 3D games; the frame rate is always determined by the CPU
and video processor power, while the logic engine runs at a fixed time base in
the background, or calculates animations for the ammount of time elapsed since
it was last invoked, in the case of a single thread engine.)

[...]
> > I am currently investigating the XRecord extension for automation of
> > Quasimodo. I don't see any need to reinvent the wheel here -
> > automation of X interfaces is something that has been worked on for 10
> > years or so. The X model is fairly nice because the server will buffer
> > your events for you until you are ready to handle them, to a
> > point. So, you can go through a huge burst of UI changes, and then
> > pick up the event stream for automation recording once things calm
> > down.
> 
> Interesting, but IMHO the GUI elements should be passive , thant means,
> the audio engine's automation should drive the elements through sending events.

Agree. For timing precision, everything should be controlled from within the
engine, in order to avoid the nasty out-of-sync problems some synths with
DSP+MCU have. Ever tried programming fast, percussive sounds on that kind of
synths? Any analog feel should be *simulated*; not a random side effect of the
system design...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Sep 24 11:20:36 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA31982
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 18:19:13 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA27433 for linux-audio-dev-list; Thu, 23 Sep 1999 17:39:23 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA27430 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 17:39:19 -0400
Received: from localhost.localdomain (dialup57-1-28.swipnet.se [130.244.57.28]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id XAA16518; 
          Thu, 23 Sep 1999 23:34:33 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Benno Senoner <sbenno@gardena.net>,
        Stefan Westerfeld <stefan@space.twc.de>,
        Havoc Pennington <hp@redhat.com>
Subject: Re: [linux-audio-dev] Re: AudioServer Standard?
Date: Thu, 23 Sep 1999 23:20:36 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: gnome-kde-list@gnome.org, linux-audio-dev@ginette.musique.umontreal.ca
References: <99092314495603.00533@goblin.flashnet.it>
MIME-Version: 1.0
Message-Id: <99092323404803.00442@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id XAA16518
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA31982
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f99af27b0cea69614769812651993ed1

On Thu, 23 Sep 1999, Benno Senoner wrote:
[...]
> Later when audiality will be fully fuctional we could provide a compatibility
> layer for esd or arts-enabled sound apps.
> Right, David ?

The basic "compatibility layer" would be the /dev/dsp emulation, that Audiality
will have as well. Perhaps aRts could run as a client to Audiality as a
quick'n'dirty solution to get it all integrated? That way, applications
expecting aRts would still work, and the whole system could still be integrated
without having to port everything to one of the engines.

[...]
> It shares many concepts with audiality, but I don't know anything about the
> design.

Indeed, and I'll look more closely at the aRts code. Perhaps there is time and
work to save by reusing parts of aRts in the new engine. (Which might be
Audiality, or something else - my efforts so far have been in other areas than
hacking actual engine code.) Depends on the coding style, and how well aRts
fits with the new plug-in API currently in the design stage.

[...]
> > + network transparency
> > 
> >   Since aRts uses CORBA for almost everything, it is network transparent.
> >   On the other hand, some audio server functionality that has been
> >   implemented in aRts use TCP to transfer the signal for instance from your
> >   external (non-arts-module-like) mp3 player to aRts. This TCP stuff is
> >   also network transparent.
> 
> tenwork transparency is ok, but we need to separate the things,
> that means if source and destination are on the same machine,
> use IPC/shmem to exchange data,
> if not then use sockets or so.
> But Corba seems a bit slow to me for a high performance event system.

I wouldn't worry much about the actual implementation. However, what does the
APIs look like, WRT dependencies on other APIs and standards? I'd rather stick
with very low level stuff, especially in the plug-in API. Partly for
performance reasons, partly because it makes it easier to port to exotic
environments like DSP farms, clusters and real time kernels, like RTLinux.

Also, I start to prefer C to C++, at least for this kind of stuff... Perhaps
I've read too much Linux kernel code? ;-) (And, I was an asm die hard for a few
years, when I hacked on the Amiga...)

> > + synthesis implemented GUI independant
> > 
> >   All the synthesis modules aRts uses (such as Synth_STD_EQUALIZER) don't
> >   know anything from the GUI at all. They use no Qt and no whatever. They
> >   are only connected to the GUI through the same signal flow mechanisms
> >   that are used for everthing else
> 
> Of course the DSP stuff must be separate from the GUI stuff, and the engine and
> the GUI should comunicate through a fast event system.

Indeed. Very important for the exotic environments mentioned above, and for any
truly useful form of network transparency.


Regards,


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Sep 24 11:20:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA09781
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 19:32:23 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA27685 for linux-audio-dev-list; Thu, 23 Sep 1999 18:38:09 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA27682 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 18:38:04 -0400
Received: from localhost.localdomain (dialup57-1-28.swipnet.se [130.244.57.28]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA25456; 
          Fri, 24 Sep 1999 00:33:46 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Juhana Sadeharju <kouhia@nic.funet.fi>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Plug-in API progress?
Date: Thu, 23 Sep 1999 23:51:05 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <19990923145137Z46019-23519+2383@nic.funet.fi>
MIME-Version: 1.0
Message-Id: <99092400400104.00442@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id AAA25456
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA09781
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 518c9aedb7380ba47274b82332e086aa

On Thu, 23 Sep 1999, Juhana Sadeharju wrote:
> >From:   David Olofson <audiality@swipnet.se>
> >
> >Hmm... I kind of like the hardcoding idea. But I doubt that it'll pay off:
> >Have a look at the engine side... And what if you have say 15 parameters of
> >which you may automate any few? That's a veeeeery long stack frame, most of
> >which will be unused most of the time. (Or am I missing the point?)
> 
> Yep. But it is quite rare that all 15 channels are sent interleaved
> through one channel.

What I meant that it's more expensive for a plug-in to check for events on
multiple inputs than to check a single input and decode destinations when
events do arrive. The multiple channels will always be there, while you can
have huge event decoding case() statements without any extra overhead. (Ok,
you'll get cache problems at some level... ;-)

The problem is more obvious when the number of events per process() call is
close to, or less than the number of (connected) event destinations. This will
usually be the case in the kind of nets I have in minds... IMO, modular soft
synths should use control signals - not events - for the high bandwidth control
data.

> I see my plug-in suggestion needs an improvement in the cases we want
> send many channels to one plug-in. The function call would need to have
> variable number of arguments and thus the closure system seems to be
> much better. Besides I already moved to closure system.

Sending a pointer-to-pointer to buffer for inputs and one for the outputs (like
VST and my proposals do) is another way, but yes, closures are probably even
better, as you can just keep the array of pointers in there. No need to send
pointers on the stack, and no need for the engine to keep track of the
buffer pointer arrays separately.

However, how does the engine access the pointers in that case? I'd give the
plug-in the opportunity to decide where it wants the pointers, and then have
the engine ask for the addresses. About the same work as with my VST style
proposal on the engine side, but we get it nicely hardcoded on the plug-in
side. :-)

> >How do we access parameters (that are used less frequently) if they're not
> >"registered" as an event input in the current net?
> 
> Parameters are part of the network. The network will have both the audio
> network and the control network mixed together.

Yes... As I want it - hard sync between event timing and timing of other data.
I was just wondering about the physical implementation, and where it fits into
your proposal with fixed destinations with individual input buffers.

> >(And BTW, if the code is supposed to be recompiled
> 
> No recompilation is needed. The plug-in indeed has to test what kind of
> input/output systems (buffer, events, static) it should use.
> 
> If you want avoid the test, then write specialized plug-ins: only
> buffer inputs and outputs are allowed (such as in Csound). It is up
> to plug-in author. I just wanted to provide more than one choise.

As long as it *can* be hard coded, it's very good indeed. But what happens on
the engine side? For example, two channels * three data formats = 6 different
plug-in call code blocks on the engine side to avoid any conditionals. (Unless
the engine can just threat all buffers the same way.)

[...]
> >Well, my idea was to make the basic system even simpler,
> 
> Your system sounds more complicated than my system... yes it does. :-)

I wasn't thinking about the event system...! ;-)

I was thinking about the low level stuff used for telling the process() call
where the buffers are - which is basically reduced to getting a bunch of
pointers across. The plug-in is supposed to either keep track of what buffer
data formats the engine mentioned for each buffer, or it's simply hardcoded. In
the later case, it tells the engine "I want 32-bit mono data on all channels.
Period." in the init sequence, and then it just grabs the buffer pointers and
does it's thing.

[...]
> >I'm afraid that will result in two interfaces/subsystems that overlap too
> >much... And is your event system really that much simpler to implement?
> 
> How would you implement the curve delivery in your system? Both static
> predefined curve and the real-time curve coming from other part of the flow
> network?

Many ways to do that. I suppose you're talking about curves with variable point
rates...? (Well, that's supposed to be harder to do, so... ;-)

First the easy part: Real time curves.

If you want it hardcoded in the plug-ins (which would be the fastest way), just
define an event type EV_DATA_CURVE, which can take any number of points.
(Dynamic event size - knew it would come in handy! :-) The plug-in just sees
the event, grabs the address of the data area (where the points are), and gets
on with it's work.

A simpler and more generic solution would be to simply have an event
EV_DATA_CURVE_POINT, that takes a point and a slope, or a duration and the
*next* point level. (Just to avoid forcing the plug-in to look up the next
event in the buffer to know where it should be going for the next few
samples...)

A slightly harder trick: Static curves.

Well, they could simply be send using the solution just described, but of
course, we don't like data copying. :-)

So, I'd just invent EV_DATAP_CURVE, which works something like EV_DATA_CURVE,
only it doesn't have the data points in the buffer. Instead, it carries a
pointer to the first point we should use in the static curve buffer.
(Obviosuly, the engine is responsible for making sure that the static data is
actually within the address range of the execution context of the plug-in code!
To keep in mind when trying to send this kind of events over network, or
between processes. That's why I want to encode it with a _class_ of DATAP, so
that an event gateway could convert all events of this kind into DATA class
events without having to know what the events actually carries.)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Sep 24 11:20:43 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA28236
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 21:34:58 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA27877 for linux-audio-dev-list; Thu, 23 Sep 1999 20:24:57 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA27874 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 20:24:53 -0400
Received: from localhost.localdomain (dialup57-1-28.swipnet.se [130.244.57.28]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA10933; 
          Fri, 24 Sep 1999 02:20:24 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Date: Fri, 24 Sep 1999 00:46:21 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199909231637.MAA11268@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99092402263905.00442@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id CAA10933
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA28236
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1c9ab7922da407c5d3602d2df57455f6

On Thu, 23 Sep 1999, Paul Barton-Davis wrote:
[...]
> Using this terminology, what I was suggesting was that the ui-thread
> {c,w,sh}ould run on the same machine as the engine, but that because
> of X, this didn't prevent you from the display being on some other
> machine.

Yes, I realised that...

> BTW, I don't think we're ready to consider clusters yet. The latency,
> by which I mean the delay in sending a message onto a previously empty
> wire, is too great for audio synchronization.

...but clustering was just what I had in mind, which would mean that the
engine, as you defined it, would be distributed over multiple machines.

And I'm not suggesting that the whole cluster should be involved in _low
latency_ processing - 50 - 100 ms latency can be perfectly fine in many
situations, and is certainly a lot nicer than off-line processing from the end
user POV.

Also, I'm not thinking TPC/IP here. A (Beowulf class) cluster is a pretty
specialized form of network anyway, and I'd use drivers ported to RTLinux,
emulating the shared memory style IPC used on "real" supercomputers. That's a
very big difference, and the _hardware_ isn't really the problem here. People
are successfully using standard ethernet cards for real time streaming already.

> >requires the GUI code to actually work on the same system as the DSP code -
> >while you most probably don't want to load Qt, GTK+ or whatever on every node
> >of a Beowulf. And what if you decide to build a cluster of Alpha or PPC boxes?
> 
> GTK is ported to these platforms. But thats beside the point. The UI
> code *has* to run on the same host if you want low-latency interaction
> between the interface and the engine. If you don't care about that,
> then you have to devise a network IPC protocol to relay changes in the
> UI to the master. This seems silly.

Which would cause most network load and latency; GUI<->X communication, or
GUI<->engine communication?

But yes, running the GUI over normal TCP/IP or something like that is likely to
cause latency problems no matter where the split is done. OTOH, I've played
XGalaga and other stuff over 10 MBit ethernet (with a few Winhogs boxes on the
same net), and it actually ran with the same frame rate as when run on the
local X server... What about dedicated NICs and Mingo's patches on both boxes
for starters?

[...]
> If the variable can change more rapidly than that, then certainly
> there is a potential problem with:
> 
>         res->a = src->a + src->b
> 
> if the UI can twiddle with src->a and src->b directly. But the
> twiddling is still atomic, and besides, there is no computer-based UI
> that will allow you to alter two things simultaneously. So in reality,
> a or b alway change independently.
> 
> the only case i can imagine where this is not true is when a single
> on-screen control element actually affects two internal variables, but
> thats just bad design of the plugin, IMHO.

Well, I'm not really thinking about UI only here... What about automation? And
what about plug-ins that accept weird data like strings and curves? (Video
folks will like that...) It's still possible to code most "transactions" just
by accessing the data in safe order, but it quickly starts to gets messy.

> >And, what about timing? How do you handle sample accuracy without going to
> >single sample buffers? Events handle that in a clean and low cost way.
> 
> No they don't. You can't do sample accuracy without reducing the size
> of the engine control cycle (the number of samples it generates
> between checking for a new event in some way) to 1.

It's not really that simple... (Fortunately!) Sample accuracy doesn't mean that
every plug-in has to check for a change every single sample. It just means
that you *can* change *some* properties of *some* plug-ins at any singe sample
position. It can be handled something like this:

process(...**inputs, ...**outputs, ...**events, samples)
{
	int current_sample = 0;
	int current_event = 0;
	int count;
	while(current_sample < samples) {
		/* process until next event should take effect */
		count = event[current_event]->time - current_sample;
		current_sample = [current_event]->time;
		while(count--) {
			process one sample;
		}
		/* handle event... */
			.
			.
			.
	}
}

(This example code requires a terminator event timed at the end of the buffer to
work properly.)

The inner loop can be optimized, and doesn't have to support full sample
accuracy. (That is, SIMD code can be used if desired.)

I think that's a bit more efficient than running the whole engine with single
sample buffers...

> >kind of programming on the Amiga. Fun for a while, but then you start to
> >realize that a faster CPU is always more flexible. At least with an RTOS...)
> 
> and with Ingo on your side, you realize than a faster non-RTOS is always more
> flexible, too :)

Well, I don't know if you can call Linux + Ingo's patch a non-RTOS... It is
certainly a good soft RT OS, and in real life, it appears to be hard RT capable.
Not s precision, but that's not in the hard RT definition - bounded latency is
enough, and we seem to have just that.

Anyway, my RTOS point still remains - you'll break Mingo-Linux' great RT
performance if you use RT incapable resources or programming methods - just as
you ruin RTL's timing if you make it use non RT drivers.

The hard RT rules are unchanged (and my engine is still going to be hard RT
capable), but the user space environment is nicer to work in. :-)

[...]
> this makes no sense to me. lets say i want to change the delay time on
> a delay line. i tweak a virtual on-screen knob to do this. what does
> the ui-thread do to cause the delay time to change ? how does the
> engine know that it has happened, if indeed it has to (in Quasimodo,
> it has no idea - the value at a certain memory location just gets
> altered). this seems fundamental to me, and i simply don't understand
> from what you've written so far how the event system can do this - it
> seems based (both in terms of its name and the API) on a polling
> system. This is not going to work, or at least, it can't do the things
> I want Quasimodo to do. There is no polling in Quasimodo: the ui
> thread has direct access to the memory containing the variables used
> by the DSP thread. There is no communication between them, and the DSP
> code does not "poll"/look-at/check any memory locations to see if
> anything has been changed, ever.

Ok, to put it simple: I build a structured description of what I want the
plug-in to do, in the form of one or more events in a shared memory buffer. As
the engine does it's event routing for the whole processing net for each turn,
the events will get processed by the recieving during the next buffer period.

The only difference between "polling" once for each engine loop, and just
altering the values directly in the DSP code's variables is that you get the
same real time deadline for all plug-ins with the "polling" system. The
resolution (leaving out event time stamps) can be one buffer in both cases, but
the timing accuracy is independent of the latency with the event system.

> >Shouldn't be a problem. Also note that the events can be handled with
> >sample accuracy no matter what buffer size you use. If the MIDI
> >interface plug-in can extract exact timing info from the MIDI data,
> >that can be used to timestamp the events, so that plug-ins may use
> >the information if desired.
> 
> i don't know what you're thinking of here. MIDI interfaces don't do
> timestamping. the MTC messages are of way too coarse a resolution for
> timing purposes, though they could be used for certain kinds of sync.

No, MIDI does not do timestamping, but you can still measure the exact time of
arrival of each message. Under Windoze, that would have been a great
improvement, but with a real OS, you can just run the whole engine at a
sufficient buffer rate...

However, if you want to keep the buffer size up for performance reasons, you
could have the MIDI input driver (or a user space process at a higher rate)
time stamp and buffer the events, so that you get a *fixed* latency of say, 15
ms, instead of 15 ms jitter.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Sep 24 11:20:40 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA23091
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 21:00:38 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA27820 for linux-audio-dev-list; Thu, 23 Sep 1999 19:52:27 -0400
Received: from zapfhahn.bone.twc.de (zapfhahn.bone.twc.de [193.158.34.194]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA27817 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 19:52:23 -0400
Received: from space.twc.de (IDENT:stefan@space.twc.de [193.158.34.195])
	by zapfhahn.bone.twc.de (8.9.3/8.9.3) with ESMTP id BAA10941;
	Fri, 24 Sep 1999 01:46:28 +0200
Received: (from stefan@localhost)
	by space.twc.de (8.8.7/8.8.7) id BAA25261;
	Fri, 24 Sep 1999 01:46:31 +0200
Message-ID: <19990924014631.21047@space.twc.de>
Date: Fri, 24 Sep 1999 01:46:31 +0200
From: Stefan Westerfeld <stefan@space.twc.de>
To: David Olofson <audiality@swipnet.se>
Cc: Benno Senoner <sbenno@gardena.net>, Havoc Pennington <hp@redhat.com>,
        gnome-kde-list@gnome.org, linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: AudioServer Standard?
References: <99092314495603.00533@goblin.flashnet.it> <99092323404803.00442@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.85e
In-Reply-To: <99092323404803.00442@localhost.localdomain>; from David Olofson on Thu, Sep 23, 1999 at 11:20:36PM +0200
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2d6b21a240a45cf8d59558eea4bca394

   Hi!

On Thu, Sep 23, 1999 at 11:20:36PM +0200, David Olofson wrote:
> On Thu, 23 Sep 1999, Benno Senoner wrote:
> [...]
> > Later when audiality will be fully fuctional we could provide a compatibility
> > layer for esd or arts-enabled sound apps.
> > Right, David ?
> 
> The basic "compatibility layer" would be the /dev/dsp emulation, that Audiality
> will have as well. Perhaps aRts could run as a client to Audiality as a
> quick'n'dirty solution to get it all integrated? That way, applications
> expecting aRts would still work, and the whole system could still be integrated
> without having to port everything to one of the engines.

Not really. aRts requires really tight timing for tasks like full duplex
audio processing, hard disk recording, realtime midi synthesis (I don't
want to wait more that some ms when pressing a key on my midi keyboard),
etc.

For that reason, hooking aRts to another audio server engine (like for
instance esd as well), is probably impossible. You could build a "link-
me-in" /dev/dsp realtime virtualization server, which then loads both,
audioality and aRts as shared libs. On the other hand, you could probably
build audioality as one aRts plugin or aRts as one audioality plugin.

I think all those ideas sound strange and only show that it makes no sense
to build two projects with exactly the same goal, purpose and technology.
What is the sense of having two fully featured realtime multimedia
processing engines running? Normally, people tend to run one linux kernel
and one X server for instance.

> [...]
> > It shares many concepts with audiality, but I don't know anything about the
> > design.
> 
> Indeed, and I'll look more closely at the aRts code. Perhaps there is time and
> work to save by reusing parts of aRts in the new engine. (Which might be
> Audiality, or something else - my efforts so far have been in other areas than
> hacking actual engine code.) Depends on the coding style, and how well aRts
> fits with the new plug-in API currently in the design stage.
> 
> [...]
> > > + network transparency
> > > 
> > >   Since aRts uses CORBA for almost everything, it is network transparent.
> > >   On the other hand, some audio server functionality that has been
> > >   implemented in aRts use TCP to transfer the signal for instance from your
> > >   external (non-arts-module-like) mp3 player to aRts. This TCP stuff is
> > >   also network transparent.
> > 
> > tenwork transparency is ok, but we need to separate the things,
> > that means if source and destination are on the same machine,
> > use IPC/shmem to exchange data,
> > if not then use sockets or so.
> > But Corba seems a bit slow to me for a high performance event system.
> 
> I wouldn't worry much about the actual implementation. However, what does the
> APIs look like, WRT dependencies on other APIs and standards? I'd rather stick
> with very low level stuff, especially in the plug-in API. Partly for
> performance reasons, partly because it makes it easier to port to exotic
> environments like DSP farms, clusters and real time kernels, like RTLinux.
> 
> Also, I start to prefer C to C++, at least for this kind of stuff... Perhaps
> I've read too much Linux kernel code? ;-) (And, I was an asm die hard for a few
> years, when I hacked on the Amiga...)

The aRts plugins are plain C++ - CORBA would be much too slow for things like
that. It's just that things like session management, distribution, flow
graphs, etc. are handled over a CORBA interface. That way you can for
instance build flow graphs with a visual editor, while the synthesis
server isn't linked to Qt, X11 and similar.

> [...]

Of course I don't know what exactly you want to do in Audioality and how,
but from the discussion and from the webpage it seems to me like the
goals you have are very close to the goals of aRts. On the other hand, aRts
is under development about two years, and has many of the things you say
you want to achieve already. And more.

For instance it will integrate really nicely into the next version of
kooBase (which will be called Brahms), has really decent flow graph
management, audio server functionality (which is why this topic came up),
etc.

Of course, it isn't perfect, and there are quite a few things that could
be done a lot better. But it is a program you can install, play with,
change a few lines, recompile, and immediately see the effect. Of course,
if you want to have a new plugin API and a new signal flow scheduler,
you change a bit more. But still you can keep the whole framework, GUI
stuff, flow graph stuff, etc., which won't care about that kind of
things.

So why don't you just consider working on aRts? It's open source and your
ideas/code is always welcome. I think linux should try to solve problems
once, right, together and then build on what is there. Finally, that also
seems to have happened for Desktops, where we have now Gnome and KDE, and
most people just joined one of the projects, so we have two very nice
solutions here.

Thats what should happen for audio, too.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-

From - Fri Sep 24 11:20:47 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA00895
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 22:05:41 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA27931 for linux-audio-dev-list; Thu, 23 Sep 1999 21:02:14 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA27928 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 21:02:10 -0400
Received: from localhost.localdomain (dialup57-1-28.swipnet.se [130.244.57.28]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA24541; 
          Fri, 24 Sep 1999 02:57:49 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Stefan Westerfeld <stefan@space.twc.de>
Subject: Re: [linux-audio-dev] Re: AudioServer Standard?
Date: Fri, 24 Sep 1999 02:31:23 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: Benno Senoner <sbenno@gardena.net>, Havoc Pennington <hp@redhat.com>,
        gnome-kde-list@gnome.org, linux-audio-dev@ginette.musique.umontreal.ca
References: <19990924014631.21047@space.twc.de>
MIME-Version: 1.0
Message-Id: <99092403040506.00442@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id CAA24541
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id WAA00895
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: fe0081346d24f0241f707b6d01d2f467

On Fri, 24 Sep 1999, Stefan Westerfeld wrote:
[...]
> Not really. aRts requires really tight timing for tasks like full duplex
> audio processing, hard disk recording, realtime midi synthesis (I don't
> want to wait more that some ms when pressing a key on my midi keyboard),
> etc.

Unavoidable problem, of course...

> For that reason, hooking aRts to another audio server engine (like for
> instance esd as well), is probably impossible. You could build a "link-
> me-in" /dev/dsp realtime virtualization server, which then loads both,
> audioality and aRts as shared libs. On the other hand, you could probably
> build audioality as one aRts plugin or aRts as one audioality plugin.

Yes, that would be a lot more efficient. (That is, it could even be usable, as
opposed to streaming between the two tasks. :-)

> I think all those ideas sound strange and only show that it makes no sense
> to build two projects with exactly the same goal, purpose and technology.
> What is the sense of having two fully featured realtime multimedia
> processing engines running? Normally, people tend to run one linux kernel
> and one X server for instance.

Yes, I agree. The only point with those ideas was as a way to solve the
transfer period, if we were to use aRts until we manage to get Audiality to a
usable level. (If Audiality actually becomes usable before aRts has evolved
into an optimized client-server style engine, that is.)

Anyway, it's probably a good idea to coordinate development of our projects,
and other Open Source audio projects as well (trying to use the same plug-in
API for example), as that improves the chances of the long term result being The
Audio Subsystem. :-)

[...]
> > Also, I start to prefer C to C++, at least for this kind of stuff... Perhaps
> > I've read too much Linux kernel code? ;-) (And, I was an asm die hard for a few
> > years, when I hacked on the Amiga...)
> 
> The aRts plugins are plain C++ - CORBA would be much too slow for things like
> that. It's just that things like session management, distribution, flow
> graphs, etc. are handled over a CORBA interface. That way you can for
> instance build flow graphs with a visual editor, while the synthesis
> server isn't linked to Qt, X11 and similar.

Ok, I was thinking of the plug-in API and the extra overhead that C++ generates
if you're not careful. Although that overhead is usually insignificant, it
might become noticable when dealing with very small buffers, like less than 32
samples. (Used in feedback loops, and ultra low latency under RTLinux.)

> Of course I don't know what exactly you want to do in Audioality and how,
> but from the discussion and from the webpage it seems to me like the
> goals you have are very close to the goals of aRts. On the other hand, aRts
> is under development about two years, and has many of the things you say
> you want to achieve already. And more.

Yes, I think we're trying to do about the same thing. Unless there's some
very fundamental difference between our projects, there are basically two ways
to go, I think:

1) Keep developing Audiality, as a new engine built from scratch, learning from
the experience with aRts and other systems, and supporting the latest concepts
from the ground up.

2) Drop the Audiality engine development, and instead concentrate on the new
plug-in API, porting aRts to RTLinux to cover the sub 3 ms latency range, and
other similar efforts.

Question: What would result in the best solution in the long run?

> For instance it will integrate really nicely into the next version of
> kooBase (which will be called Brahms), has really decent flow graph
> management, audio server functionality (which is why this topic came up),
> etc.
> 
> Of course, it isn't perfect, and there are quite a few things that could
> be done a lot better. But it is a program you can install, play with,
> change a few lines, recompile, and immediately see the effect. Of course,
> if you want to have a new plugin API and a new signal flow scheduler,
> you change a bit more. But still you can keep the whole framework, GUI
> stuff, flow graph stuff, etc., which won't care about that kind of
> things.

That's kind of what I had in mind... Perhaps I could use aRts as a starting
point for the implementation of Audiality? It could save time for me, and might
also result in some useful new that can be ported back to aRts until Audiality
is mature enough to use.

> So why don't you just consider working on aRts? It's open source and your
> ideas/code is always welcome. I think linux should try to solve problems
> once, right, together and then build on what is there. Finally, that also
> seems to have happened for Desktops, where we have now Gnome and KDE, and
> most people just joined one of the projects, so we have two very nice
> solutions here.
> 
> Thats what should happen for audio, too.

Yes, I agree, and we certainly need to get rid of this chaos of different
plug-in APIs and incompatible engines. What I'll do depends on how different
aRts is from my Audiality plans... I want the plug-in and client APIs to be
flexible, efficient and powerful enough for most Linux audio developers to use,
or it won't be much point. I'm aiming for something more like an OS audio
infrastructure than a specialized music/audio engine.


Regards,


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Sep 24 11:20:55 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA08161
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 22:54:08 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA27994 for linux-audio-dev-list; Thu, 23 Sep 1999 21:34:12 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA27991 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 21:34:09 -0400
Received: from someip.ppp.op.net (d-bm2-01.ppp.op.net [209.152.194.33]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id VAA01441 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 21:29:56 -0400 (EDT)
Message-Id: <199909240129.VAA01441@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress? 
In-reply-to: Your message of "Fri, 24 Sep 1999 00:46:21 +0200."
             <99092402263905.00442@localhost.localdomain> 
Date: Thu, 23 Sep 1999 22:26:11 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 05420e9ee2f928ccc518fe9d3dcc4e85

>...but clustering was just what I had in mind, which would mean that the
>engine, as you defined it, would be distributed over multiple machines.
>
>And I'm not suggesting that the whole cluster should be involved in _low
>latency_ processing - 50 - 100 ms latency can be perfectly fine in many
>situations, and is certainly a lot nicer than off-line processing from the end
>user POV.
>
>Also, I'm not thinking TPC/IP here. A (Beowulf class) cluster is a pretty
>specialized form of network anyway, and I'd use drivers ported to RTLinux,
>emulating the shared memory style IPC used on "real" supercomputers. That's a
>very big difference, and the _hardware_ isn't really the problem here. People
>are successfully using standard ethernet cards for real time streaming already

Sorry, this is wrong. I spent several years running those "real"
supercomputers (Sequent, KSR's, nCube, etc), and its not true that
there isn't a hardware problem. Real time streaming is a completely
different problem - its fundamentally bandwidth related. For
event-driven (and by event, I refer not to your proposed event system,
but to MIDI and X and timers) stuff, the individual message latency is
a fundamental problem. When I worked in the CS dept at UofWashington,
there was a graduate student working on this exact problem. Its very
very hard with regular networking hardware to get the latency for a
single message low enough to provide a shared-memory like
environment. There have been some really cool tricks that have enabled
Beowulf to take off, but a 100ms delay in response to a MIDI NoteOn is
going to make you the laughing stock of AES :) Beowulf is a really
cool and fabulous system, but its success is entirely in areas where
the workload can be divided into reasonable large portions that don't
require very much intermediate synchronization. Even on the KSR, which
had a *much* faster inter-processor bus than ethernet, people doing
heavy numeric processing that did not have this characteristic
(i.e. there was a lot of read/write activity on the mythical "shared
memory" that actually translated into invalidations of the local
processor caches) found that their performance sucked. they had to
switch to a NUMA model to get things to really fly, which was hardly
the point of the KSR.

So, I don't think that clusters are viable for real-time audio
generation when you want sub-100ms event latency. They *are* fantastic
as rendering farms, the way that ILM uses them, for example. Its easy
to imagine some very impressive audio generation taking place on a
cluster, but without any input devices to "disturb" the computation.

>> GTK is ported to these platforms. But thats beside the point. The UI
>> code *has* to run on the same host if you want low-latency interaction
>> between the interface and the engine. If you don't care about that,
>> then you have to devise a network IPC protocol to relay changes in the
>> UI to the master. This seems silly.
>
>Which would cause most network load and latency; GUI<->X communication, or
>GUI<->engine communication?

Thats a good question. I actually don't know. It depends on the nature
of the X stuff. X sucks for some kinds of event streams, particular
those involving lots of bitmaps going over the server. But for mouse
and key events, its pretty damn efficient. If the server has its
pixmaps already loaded up so that knob twiddling didn't involve any of
the costly stuff, then I wouldn't be suprised if X communication cost
no more than a custom designed (*and* debugged!) GUI<->engine communication.

[ ... the synchronization problem ... ]

>Well, I'm not really thinking about UI only here... What about automation? And
>what about plug-ins that accept weird data like strings and curves? (Video
>folks will like that...) It's still possible to code most "transactions" just
>by accessing the data in safe order, but it quickly starts to gets messy.

strings are just pointers to data. you store the data, then flip the
pointer, which is just as atomic as an integer or float. likewise for
curves. 

>> >And, what about timing? How do you handle sample accuracy without going to
>> >single sample buffers? Events handle that in a clean and low cost way.
>> 
>> No they don't. You can't do sample accuracy without reducing the size
>> of the engine control cycle (the number of samples it generates
>> between checking for a new event in some way) to 1.

>It's not really that simple... (Fortunately!) Sample accuracy doesn't
>mean tha t every plug-in has to check for a change every single
>sample. It just means that you *can* change *some* properties of
>*some* plug-ins at any singe sample position. It can be handled
>something like this:

>process(...**inputs, ...**outputs, ...**events, samples)
>{
>	int current_sample = 0;
>	int current_event = 0;
>	int count;
>	while(current_sample < samples) {
>		/* process until next event should take effect */
>		count = event[current_event]->time - current_sample;
>		current_sample = [current_event]->time;
>		while(count--) {
>			process one sample;
>		}
>		/* handle event... */
>			.
>			.
>			.
>	}
>}

how can this work ? lets suppose that there are no events pending. you
just call process(..., 64) to generate the next 64 samples. someone
causes a MIDI CC message that is supposed to alter how the plugin
works. this is presumable queued in `events', but how is the plugin to
know to look for it ? it will be queued up after the terminator event
in the `events' "list" you pass in, so it can't see it during this pass.

so in this case, you've got a 64 sample event latency. to get this
down to 1, you've got to tell the plugin to only generate a single
sample. 

the way that quasimodo (+supercollider +csound) would handle this is
that the thread handling MIDI input would cause a callback to run. the
callback would fiddle with the parameters of the plugin (without
talking to the plugin, or queing anything up anywhere), and if the
plugin is running, it will simply use the new value.

perhaps i'm missing something here, but it seems to me that you're
proposing a polling system with an event latency equivalent to the
number of samples generated per control-cycle/call to process(). This
view seems to be reinforced by the following:

>Ok, to put it simple: I build a structured description of what I want the
>plug-in to do, in the form of one or more events in a shared memory buffer. As
>the engine does it's event routing for the whole processing net for each turn,
>the events will get processed by the recieving during the next buffer period.

right, exactly - "during the next buffer period". so your event
latency is bounded by the control cycle size/buffer period. 

>The only difference between "polling" once for each engine loop, and
>just altering the values directly in the DSP code's variables is that
>you get the same real time deadline for all plug-ins with the
>"polling" system. The resolution (leaving out event time stamps) can
>be one buffer in both cases, but the timing accuracy is independent
>of the latency with the event system.

directly altering the DSP code's variables doesn't change the
real-time deadline for all plugins. they are running without any
knowledge that their parameters are being played with. they just know
they are supposed to generate X samples and return. Quasimodo doesn't
want plugins to know the real time. they use DSP time, which is
constant during an entire control cycle. that is, the timestamp during
execution of the first plugin is *always guaranteed* to be the same as
that during the execution of the last plugin for any given cycle. it
is extremely rare that a plugin ever needs to know the "real" time.

--p


From - Fri Sep 24 11:20:52 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA07359
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 22:48:10 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA28006 for linux-audio-dev-list; Thu, 23 Sep 1999 21:41:17 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA28003 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 21:41:14 -0400
Received: from someip.ppp.op.net (d-bm2-01.ppp.op.net [209.152.194.33]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id VAA01968 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 21:37:02 -0400 (EDT)
Message-Id: <199909240137.VAA01968@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress? 
In-reply-to: Your message of "Thu, 23 Sep 1999 22:31:21 +0200."
             <99092323050002.00442@localhost.localdomain> 
Date: Thu, 23 Sep 1999 22:33:18 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 06ab2d16d77c74d14f5c6e6861ee0225

>(Personally, I don't even think GUI and processing code should be
>allowed to be in the same address space...)

David, we're clearly not on the same planet :)

>And I certainly DON'T want to listen to the cooling compressors and fans of a
>machine like that, so remote GUI is not only cool, but *required* for any
>serious high end applications. Preferably, the X terminal should have a flash
>disk (if any disk at all), and no fans. The Big Cool Box should be in the next
>room.

http://www.custom-consoles.com/

>in a big hard disk recording system, up to 50 ms latency for track insert

my pro studio friends tell me that they *rarely* (if ever) record more
than 16 tracks at once. keep this in mind. playback of, say 64 tracks,
is a breeze compared with recording them, and the verdict from the
users is: "we don't do that".

>drivers, but can anyone tell me how to build a 16-way Celeron 500...? ;-)

Wait 2 years. Buy a single processor :)

--p

From - Fri Sep 24 11:20:59 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA08954
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 22:58:48 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA28034 for linux-audio-dev-list; Thu, 23 Sep 1999 21:48:58 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA28031 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 21:48:55 -0400
Received: from someip.ppp.op.net (d-bm2-01.ppp.op.net [209.152.194.33]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id VAA02513 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 21:44:43 -0400 (EDT)
Message-Id: <199909240144.VAA02513@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] signal flow in Quasimodo 
In-reply-to: Your message of "Thu, 23 Sep 1999 18:47:30 +0300."
             <19990923154736Z46412-8255+2372@nic.funet.fi> 
Date: Thu, 23 Sep 1999 22:40:59 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3ad655e92eb9dcae4eb49bc46cd5d4ca

In message <19990923154736Z46412-8255+2372@nic.funet.fi>you write:
>>From:   Paul Barton-Davis <pbd@Op.Net>
>>
>>   is, if you have a signal generator named "xxx" and a delay line
>>   called "aaa", then on the first control cycle, only silence will
>>   emerge, because the signal generator will run *after* the delay
>>   line.
>
>Hmm.. the delay will anyway produce some silence in the first place.
>Do you mean extra silence? That is, if the delay is N and control period C,
>then the actual silence is N+C and not N as should be?

yes, i meant extra silence caused by the absence of any input from the
generator for the first control cycle's execution of the delay.

so, you get N, but shifted by C from the "true" start. 

at some point, i will fix this so that you can control the execution
order. i don't think this is hard: we just default to alphanumeric
sort unless a module is marked with an "run order" number, which you
can assign yourself. its hardly critical for most things.

--p

From - Fri Sep 24 11:20:58 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA08392
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 22:55:50 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA28046 for linux-audio-dev-list; Thu, 23 Sep 1999 21:50:52 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA28043 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 21:50:48 -0400
Received: from someip.ppp.op.net (d-bm2-01.ppp.op.net [209.152.194.33]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id VAA02631 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 21:46:36 -0400 (EDT)
Message-Id: <199909240146.VAA02631@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] campaigning at AES
In-reply-to: Your message of "Thu, 23 Sep 1999 18:47:30 +0300."
             <19990923154736Z46412-8255+2372@nic.funet.fi> 
Date: Thu, 23 Sep 1999 22:42:52 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 02ff1c727d06dbd5aa20aadcfc4b21eb

>Please, if possible, don't stand at the doors and stick a paper note to
>people's hand. Instead, go through every commercial software producer
>and start talking if they have plans to go for Linux, then give that
>paper note to them if they really want it. Let the crackpots only stand
>at the doors! Try avoid "I love Linux" T-shirt at that day...

i have no t-shirts with any letters on them anymore. and i will put
the document i will be handing out to commercial software *and*
hardware entities on the web (as .pdf's) before i head up. its
formatted with LaTeX+Palatino, looks nice, and runs about 20 pages
(including a typeset version of the Linux Audio+MIDI program list, and
screenshots of Ceres, SoundTracker, Snd, grip, Quasimodo, XWave and
DAP). Its called "Linux ? Why Should We Care ?: an information packet
for the audio industry". i plan to actively circulate among all the
significant companies, and maybe a few not-so-significant ones too. oh
yes, the logo on the front says "Linux: The Operating System for the
21st Century", and of course features Tux :)

--p

From - Fri Sep 24 11:21:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA16465
	for <slinkp@ulster.net>; Thu, 23 Sep 1999 23:58:03 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA28209 for linux-audio-dev-list; Thu, 23 Sep 1999 23:00:53 -0400
Received: from news.bris.corplink.com.au (news.bris.apacinternet.com.au [203.37.202.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA28206 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Sep 1999 23:00:47 -0400
Received: from crosswinds.net ([203.37.202.138])
	by news.bris.corplink.com.au (8.8.8/8.8.8) with ESMTP id MAA03898
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 24 Sep 1999 12:56:20 +1000
Message-ID: <37EAE7B9.3F01DA0B@crosswinds.net>
Date: Fri, 24 Sep 1999 12:53:45 +1000
From: Dan Horwood <reddan@crosswinds.net>
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] some basic questions
References: <199902011112.LAA18006@ns0.netcraft.co.uk> <36B590A3.E5612D3E@tin.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 2f8ee549b4153ac68e9dbc738a4b992d

Hi guys, I've been lurking on this list for quite a while, although most
of it goes over my head ;-)

I've never really got into linux, but I want to run jMax on my PC
(Celeron 333, 128MB RAM, Sound Blaster AWE 64...)
I was hoping someone could let me know which distribution I should
install so that I can run jMax (I've used Max extensively at uni, and am
excited about using it at home!). Also, is the java VM built into the
distribution, or do I have to download it separately - I've heard that
the IBM vm is really good.

Thanks for your help,
Dan Horwood.

From - Fri Sep 24 11:21:03 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id FAA04061
	for <slinkp@ulster.net>; Fri, 24 Sep 1999 05:18:35 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id EAA28805 for linux-audio-dev-list; Fri, 24 Sep 1999 04:27:30 -0400
Received: from dsmail.hmi.de (dsmail.hmi.de [134.30.15.24]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA28802 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 24 Sep 1999 04:27:11 -0400
Received: from daniel.hmi.de (daniel.hmi.de [134.30.15.2])
	by dsmail.hmi.de (8.9.1a/8.9.1) with ESMTP id KAA12792
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 24 Sep 1999 10:22:39 +0200 (MET DST)
Date: Fri, 24 Sep 1999 10:22:39 +0200 (MET DST)
From: Reiner Klenk <klenk@hmi.de>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] some basic questions
In-Reply-To: <37EAE7B9.3F01DA0B@crosswinds.net>
Message-ID: <Pine.OSF.4.05.9909241010070.13438-100000@daniel.hmi.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 72bf519af3080022d1ad97da9498e697


On Fri, 24 Sep 1999, Dan Horwood wrote:

> I was hoping someone could let me know which distribution I should
> install so that I can run jMax (I've used Max extensively at uni, and am
> excited about using it at home!). Also, is the java VM built into the
> distribution, or do I have to download it separately - I've heard that
> the IBM vm is really good.
I'm in the process of installing it on a RedHat6.0 system. I had to
download a lot of extra stuff such as the pgcc (pentium gcc) and the java
developers kit (jdk) from blackdown.org and the jfc (swing) from sun.com.
I don't think the distribution will make a big difference but if you stick
with the big players (RedHat, Suse, Debian) you will have less problems
finding software in the correct package format. 
I have everything compiled now, the java GUI seems to work, but audio
doesn't work as advertised. On the other hand, I've never used max before
so I'm still struggling with the concept as such. If you run into
installation problems send me a mail, may be I can help.
Regards,
Reiner

From - Fri Sep 24 11:21:17 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA02483
	for <slinkp@ulster.net>; Fri, 24 Sep 1999 10:40:24 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA29284 for linux-audio-dev-list; Fri, 24 Sep 1999 09:44:12 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA29281 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 24 Sep 1999 09:44:07 -0400
Received: from gardena.net ([194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id PAA31254;
	Fri, 24 Sep 1999 15:39:36 +0200
Received: from localhost (localhost [[UNIX: localhost]])
	by gardena.net (8.9.3/8.9.3) id PAA01785;
	Fri, 24 Sep 1999 15:29:40 +0200
From: Benno Senoner <sbenno@gardena.net>
To: David Olofson <audiality@swipnet.se>, Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: [l Re: Plug-in API progress?
Date: Fri, 24 Sep 1999 14:45:25 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <99092322073700.00442@localhost.localdomain>
MIME-Version: 1.0
Message-Id: <99092415293900.01521@goblin.flashnet.it>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2f36e3d2f86d743eaf878f16fde1cd36

On Thu, 23 Sep 1999, David Olofson wrote:
> On Thu, 23 Sep 1999, Benno Senoner wrote:
> [...]
> > 
> > Agreed, I like this idea,
> > for example the volume-slider (the GUI part) of a gain-control plugin just
> > installs an event-sending port and sends the events to the plugin DSP code.
> > Plus the DSP code installs an event-sending port and connect the event-receiver
> > port of the volume-slider.
> > That means if someone (a sequencer/ or arbitrary plugin) changes the gain value,
> > the fader would move automagically in the correct position.
> > Or is this suboptimal ?
> 
> Well, with the event system I'm working on is based on Recieve Ports only. That
> is, you don't write all your events with destination addresses to a single
> output buffer for dispatching by the engine, as in the design I might have
> mentioned earlier. (Perhaps I'll move back to that kind of design, but I'd
> really like some realistic processing net models with traffic statistics first.)
> 
> 
> There's one trick that *could* be done at virtually no cost though -
> sending the same buffer to multiple recipients. What I'm getting at is this: If
> the DSP <-> GUI communication is based on the two sending events directly to
> each other's event ports, the automation system could tap data from those
> communication paths by scanning the GUI -> DSP buffers for input, and sending
> it's output to both the GUI and the DSP code.

Yes this seems ok to me,
bt I want a generalized system where every other process can be the
"automation".
In short, I wat that my own process is able to get parameter-changes
notifications from the engine, and is allowed to send parameter-changes to any
plugin. (with immediate reflection on the GUI sliders, other
automation-recorders etc).


what about the following scenario:
sequencer1 continuously changes the cutoff frequency of a LP filter-plugin,
the GUI slider moves reflecting the changes.
sequencer2 records the automation parameters.
If the user moves the GUI sliders manually sequencer2 can record the data too.

> 
> Not a hardware problem, but what I have in mind isn't really networking - it's
> about building clusters using 100 MB or gigabit ethernet with RTLinux RT
> communication drivers. More like extending connecting the machines into
> something like a huge SMP box, than building a network...

Ok in a dedicated enviroment running at 100Mbit or 1Gbit , if there is no
additional random network traffic, IMHO using simple UDP/IP with SCHED_FIFO
processes you can reach a <20-30ms latency for your needs.


>> 
> <legal stuff>
> Speaking of Qt; I came up with an interesting licencing problem a while ago.
.....
> or perhaps didn't even know that something like that could be written. Does
> that mean that the end user - by loading a closed source plug-in from a
> developer without a Qt developer's license on the Qt host - is guilty of
> breaking the QPL?
> </legal stuff>

I think as long as the Qt-host is opensource , or the Qt-host creator owns a
license there should be no problem, but I'm not 100% sure about this.

regards,
Benno.

From - Fri Sep 24 11:21:19 1999
Received: from taz.ulster.net (root@taz.ulster.net [208.148.73.10])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id KAA03836
	for <slinkp@ulster.net>; Fri, 24 Sep 1999 10:48:31 -0400
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34]) by taz.ulster.net (8.8.5/8.7.3) with SMTP id KAA27419 for <slinkp@ulster.net>; Fri, 24 Sep 1999 10:28:43 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA29249 for linux-audio-dev-list; Fri, 24 Sep 1999 09:28:11 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA29246 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 24 Sep 1999 09:28:07 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46264AbPIXNXf>; Fri, 24 Sep 1999 16:23:35 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: gnome-kde-list@gnome.org, linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <19990924014631.21047@space.twc.de> (message from Stefan
	Westerfeld on Fri, 24 Sep 1999 01:46:31 +0200)
Subject: Re: [linux-audio-dev] Re: AudioServer Standard?
Message-Id: <19990924132338Z46264-608+70@nic.funet.fi>
Date:   Fri, 24 Sep 1999 16:23:35 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: aed9d362bc9fd63300ed300d70b41540

>From:   Stefan Westerfeld <stefan@space.twc.de>
>
>Not really. aRts requires really tight timing for tasks like full duplex
>audio processing, hard disk recording, realtime midi synthesis (I don't

Well, Arts is an audio engine (as well as have flow network builder) and
not just an application which has a quick hack of audio routines.

I have expected that at most we could cowork by making a common audio
engine (flow engine, disk service, audio card service, timings and
syncronizations, etc.). Then everything else around the core engine
would be different (CORBA, etc.).

Arts would use the core engine as library (as would Audiality use) but
the common applications would use the engine only via engine API.
Arts as an audio server in KDE would offer applications the similar
audio possibilities than Audiality.

I think there is no need to have only one engine around but we could
copy best parts of each's audio system for making a pretty good common
core engine.

For the above reason, I would like to see a detailed description about the
flow system of Arts and a list of features it lacks currently.

>For instance it will integrate really nicely into the next version of
>kooBase (which will be called Brahms), has really decent flow graph
>management, audio server functionality

Are you aware of Galan? Its network editor look pretty good but I have not
got into details. I remember Arts (previously Ksynth) had some very odd
looking network builder -- is the same GUI still in Arts?

>So why don't you just consider working on aRts? It's open source and your
>ideas/code is always welcome.

We should rewrite the core engine and not just submit code to the current
engine. We should write it in C not in C++.

Yours,

Juhana

From - Fri Sep 24 12:09:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA17257
	for <slinkp@ulster.net>; Fri, 24 Sep 1999 12:11:49 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA29421 for linux-audio-dev-list; Fri, 24 Sep 1999 10:59:19 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA29418 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 24 Sep 1999 10:59:11 -0400
Received: from gardena.net ([194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id QAA32240;
	Fri, 24 Sep 1999 16:54:34 +0200
Received: from localhost (localhost [[UNIX: localhost]])
	by gardena.net (8.9.3/8.9.3) id QAA01861;
	Fri, 24 Sep 1999 16:44:44 +0200
From: Benno Senoner <sbenno@gardena.net>
To: David Olofson <audiality@swipnet.se>,
        Stefan Westerfeld <stefan@space.twc.de>
Subject: Re: [linux-audio-dev] Re: AudioServer Standard?
Date: Fri, 24 Sep 1999 15:59:30 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <99092403040506.00442@localhost.localdomain>
MIME-Version: 1.0
Message-Id: <99092416444301.01521@goblin.flashnet.it>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 830883390d429e655c882a451b8075a7

On Fri, 24 Sep 1999, David Olofson wrote:
> On Fri, 24 Sep 1999, Stefan Westerfeld wrote:


>> > Of course I don't know what exactly you want to do in Audioality and how,
> > but from the discussion and from the webpage it seems to me like the
> > goals you have are very close to the goals of aRts. On the other hand, aRts
> > is under development about two years, and has many of the things you say
> > you want to achieve already. And more.
> 
> Yes, I think we're trying to do about the same thing. Unless there's some
> very fundamental difference between our projects, there are basically two ways
> to go, I think:
> 
> 1) Keep developing Audiality, as a new engine built from scratch, learning from
> the experience with aRts and other systems, and supporting the latest concepts
> from the ground up.
> 
> 2) Drop the Audiality engine development, and instead concentrate on the new
> plug-in API, porting aRts to RTLinux to cover the sub 3 ms latency range, and
> other similar efforts.
> 
> Question: What would result in the best solution in the long run?

If you ask me,
David seems to be one of the best  "Mr.optimizer"  (speed/efficiency/low-mem
footprint optimizations) around in the linux-audio arena,
maybe because he is doing control-processing at work,
and audio/DSP stuff is some sort of control processing.

I know almost nothing about arts, but audiality will certainly be optimized
as much as possible.
Of course audiality is still "vaporware" compared to arts.
I'm more for the 2nd solution:
in in the mean time you should use arts, and we could take the good ideas
from arts, and when arts reachs an usable state, provide the arts-compatibility
layer.


> 
> > For instance it will integrate really nicely into the next version of
> > kooBase (which will be called Brahms), has really decent flow graph
> > management, audio server functionality (which is why this topic came up),
> > etc.
> > 
> > Of course, it isn't perfect, and there are quite a few things that could
> > be done a lot better. But it is a program you can install, play with,
> > change a few lines, recompile, and immediately see the effect. Of course,
> > if you want to have a new plugin API and a new signal flow scheduler,
> > you change a bit more. But still you can keep the whole framework, GUI
> > stuff, flow graph stuff, etc., which won't care about that kind of
> > things.
> 
> That's kind of what I had in mind... Perhaps I could use aRts as a starting
> point for the implementation of Audiality? It could save time for me, and might
> also result in some useful new that can be ported back to aRts until Audiality
> is mature enough to use.

I agree.

> 
> > So why don't you just consider working on aRts? It's open source and your
> > ideas/code is always welcome. I think linux should try to solve problems
> > once, right, together and then build on what is there. Finally, that also
> > seems to have happened for Desktops, where we have now Gnome and KDE, and
> > most people just joined one of the projects, so we have two very nice
> > solutions here.
> > 
> > Thats what should happen for audio, too.
> 
> Yes, I agree, and we certainly need to get rid of this chaos of different
> plug-in APIs and incompatible engines. What I'll do depends on how different
> aRts is from my Audiality plans... I want the plug-in and client APIs to be
> flexible, efficient and powerful enough for most Linux audio developers to use,
> or it won't be much point. I'm aiming for something more like an OS audio
> infrastructure than a specialized music/audio engine.

That's the main point because I'm opting for audiality,
since the core is very simple, and of course very efficient (I agree about the C
over C++ speed advantage (see linux-kernel folks)  ,
but it is 100% extensible. That means no functionality limitations,
just hook up the additional functionality you need.

I hope that we do not run into ego-clashes or something.
(on one wants to drop his own engine).
Joining forces is IMHO very important for the succeeding of a decent audio API
on Linux.
But sometime building a system from scratch produces better results than
adapting existing ones.
See Cygnus' Ecos Embedded modular RTOS,
they developed an  embedded OS from scratch, instead of downsizing Linux.
And indeed Ecos is almost impossible to beat in terms of memory-footprint.
(Can run in a few KBs on a flashrom) 
Consider the fact that Audliality will be designed from principle with RTLinux
in mind (but you can run the engine as user process too).
That means timing performance better than most dedicated HW solutions.

I will play a little with arts to get a better vision of the engine.

regards,
Benno.

From - Sun Sep 26 23:33:23 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA21394
	for <slinkp@ulster.net>; Fri, 24 Sep 1999 12:39:52 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA29499 for linux-audio-dev-list; Fri, 24 Sep 1999 11:44:51 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA29496 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 24 Sep 1999 11:44:43 -0400
Received: from gardena.net ([194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id RAA00311;
	Fri, 24 Sep 1999 17:40:15 +0200
Received: from localhost (localhost [[UNIX: localhost]])
	by gardena.net (8.9.3/8.9.3) id RAA01941;
	Fri, 24 Sep 1999 17:30:49 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Date: Fri, 24 Sep 1999 17:12:47 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199909240129.VAA01441@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99092417304802.01521@goblin.flashnet.it>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1c03b13523ee668bc7774ec2fa47a983

On Fri, 24 Sep 1999, Paul Barton-Davis wrote:
[ ... network latency discussion ...]

 single message low enough to provide a shared-memory like
> environment. There have been some really cool tricks that have enabled
> Beowulf to take off, but a 100ms delay in response to a MIDI NoteOn is
> going to make you the laughing stock of AES :) 

100ms seems rather ridiculous to me ..
the ping (64bytes ICMP) round trip time between 2 machines is <1ms on
an idle 10mbit  LAN,
that means as long as you use the LAN for audio-only,
you can get <20-30ms latency easily,
or am I missing something ?

> 
> So, I don't think that clusters are viable for real-time audio
> generation when you want sub-100ms event latency. They *are* fantastic
> as rendering farms, the way that ILM uses them, for example. Its easy
> to imagine some very impressive audio generation taking place on a
> cluster, but without any input devices to "disturb" the computation.

What do are input devices ?
MIDI masterkeyboards , or mouse/keyboards which cause X traffic
slowing the audio event flow ?

[ ... sample accuracy ... ]

> how can this work ? lets suppose that there are no events pending. you
> just call process(..., 64) to generate the next 64 samples. someone
> causes a MIDI CC message that is supposed to alter how the plugin
> works. this is presumable queued in `events', but how is the plugin to
> know to look for it ? it will be queued up after the terminator event
> in the `events' "list" you pass in, so it can't see it during this pass.
> 
> so in this case, you've got a 64 sample event latency. to get this
> down to 1, you've got to tell the plugin to only generate a single
> sample. 

Yes the event latency will be 64 samples, there is no way around
checking for evens in 1 sample steps if you want sample accurate
latency, but scheduling jitter will completely ruin this accuracy.
Therefore it makes no sense to me to check for new events on every sample.

He is assuming that all events will be timestamped, and therefore the output
will be sample accurate for sequenced MIDI events , but the latency will be
constant.
Live MIDI input, will have an event delay of 64 samples, but I'm not sure how
precise the timestamps will be due to scheduling jitter,
but anyway below 1ms with Ingo's patches, that means better than the
MIDI wire resolution.

regards,
Benno.

From - Sun Sep 26 23:33:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA02218
	for <slinkp@ulster.net>; Fri, 24 Sep 1999 14:12:42 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA29650 for linux-audio-dev-list; Fri, 24 Sep 1999 13:22:42 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA29647 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 24 Sep 1999 13:22:37 -0400
Received: from gardena.net ([194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id TAA01543;
	Fri, 24 Sep 1999 19:18:10 +0200
Received: from localhost (localhost [[UNIX: localhost]])
	by gardena.net (8.9.3/8.9.3) id TAA02133;
	Fri, 24 Sep 1999 19:08:49 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Juhana Sadeharju <kouhia@nic.funet.fi>, audiality@swipnet.se
Subject: [linux-audio-dev] Re: Audio engine
Date: Fri, 24 Sep 1999 19:03:58 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <19990924164542Z46860-607+67@nic.funet.fi>
MIME-Version: 1.0
Message-Id: <99092419084904.01521@goblin.flashnet.it>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 8dae58402ca082bd0a594bb4d93e96f9

On Fri, 24 Sep 1999, Juhana Sadeharju wrote:
>> 
> Hmm.. I looked that greedy algorithm paper:
>   Efficient Editing of Digital Sound on Disk
>   Vol. 32, Number 6 pp. 394 (1984)
>   Author:   Curtis Abbott
>   Abstract:  Most professional applications of digital audio require a large
>   number of channels to be available, but do not require extensive editing
>   of the timing relationships among the channels. For these applications,
>   digital tape technology is an appropriate media
> 
> It is from 1984 but it is quite good. The author works at Lucasfilm, so,
> if the system is good for them, it is good for us. I will scan it in
> for you to read if you don't have a local technical library there.

Would be nice if you can put it online somewhere.

> They have another paper written by J.A. Moorer at about the same years.
> It gives an overview of the audio system used there and designed by Moorer.
> Moorer is founder of Sonic Solutions (Sonic Studio manuals are available
> through my Manuals page at GASP and gives a quite good view to the system)
> and is pretty well-known in audio research.
> 
> They talk about low level disk usage (can a Linux hard disk driver know
> about where the disk head rotates or is it buried in deep to the hard disk
> device?) and buffer fillings.

we can't make disk rotation assumptions etc, since we must deal with regular
files, but using smart buffering, we get nice performance,
60 tracks out of a 5200RPM disk is certainly not that bad.
I don't think that the algorithm proposed in the paper would bring many
benefits, since we aren't allowed to use the disk directly.
But I' certainly worth to take a look at the paper.

Using my simple sorting algorithm you get varispeed for free.

regards,
Benno.


From - Sun Sep 26 23:33:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA04572
	for <slinkp@ulster.net>; Fri, 24 Sep 1999 14:29:27 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA29695 for linux-audio-dev-list; Fri, 24 Sep 1999 13:48:55 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA29692 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 24 Sep 1999 13:48:52 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id NAA15637
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 24 Sep 1999 13:43:21 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id NAA14581; Fri, 24 Sep 1999 13:43:20 -0400 (EDT)
Date: Fri, 24 Sep 1999 13:43:08 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
In-Reply-To: <99092417304802.01521@goblin.flashnet.it>
Message-ID: <Pine.GSO.4.10.9909241324300.13475-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e97feb9b120ed2c45e3750be339c77d2

On Fri, 24 Sep 1999, Benno Senoner wrote:

> 100ms seems rather ridiculous to me .. the ping (64bytes ICMP) round
> trip time between 2 machines is <1ms on an idle 10mbit LAN, that means
> as long as you use the LAN for audio-only, you can get <20-30ms
> latency easily, or am I missing something ?

Here's a question... how does the latency compare amongst the core three
streaming IPC mechanisms on the _same_ machine: sockets, pipes, and shared
memory (with some sort of convention for using a ring buffer)?

I know shared memory is supposed to be instantaneous (although there've
been conflicting reports posted to the list recently), but it is not
inherently a streaming interface, so you need to manage the ring buffer
and locking yourself, which adds overhead.

Are local sockets and pipes any different?  What are the actual numbers?

Since my NetMIDI toys already support pipes and sockets, I'm wondering if
it would be beneficial to concentrate on one of them, or add shared mem
too.  I'd try to make my own measurements, but I don't trust my skills in
this area, since I'm not a realtime kind of guy.  

Thanks,
Div.

From - Sun Sep 26 23:33:31 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA15249
	for <slinkp@ulster.net>; Fri, 24 Sep 1999 15:43:32 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA29869 for linux-audio-dev-list; Fri, 24 Sep 1999 15:04:53 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA29866 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 24 Sep 1999 15:04:49 -0400
Received: from someip.ppp.op.net (d-bm2-0b.ppp.op.net [209.152.194.43]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id PAA01214 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 24 Sep 1999 15:00:32 -0400 (EDT)
Message-Id: <199909241900.PAA01214@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress? 
In-reply-to: Your message of "Fri, 24 Sep 1999 17:12:47 +0200."
             <99092417304802.01521@goblin.flashnet.it> 
Date: Fri, 24 Sep 1999 15:56:58 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2dce0e0ea48fa8f5cab91a81e7a7f247

[ network latency ]

>100ms seems rather ridiculous to me ..
>the ping (64bytes ICMP) round trip time between 2 machines is <1ms on
>an idle 10mbit  LAN,
>that means as long as you use the LAN for audio-only,
>you can get <20-30ms latency easily,
>or am I missing something ?

yes, you are. ping doesn't tell you how long from when it, the
application, decided to send its first packet until the reply
arrived. it tells you the time between the packet timestamps.  so,
sure, it the round-trip-time is <1ms, but how long did it actually
take from the decision to send until a reply was received ?

>> So, I don't think that clusters are viable for real-time audio
>> generation when you want sub-100ms event latency. They *are* fantastic
>> as rendering farms, the way that ILM uses them, for example. Its easy
>> to imagine some very impressive audio generation taking place on a
>> cluster, but without any input devices to "disturb" the computation.
>
>What do are input devices ?
>MIDI masterkeyboards , or mouse/keyboards which cause X traffic
>slowing the audio event flow ?

both. anything that causes some I/O that has to be handled by the X
server and/or a thread. it could be the RTC as well.

>[ ... sample accuracy ... ]
>
>> how can this work ? lets suppose that there are no events pending. you
>> just call process(..., 64) to generate the next 64 samples. someone
>> causes a MIDI CC message that is supposed to alter how the plugin
>> works. this is presumable queued in `events', but how is the plugin to
>> know to look for it ? it will be queued up after the terminator event
>> in the `events' "list" you pass in, so it can't see it during this pass.
>> 
>> so in this case, you've got a 64 sample event latency. to get this
>> down to 1, you've got to tell the plugin to only generate a single
>> sample. 
>
>Yes the event latency will be 64 samples, there is no way around

but there *is*. Quasimodo has no inherent input event latency at all!
of course, in real life, the delay between a byte arriving on a wire,
and the EventManager thread running the relevant callback is
non-zero. but Quasimodo's UI and EventHandler can directly tweak the
data the DSP works on without having to tell the DSP at all. NOTE: i
qualify this below.

>Therefore it makes no sense to me to check for new events on every sample.

I would go a step further. Event checking is wrong as a general
design.

When events *do* matter is not for parameter changes, but for things
that alter the program that the DSP simulation should be running. An
example is a MIDI NoteOn or its equivalent. 

In this case, paying attention to the event is not just a matter of
altering a memory value, but inserting a whole new series of
instructions into the DSP's current program. This has to have a
certain latency associated with it, and in Quasimodo (and to some
extent Csound and possibly SuperCollider as well), its determined by
the control cycle period. So, if the cycle is set to 64 samples, and a
MIDI NoteOn arrives just after a new cycle has started, then we have
to wait for the rest of the cycle till a new voice is audible/new
effect starts/whatever. *BUT* (and this is *very* important), if a
MIDI CC message or its equivalent arrives, it can be handled
*immediately* with no latency whatsoever (*)

This idea comes from a careful reading of papers on DSP design, and
thinking a lot about the benefits of running a DSP simulation in
software and how we could end up with the best of a fixed program DSP
a variable program DSP and a general purpose CPU. After all, *I* am
the one designed the "Quasimodo DSP", and I can make it do anything I
want :)

A key idea inside Quasimodo is the notion of run-time editing of the
DSP program(s) (aka the set of plugins currently running), and its
this that allows overhead-free patching between modules. For example,
in Quasimodo, when one plugin writes a certain value to its "output",
there is no "message" to connect it with another plugin that is
nominally connected to it - the same memory location is used by both
plugins, without them being aware that the engine did some run-time
editing to make it so. I am very happy with the way this idea has
turned out in practice - its very powerful, IMHO.

--p

(*) writing this reminds me that i need to make careful use of the
volatile keyword in writing opcodes. excessive use prevents gcc's
optimizer from doing its stuff, but inadequate use will cause there to
be a control cycle's worth of latency whether i designed it that way
or not.

From - Sun Sep 26 23:33:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA20213
	for <slinkp@ulster.net>; Fri, 24 Sep 1999 20:10:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA00360 for linux-audio-dev-list; Fri, 24 Sep 1999 19:22:40 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA00357 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 24 Sep 1999 19:21:54 -0400
Received: from localhost.localdomain (d212-151-42-251.swipnet.se [212.151.42.251]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA05833; 
          Sat, 25 Sep 1999 01:17:23 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Date: Fri, 24 Sep 1999 23:42:06 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199909240129.VAA01441@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99092501234200.00438@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id BAA05833
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA20213
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: bfcea36b8f6af2286a561d0106fe042e

On Fri, 24 Sep 1999, Paul Barton-Davis wrote:
> >...but clustering was just what I had in mind, which would mean that the
> >engine, as you defined it, would be distributed over multiple machines.
> >
> >And I'm not suggesting that the whole cluster should be involved in _low
> >latency_ processing - 50 - 100 ms latency can be perfectly fine in many
> >situations, and is certainly a lot nicer than off-line processing from the end
> >user POV.
> >
> >Also, I'm not thinking TPC/IP here. A (Beowulf class) cluster is a pretty
> >specialized form of network anyway, and I'd use drivers ported to RTLinux,
> >emulating the shared memory style IPC used on "real" supercomputers. That's a
> >very big difference, and the _hardware_ isn't really the problem here. People
> >are successfully using standard ethernet cards for real time streaming already
> 
> Sorry, this is wrong. I spent several years running those "real"
> supercomputers (Sequent, KSR's, nCube, etc), and its not true that
> there isn't a hardware problem. Real time streaming is a completely
> different problem - its fundamentally bandwidth related.

There's a problem with applications where threads will block waiting for data
to get through all, the time... That is, applications that do not map well to
parallel processing. But do audio engines really belong in that class?

> For
> event-driven (and by event, I refer not to your proposed event system,
> but to MIDI and X and timers) stuff, the individual message latency is
> a fundamental problem.

Of course, and I'm obviously being very incomprehensible if I seem to suggest
that's not the case...

> When I worked in the CS dept at UofWashington,
> there was a graduate student working on this exact problem. Its very
> very hard with regular networking hardware to get the latency for a
> single message low enough to provide a shared-memory like
> environment.

Yes, since applications designed for shared memory machines expect virtually
*no* latency. I'd say it's nothing but a design error building a new
application like that, if it's supposed to run on systems with "shared memory"
latency. (Unless it's dictated by the nature of the problem.)

> There have been some really cool tricks that have enabled
> Beowulf to take off, but a 100ms delay in response to a MIDI NoteOn is
> going to make you the laughing stock of AES :)

Yep, and I'm not suggesting to run soft synths hooked up to input devices on the
cluster. This is what the RT node with the audio cards is for. You don't play
*everything* at once using real time control, do you? (And if you do, you're
probably better of using the nodes as stand-alone synths with digital audio
interfaces for the communication.)

(BTW, I don't think I should have mentioned shared memory in this context -
emulating a shared memory environment isn't the right way to use ethernet like
hardware. Guess I wasn't awake enough to separate this discussion from that on
my event system...)

> Beowulf is a really
> cool and fabulous system, but its success is entirely in areas where
> the workload can be divided into reasonable large portions that don't
> require very much intermediate synchronization.

I'd say signal processing sub nets fit that description pretty well. (See above
digital audio interface suggestion, BTW - perhaps even ethernet hardware can
do that with RTL drivers...)

> Even on the KSR, which
> had a *much* faster inter-processor bus than ethernet, people doing
> heavy numeric processing that did not have this characteristic
> (i.e. there was a lot of read/write activity on the mythical "shared
> memory" that actually translated into invalidations of the local
> processor caches) found that their performance sucked. they had to
> switch to a NUMA model to get things to really fly, which was hardly
> the point of the KSR.

Of course. Who would expect otherwise?

> So, I don't think that clusters are viable for real-time audio
> generation when you want sub-100ms event latency. They *are* fantastic
> as rendering farms, the way that ILM uses them, for example. Its easy
> to imagine some very impressive audio generation taking place on a
> cluster, but without any input devices to "disturb" the computation.

Exactly, but who's defining anything worse than 100 ms as non-real time now? :-)

True, I'd sure like to do *everything* with sub 1 ms latency, but that's just
not going to happen. (Ok, perhaps on a quad Athlon 800 or some SMP Alpha
monster. But you always find something that needs more power sooner or later,
right? ;-)

Different solutions for different problems - and I can't see a valid reason not
to use multiple kinds of solutions together. I mean, you *do* use normal hard
drives for recording, even if the engine requires far lower latenices than those
can handle, don't you? That doesn't make sub 5 ms processing latency pointless;
nor does the 1-3 *seconds* range disk->engine latency make the 5 ms latency
processing impossible or useless.

[...]
> >Which would cause most network load and latency; GUI<->X communication, or
> >GUI<->engine communication?
> 
> Thats a good question. I actually don't know. It depends on the nature
> of the X stuff. X sucks for some kinds of event streams, particular
> those involving lots of bitmaps going over the server. But for mouse
> and key events, its pretty damn efficient. If the server has its
> pixmaps already loaded up so that knob twiddling didn't involve any of
> the costly stuff, then I wouldn't be suprised if X communication cost
> no more than a custom designed (*and* debugged!) GUI<->engine communication.

Yes, that's pretty likely. X is rather impressive sometimes. (Apart from being
ages ahead of certain M$ "inventions" long before those existed...)

[...]
> >process(...**inputs, ...**outputs, ...**events, samples)
> >{
> >	int current_sample = 0;
> >	int current_event = 0;
> >	int count;
> >	while(current_sample < samples) {
> >		/* process until next event should take effect */
> >		count = event[current_event]->time - current_sample;
> >		current_sample = [current_event]->time;
> >		while(count--) {
> >			process one sample;
> >		}
> >		/* handle event... */
> >			.
> >			.
> >			.
> >	}
> >}
> 
> how can this work ? lets suppose that there are no events pending. you
> just call process(..., 64) to generate the next 64 samples. someone
> causes a MIDI CC message that is supposed to alter how the plugin
> works. this is presumable queued in `events', but how is the plugin to
> know to look for it ? it will be queued up after the terminator event
> in the `events' "list" you pass in, so it can't see it during this pass.

You can't see *anything* that happens during the execution of the process()
function anyway, since in the normal case, it will execute in a fraction of the
time it takes to play the buffer. You could approximate the entire process()
call as an atomic operation with insignificant execution time, when viewing a
complete processing net. If there are 10 plug-ins, each one would only be open
for event changes during 10% of the total processing time (100% CPU load...),
which means it's quite pointless to care about any news while executing the
process() call. Plug-ins are not executing in parallel...

> so in this case, you've got a 64 sample event latency. to get this
> down to 1, you've got to tell the plugin to only generate a single
> sample. 

True. That's a law of nature. Time...

> the way that quasimodo (+supercollider +csound) would handle this is
> that the thread handling MIDI input would cause a callback to run. the
> callback would fiddle with the parameters of the plugin (without
> talking to the plugin, or queing anything up anywhere), and if the
> plugin is running, it will simply use the new value.

...and that happens only a fraction of the times you get an event. And unless
you're only running one plug-in, that takes nearly 100% of the CPU power, the
resulting effect on the output will not have much to do with the actual timing
of the input event.

> perhaps i'm missing something here, but it seems to me that you're
> proposing a polling system with an event latency equivalent to the
> number of samples generated per control-cycle/call to process(). This
> view seems to be reinforced by the following:
> 
> >Ok, to put it simple: I build a structured description of what I want the
> >plug-in to do, in the form of one or more events in a shared memory buffer. As
> >the engine does it's event routing for the whole processing net for each turn,
> >the events will get processed by the recieving during the next buffer period.

Yes.

> right, exactly - "during the next buffer period". so your event
> latency is bounded by the control cycle size/buffer period. 

Yes, but it does *not* quantisize events to that resolution. The latency is
fixed, with sample accuracy.

And, as you're really keen on cutting the latencies no matter what effect it
has on the jitter ;-) - my system does allow that events are sent to plug-ins
asynchronously while other plug-ins are executing. With 10% of the CPU in each
plug-in, that adds an average of 5% latency compared to your system, as my
system doesn't accept events when the recieving plug-in is in the process()
function. But that means you have to send the events with time == 0, unless you
want a jitter phenomenon caused by some events getting handled in the current
engine loop, and others in the next, but using the same position in the
buffer...

> >The only difference between "polling" once for each engine loop, and
> >just altering the values directly in the DSP code's variables is that
> >you get the same real time deadline for all plug-ins with the
> >"polling" system. The resolution (leaving out event time stamps) can
> >be one buffer in both cases, but the timing accuracy is independent
> >of the latency with the event system.
> 
> directly altering the DSP code's variables doesn't change the
> real-time deadline for all plugins. they are running without any
> knowledge that their parameters are being played with. they just know
> they are supposed to generate X samples and return. Quasimodo doesn't
> want plugins to know the real time. they use DSP time, which is
> constant during an entire control cycle. that is, the timestamp during
> execution of the first plugin is *always guaranteed* to be the same as
> that during the execution of the last plugin for any given cycle. it
> is extremely rare that a plugin ever needs to know the "real" time.

Hmm... To me, this sounds like you're actually talking about my system.
Certainly, your plug-ins don't know about real time in the normal case - but
how do you guarantee that the time stamp is the same for all plug-ins during
one cycle, if "events" are allowed t take effect in the middle of the cycle?
*That* makes real time look different depending on when in the cycle a plug-in
is executed... Or: If all plug-ins are working on buffers with the same start
time stamp, they must execute in parallel - or the plug-ins will get different
offsets between real time and DSP time.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Sep 26 23:33:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA10179
	for <slinkp@ulster.net>; Fri, 24 Sep 1999 18:48:42 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA00183 for linux-audio-dev-list; Fri, 24 Sep 1999 18:02:39 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA00179 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 24 Sep 1999 18:02:34 -0400
Received: from someip.ppp.op.net (d-bm3-01.ppp.op.net [209.152.194.65]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id RAA17659 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 24 Sep 1999 17:58:17 -0400 (EDT)
Message-Id: <199909242158.RAA17659@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress? 
In-reply-to: Your message of "Fri, 24 Sep 1999 13:43:08 EDT."
             <Pine.GSO.4.10.9909241324300.13475-100000@ux02.CS.Princeton.EDU> 
Date: Fri, 24 Sep 1999 18:54:45 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0ab122f3639ef51dc3706e1872fcc7d0

>Here's a question... how does the latency compare amongst the core three
>streaming IPC mechanisms on the _same_ machine: sockets, pipes, and shared
>memory (with some sort of convention for using a ring buffer)?
>
>I know shared memory is supposed to be instantaneous (although there've
>been conflicting reports posted to the list recently), but it is not
>inherently a streaming interface, so you need to manage the ring buffer
>and locking yourself, which adds overhead.
>
>Are local sockets and pipes any different?  What are the actual numbers?

i don't have actual numbers, but i do know the implementation model.

pipe latency is effectively the same as the time between the writer
calling write(2) and the reader being context-switched back in. this
is hard to predict, though if the reader is SCHED_FIFO, its
essentially on the order of <10usec. the actual data copying time is
almost completely ignorable.

a unix domain socket is effectively identical to a pipe, although
there is a small extra layer of fs code to go through; it doesn't add
more than 1usec to the usual pipe case.

shared memory should be instantaneous, but of course the context
switch time still plays a role, and in this case, the priority of the
reader makes no difference, since writing to shared memory doesn't
ever cause the kernel to believe that a reschedule is needed. so in
fact, shared memory could be slower than a pipe if used without an
accompanying system call that might cause a reschedule.

--p

From - Sun Sep 26 23:33:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA21186
	for <slinkp@ulster.net>; Fri, 24 Sep 1999 20:18:50 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA00379 for linux-audio-dev-list; Fri, 24 Sep 1999 19:34:52 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA00376 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 24 Sep 1999 19:34:48 -0400
Received: from localhost.localdomain (d212-151-42-251.swipnet.se [212.151.42.251]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA29741; 
          Sat, 25 Sep 1999 01:30:25 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Date: Sat, 25 Sep 1999 01:24:05 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199909240137.VAA01968@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99092501364301.00438@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id BAA29741
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA21186
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c8b656d5740bda05f09b4f1971821c18

On Fri, 24 Sep 1999, Paul Barton-Davis wrote:
> >(Personally, I don't even think GUI and processing code should be
> >allowed to be in the same address space...)
> 
> David, we're clearly not on the same planet :)

Are you kidding? :-)

> >And I certainly DON'T want to listen to the cooling compressors and fans of a
> >machine like that, so remote GUI is not only cool, but *required* for any
> >serious high end applications. Preferably, the X terminal should have a flash
> >disk (if any disk at all), and no fans. The Big Cool Box should be in the next
> >room.
> 
> http://www.custom-consoles.com/

Yes, of course... :-) I'm actually planning to build something like that, but
I'm a bit worried about cooling of fast SMP machines. Sound traps and a big,
low RPM fan inside the box should do, I think...

> >in a big hard disk recording system, up to 50 ms latency for track insert
> 
> my pro studio friends tell me that they *rarely* (if ever) record more
> than 16 tracks at once. keep this in mind. playback of, say 64 tracks,
> is a breeze compared with recording them, and the verdict from the
> users is: "we don't do that".

Now, I'm not following... Where did the "record vs. playback" discussion get
in? Anyway, personally, I rarely record more than 4 tracks at a time (partly
because I'm only one person!), but it's not hard to hit the 32 track limit on
my current Windoze system when mixing down a song.

Oh, "insert effects"... I was thinking about the mixdown phase - not the insert
fx used when recording the tracks. (Some call both "insert effects", but there
might be other terminologies in use...)

> >drivers, but can anyone tell me how to build a 16-way Celeron 500...? ;-)
> 
> Wait 2 years. Buy a single processor :)

Yes, but will the new DSP "inventions" we all want to play with at that time run
on that? ;-) (And, I wan't to have some fun sooner than that. :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Sep 26 23:33:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA24848
	for <slinkp@ulster.net>; Fri, 24 Sep 1999 20:49:13 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA00433 for linux-audio-dev-list; Fri, 24 Sep 1999 20:06:11 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA00427 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 24 Sep 1999 20:05:49 -0400
Received: from localhost.localdomain (d212-151-42-251.swipnet.se [212.151.42.251]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA22130; 
          Sat, 25 Sep 1999 01:59:51 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Benno Senoner <sbenno@gardena.net>, Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: [l Re: Plug-in API progress?
Date: Sat, 25 Sep 1999 01:42:12 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <99092415293900.01521@goblin.flashnet.it>
MIME-Version: 1.0
Message-Id: <99092502060902.00438@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id BAA22130
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA24848
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 320ece64ec0a88466b65685a839d9ada

On Fri, 24 Sep 1999, Benno Senoner wrote:
[...]
> > There's one trick that *could* be done at virtually no cost though -
> > sending the same buffer to multiple recipients. What I'm getting at is this: If
> > the DSP <-> GUI communication is based on the two sending events directly to
> > each other's event ports, the automation system could tap data from those
> > communication paths by scanning the GUI -> DSP buffers for input, and sending
> > it's output to both the GUI and the DSP code.
> 
> Yes this seems ok to me,
> bt I want a generalized system where every other process can be the
> "automation".

I was thinking along those lines as well. However, I think that calls for a per
event routing system in the engine - which would probably have a lot more
overhead than a "sender selects target per event" system.

Not sure though - there's certainly a lot to keep in mind here...

> In short, I wat that my own process is able to get parameter-changes
> notifications from the engine, and is allowed to send parameter-changes to any
> plugin. (with immediate reflection on the GUI sliders, other
> automation-recorders etc).

Yes, that's basic. That's what the client/server/plug-in architecture is all
about in this case, IMO.

> what about the following scenario:
> sequencer1 continuously changes the cutoff frequency of a LP filter-plugin,
> the GUI slider moves reflecting the changes.

Ok. Sequencer 1 somehow (directly or indirectly) sends events to both the
filter plug-in, and the GUI element (which is in fact a plug-in as well).

> sequencer2 records the automation parameters.

It could request to become another recipient of all events sent to the filter
plug-in. That is, another port to recieve a pointer to the same event buffer.

(Can you see the problem that's been on my mind for a while? What if seuencer2
would request event buffer mirroring from multiple sources? Yep, either the
engine gets to merge buffers - which is a lot more expensive than passing over
a pointer - or sequencer2 has to use one extra event port for each port it
wants to mirror. Not sure yet if this really matters, or if it would be less
expensive to pay somewhere else to solve this...)

> If the user moves the GUI sliders manually sequencer2 can record the data too.

Just another mirror... However, I'd like some nice way to keep track of what
belongs where. You get events from the GUI, and from the DSP code... Will this
be a frequently seen scenario that can be handled by the engine in an optimized
way? Seeme like it, but I might be wrong. Is the solution smart use of
mirroring and merging, where the engine handles setting it up, so that
plug-ins and clients won't have to worry much about it?

(I'll probably find a much better solution after having spent countless hours on
figuring out the details of this one! *hehe*)

> > Not a hardware problem, but what I have in mind isn't really networking - it's
> > about building clusters using 100 MB or gigabit ethernet with RTLinux RT
> > communication drivers. More like extending connecting the machines into
> > something like a huge SMP box, than building a network...
> 
> Ok in a dedicated enviroment running at 100Mbit or 1Gbit , if there is no
> additional random network traffic, IMHO using simple UDP/IP with SCHED_FIFO
> processes you can reach a <20-30ms latency for your needs.

Perhaps I should just set up the Dual box as well, and play some with my 100
Mbit network... It's just that I have way too much to do already.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Sep 26 23:33:43 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA20683
	for <slinkp@ulster.net>; Sat, 25 Sep 1999 01:14:57 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA00861 for linux-audio-dev-list; Sat, 25 Sep 1999 00:37:55 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA00858 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 25 Sep 1999 00:37:50 -0400
Received: from someip.ppp.op.net (d-bm3-1a.ppp.op.net [209.152.194.90]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id AAA08724 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 25 Sep 1999 00:33:30 -0400 (EDT)
Message-Id: <199909250433.AAA08724@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress? 
In-reply-to: Your message of "Fri, 24 Sep 1999 23:42:06 +0200."
             <99092501234200.00438@localhost.localdomain> 
Date: Sat, 25 Sep 1999 01:30:02 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 29e6c07a1e7da4270a9221879fc3a3bd

>There's a problem with applications where threads will block waiting for data
>to get through all, the time... That is, applications that do not map well to
>parallel processing. But do audio engines really belong in that class?

it depends. anything which may have to mixdown a series of output
buffers and/or constantly do mutex between plugins to make sure
they are not touching the output buffer at the same time *does* fit
into this category.

>Yep, and I'm not suggesting to run soft synths hooked up to input devices on the
>cluster. This is what the RT node with the audio cards is for. You don't play
>*everything* at once using real time control, do you? (And if you do, you're
>probably better of using the nodes as stand-alone synths with digital audio
>interfaces for the communication.)

agreed. this is exactly how i think "clusters" of any system along the
lines we are talking about should work i.e. routed through a digital
mixer (which may itself be just another node).

>> Even on the KSR, which
>> had a *much* faster inter-processor bus than ethernet, people doing
>> heavy numeric processing that did not have this characteristic
>> (i.e. there was a lot of read/write activity on the mythical "shared
>> memory" that actually translated into invalidations of the local
>> processor caches) found that their performance sucked. they had to
>> switch to a NUMA model to get things to really fly, which was hardly
>> the point of the KSR.
>
>Of course. Who would expect otherwise?

KSR :) Not to mention dozens of researchers, and quite a few venture
capitalists who got burned in the various ventures that tried to
implement this kind of system.

>Plug-ins are not executing in parallel...

so much for closely-knit clusters, eh ?

>> the way that quasimodo (+supercollider +csound) would handle this is
>> that the thread handling MIDI input would cause a callback to run. the
>> callback would fiddle with the parameters of the plugin (without
>> talking to the plugin, or queing anything up anywhere), and if the
>> plugin is running, it will simply use the new value.
>
>...and that happens only a fraction of the times you get an event. And unless
>you're only running one plug-in, that takes nearly 100% of the CPU power, the
>resulting effect on the output will not have much to do with the actual timing
>of the input event.

i accept this observation. its a good one that i hadn't paid to much
attention to. however, i didn't write things this way to improve the
input event latency (which i once believed was bounded by the control
cycle anyway), but to reduce the overhead of handling input events. i
will try to think a little more about which of our two schemes really
does this.

>> directly altering the DSP code's variables doesn't change the
>> real-time deadline for all plugins. they are running without any
>> knowledge that their parameters are being played with. they just know
>> they are supposed to generate X samples and return. Quasimodo doesn't
>> want plugins to know the real time. they use DSP time, which is
>> constant during an entire control cycle. that is, the timestamp during
>> execution of the first plugin is *always guaranteed* to be the same as
>> that during the execution of the last plugin for any given cycle. it
>> is extremely rare that a plugin ever needs to know the "real" time.
>
>Hmm... To me, this sounds like you're actually talking about my system.
>Certainly, your plug-ins don't know about real time in the normal case - but
>how do you guarantee that the time stamp is the same for all plug-ins during
>one cycle, if "events" are allowed t take effect in the middle of the cycle?

because there are no "events": parameter updates are handled in a
single step, by a thread that is not running the DSP simulation
(typically a ui-thread or an event-manager thread). so time stamps on
parameter changes simply don't exist. my system doesn't use timestamps
at all. there are no timestamped buffers, no timestamped events, no
timestamps for anything at all.

the notion of time is not based on "timestamps", but is synced to the
DAC. if a plugin is executing in any given cycle, then its query of
the current time will always return the same value. that doesn't mean
there have been no events - its means its busy generating the same
output buffer (and working on the same input buffer) as everybody
else who will be executed during that cycle. 

i originally foolishly thought i could get away from this scheme,
since it was something in Csound that i hated. after several weeks of
numerous different approaches, i decided that vercoe and friends knew
something after all :)

just to reiterate: Quasimodo makes a huge distinction between those
events that require a change in the program the DSP simulation is
running, and those that do not. The former get sent to the DSP, and
are processed at the beginning (or end, depending on how you look at
it) of every control cycle. All other events are handled
asynchronously without any communication with the DSP thread at all. 

and i know that you know this, but the system i'm describing is
implemented, fully functional, and about to go to release 0.1.7 this
weekend :) One might argue that it should be 0.2.0, but I promised
some people that 0.2.0 would contain a better language than Csound
orchestras for "plugin/module" programming, and that is not yet a part
of this release.

--p

From - Sun Sep 26 23:33:45 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA20762
	for <slinkp@ulster.net>; Sat, 25 Sep 1999 01:15:50 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA00869 for linux-audio-dev-list; Sat, 25 Sep 1999 00:41:52 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA00866 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 25 Sep 1999 00:41:49 -0400
Received: from someip.ppp.op.net (d-bm3-1a.ppp.op.net [209.152.194.90]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id AAA08890 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 25 Sep 1999 00:37:31 -0400 (EDT)
Message-Id: <199909250437.AAA08890@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress? 
In-reply-to: Your message of "Sat, 25 Sep 1999 01:24:05 +0200."
             <99092501364301.00438@localhost.localdomain> 
Date: Sat, 25 Sep 1999 01:34:03 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 90e1fbebc58f67dd61d88bc43f736ab8

In message <99092501364301.00438@localhost.localdomain>you write:
>On Fri, 24 Sep 1999, Paul Barton-Davis wrote:
>> >(Personally, I don't even think GUI and processing code should be
>> >allowed to be in the same address space...)
>> 
>> David, we're clearly not on the same planet :)
>
>Are you kidding? :-)

Well, only partly. putting them in different address spaces prohibits
the scheme for parameter updates that i've described, and i think that
doing so would be bad. 

>Yes, of course... :-) I'm actually planning to build something like that, but
>I'm a bit worried about cooling of fast SMP machines. Sound traps and a big,
>low RPM fan inside the box should do, I think...

the ISO-BOX fan completely refreshes the box every 20 seconds.

>> >in a big hard disk recording system, up to 50 ms latency for track insert
>> 
>> my pro studio friends tell me that they *rarely* (if ever) record more
>> than 16 tracks at once. keep this in mind. playback of, say 64 tracks,
>> is a breeze compared with recording them, and the verdict from the
>> users is: "we don't do that".

>Now, I'm not following... Where did the "record vs. playback"
>discussion get in? Anyway, personally, I rarely record more than 4
>tracks at a time (partly because I'm only one person!), but it's not
>hard to hit the 32 track limit on my current Windoze system when
>mixing down a song.

right, mixdown is not the same as recording. and to clarify, when i
quoted "we don't do that", i meant "we don't record 64 tracks at a
time". 

--p

From - Sun Sep 26 23:33:46 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA23645
	for <slinkp@ulster.net>; Sat, 25 Sep 1999 01:59:09 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id BAA00955 for linux-audio-dev-list; Sat, 25 Sep 1999 01:24:36 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA00952 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 25 Sep 1999 01:24:33 -0400
Received: from someip.ppp.op.net (d-bm3-1a.ppp.op.net [209.152.194.90]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id BAA10873 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 25 Sep 1999 01:20:15 -0400 (EDT)
Message-Id: <199909250520.BAA10873@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: [l Re: Plug-in API progress? 
In-reply-to: Your message of "Sat, 25 Sep 1999 01:42:12 +0200."
             <99092502060902.00438@localhost.localdomain> 
Date: Sat, 25 Sep 1999 02:16:48 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1ce22a6dae159a44cf7e9ce91c273fa5

>> what about the following scenario:
>> sequencer1 continuously changes the cutoff frequency of a LP filter-plugin,
>> the GUI slider moves reflecting the changes.
>
>Ok. Sequencer 1 somehow (directly or indirectly) sends events to both the
>filter plug-in, and the GUI element (which is in fact a plug-in as well).
>
>> sequencer2 records the automation parameters.
>
>It could request to become another recipient of all events sent to the filter
>plug-in. That is, another port to recieve a pointer to the same event buffer.
>
>(Can you see the problem that's been on my mind for a while? What if seuencer2
>would request event buffer mirroring from multiple sources? Yep, either the
>engine gets to merge buffers - which is a lot more expensive than passing over
>a pointer - or sequencer2 has to use one extra event port for each port it
>wants to mirror. Not sure yet if this really matters, or if it would be less
>expensive to pay somewhere else to solve this...)

let me just mention another problem. this one is *not* solved in
quasimodo yet either ... 

typically, parameter updates occur because of the GUI requesting
them. therefore, under most circumstances, the GUI does not want to be
notified of a parameter update event - it was the sender! however, if
the parameter update was caused by something else, the GUI *does* need
to be notified.

how to distinguish cheaply and easily between these two cases ?

in quasimodo, it happens when you are loading a preset, for
example. the GUI requests the preset, but it doesn't do the actual
processing (which may or may not be all in the same thread as the
GUI). first, we load the plugin(s), and then we set the parameters,
and then we then make the patches between them (i.e. run-time edit the
DSP programs for the plugins). when the parameters get set, the GUI
should reflect the new values. they don't. how to avoid a redundant
loop in the common case is not obvious to me right now.

--p

From - Sun Sep 26 23:33:48 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA20419
	for <slinkp@ulster.net>; Sat, 25 Sep 1999 10:37:17 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA02060 for linux-audio-dev-list; Sat, 25 Sep 1999 09:56:33 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA02056 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 25 Sep 1999 09:55:49 -0400
Received: from localhost.localdomain (d212-151-33-18.swipnet.se [212.151.33.18]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id PAA27568; 
          Sat, 25 Sep 1999 15:51:25 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Date: Sat, 25 Sep 1999 15:25:24 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199909250433.AAA08724@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99092515574400.00516@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id PAA27568
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id KAA20419
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 57e5357ed0a3249b0340fd20b78fdbbe

On Sat, 25 Sep 1999, Paul Barton-Davis wrote:
> >There's a problem with applications where threads will block waiting for data
> >to get through all, the time... That is, applications that do not map well to
> >parallel processing. But do audio engines really belong in that class?
> 
> it depends. anything which may have to mixdown a series of output
> buffers and/or constantly do mutex between plugins to make sure
> they are not touching the output buffer at the same time *does* fit
> into this category.

The output buffer and the plug-ins are to be on the same CPU in that case.
That's why it's so important to structure the processing net correctly. And, as
opposed to an OS running normal tasks, an audio engine running plug-ins has
quite a lot of control here.

> >> Even on the KSR, which
> >> had a *much* faster inter-processor bus than ethernet, people doing
> >> heavy numeric processing that did not have this characteristic
> >> (i.e. there was a lot of read/write activity on the mythical "shared
> >> memory" that actually translated into invalidations of the local
> >> processor caches) found that their performance sucked. they had to
> >> switch to a NUMA model to get things to really fly, which was hardly
> >> the point of the KSR.
> >
> >Of course. Who would expect otherwise?
> 
> KSR :)

Yes, obviously! :-)

> Not to mention dozens of researchers, and quite a few venture
> capitalists who got burned in the various ventures that tried to
> implement this kind of system.

Hmm... I thought it was pretty obvious that you'll get problems if your
applications depend on latencies that you can't cut down.

As a parallel; when you write applications for NT, you usually try to keep the
number of threads down, as NT's inefficient context switching is a known
problem. If you can't live with it, you'll do like quite a few have already
done: Switch to a real OS. :-)

> >Plug-ins are not executing in parallel...
> 
> so much for closely-knit clusters, eh ?

Well, that wasn't really the point here. A few plug-ins *will* of course be
executing in parallel in such a system, as in SMP systems, but that still
doesn't necessarilly mean you run only one plug-in per CPU, using close to 100%
of the CPU time...

> >> the way that quasimodo (+supercollider +csound) would handle this is
> >> that the thread handling MIDI input would cause a callback to run. the
> >> callback would fiddle with the parameters of the plugin (without
> >> talking to the plugin, or queing anything up anywhere), and if the
> >> plugin is running, it will simply use the new value.
> >
> >...and that happens only a fraction of the times you get an event. And unless
> >you're only running one plug-in, that takes nearly 100% of the CPU power, the
> >resulting effect on the output will not have much to do with the actual timing
> >of the input event.
> 
> i accept this observation. its a good one that i hadn't paid to much
> attention to. however, i didn't write things this way to improve the
> input event latency (which i once believed was bounded by the control
> cycle anyway), but to reduce the overhead of handling input events. i
> will try to think a little more about which of our two schemes really
> does this.

That depends on what you want to do, I guess. (And on the quality of the
implementation itself, of course. Crappy code can kill any design...)
Basically, my system should be more efficient if you really want high accuracy
without decreasing the buffer size. But if ultra low latency is the main goal,
my system will probably only result in a little more flexibility at a rather
high cost in the form of overhead.

However, I think that when used in situations where "normal" kind of latencies
are good enough, this flexibility will be very good for the usefullness of the
plug-in API. Frankly, what's most important; a few % of CPU, or the ability to
use a common plug-in for just about anything, and not forcing end users to
fiddle with multiple, incompatible systems? True, the extra transparency that
a buffered event system provides is mostly of interest to high end users, but
that's not the only point with it.

[...]
> >Hmm... To me, this sounds like you're actually talking about my system.
> >Certainly, your plug-ins don't know about real time in the normal case - but
> >how do you guarantee that the time stamp is the same for all plug-ins during
> >one cycle, if "events" are allowed t take effect in the middle of the cycle?
> 
> because there are no "events": parameter updates are handled in a
> single step, by a thread that is not running the DSP simulation
> (typically a ui-thread or an event-manager thread). so time stamps on
> parameter changes simply don't exist. my system doesn't use timestamps
> at all. there are no timestamped buffers, no timestamped events, no
> timestamps for anything at all.

Exactly.

> the notion of time is not based on "timestamps", but is synced to the
> DAC.

Yes, but not with sample resolution...

> if a plugin is executing in any given cycle, then its query of
> the current time will always return the same value. that doesn't mean
> there have been no events - its means its busy generating the same
> output buffer (and working on the same input buffer) as everybody
> else who will be executed during that cycle.

"will be" is very important here.

> i originally foolishly thought i could get away from this scheme,
> since it was something in Csound that i hated. after several weeks of
> numerous different approaches, i decided that vercoe and friends knew
> something after all :)

Well, they certainly knew how to design a simple and *efficient* system! :-)

> just to reiterate: Quasimodo makes a huge distinction between those
> events that require a change in the program the DSP simulation is
> running, and those that do not. The former get sent to the DSP, and
> are processed at the beginning (or end, depending on how you look at
> it) of every control cycle. All other events are handled
> asynchronously without any communication with the DSP thread at all. 

Yes, but that's a slightly different discussion. Of course, modifying the net
in real time is very useful, and my system will allow that as well. However,
that has nothing to do with my event system, other that that it might be done
by sending events to the engine itself. Rerouting the signal and event flows is
still a low level job done in the engine.

> and i know that you know this, but the system i'm describing is
> implemented, fully functional, and about to go to release 0.1.7 this
> weekend :)

Yes, but does that mean it's the perfect solution? ;-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Sep 26 23:33:53 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA24011
	for <slinkp@ulster.net>; Sat, 25 Sep 1999 11:11:12 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA02138 for linux-audio-dev-list; Sat, 25 Sep 1999 10:30:43 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA02135 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 25 Sep 1999 10:30:39 -0400
Received: from localhost.localdomain (d212-151-84-79.swipnet.se [212.151.84.79]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id QAA20507; 
          Sat, 25 Sep 1999 16:26:16 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Date: Sat, 25 Sep 1999 15:58:16 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199909250437.AAA08890@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99092516133601.00516@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id QAA20507
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id LAA24011
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: eb592c9ac9179b239f082f1a14cfcd0c

On Sat, 25 Sep 1999, Paul Barton-Davis wrote:
> In message <99092501364301.00438@localhost.localdomain>you write:
> >On Fri, 24 Sep 1999, Paul Barton-Davis wrote:
> >> >(Personally, I don't even think GUI and processing code should be
> >> >allowed to be in the same address space...)
> >> 
> >> David, we're clearly not on the same planet :)
> >
> >Are you kidding? :-)
> 
> Well, only partly. putting them in different address spaces prohibits
> the scheme for parameter updates that i've described, and i think that
> doing so would be bad. 

Yes, that's pretty obvious, of course. And I will partly contradict myself by
saying that it's still ok to use shared memory for the event buffers. The
important point is to keep a crashing GUI from taking the engine with it, which
is at least a little easier to do if they're running as different processes,
sharing as little as possible without wasting performance completely. (That is,
I'm not going to have an event syntax/structure checker or something in
between...)

> >Yes, of course... :-) I'm actually planning to build something like that, but
> >I'm a bit worried about cooling of fast SMP machines. Sound traps and a big,
> >low RPM fan inside the box should do, I think...
> 
> the ISO-BOX fan completely refreshes the box every 20 seconds.

Should do the trick, I guess. :-)

[...]
> right, mixdown is not the same as recording. and to clarify, when i
> quoted "we don't do that", i meant "we don't record 64 tracks at a
> time". 

Ok, but what about insert effects (as opposed to master effects) when mixing
down? I was suggesting that there's a point in supporting processing nets where
most signal flows start as hard disk tracks, pass through some insert effects,
and are then mixed in a lower latency net where the master effect plug-ins are
running, and inter-track dependencies are allowed. (If the later kind of tricks
is done acrosss tracks on different nodes in the cluster, the engine should
reorganized the net to fix that - high latency nodes should only sync with the
master low latency node as far as possible.)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Compose

From - Sun Sep 26 23:33:51 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA23658
	for <slinkp@ulster.net>; Sat, 25 Sep 1999 11:08:13 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA02143 for linux-audio-dev-list; Sat, 25 Sep 1999 10:30:53 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA02140 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 25 Sep 1999 10:30:50 -0400
Received: from localhost.localdomain (d212-151-84-79.swipnet.se [212.151.84.79]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id QAA20521; 
          Sat, 25 Sep 1999 16:26:18 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: [l Re: Plug-in API progress?
Date: Sat, 25 Sep 1999 16:16:58 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199909250520.BAA10873@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99092516304202.00516@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id QAA20521
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id LAA23658
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 736937a5966620005bb88b12cee108e6

On Sat, 25 Sep 1999, Paul Barton-Davis wrote:
[...]
> typically, parameter updates occur because of the GUI requesting
> them. therefore, under most circumstances, the GUI does not want to be
> notified of a parameter update event - it was the sender! however, if
> the parameter update was caused by something else, the GUI *does* need
> to be notified.
> 
> how to distinguish cheaply and easily between these two cases ?
> 
> in quasimodo, it happens when you are loading a preset, for
> example. the GUI requests the preset, but it doesn't do the actual
> processing (which may or may not be all in the same thread as the
> GUI). first, we load the plugin(s), and then we set the parameters,
> and then we then make the patches between them (i.e. run-time edit the
> DSP programs for the plugins). when the parameters get set, the GUI
> should reflect the new values. they don't. how to avoid a redundant
> loop in the common case is not obvious to me right now.

If it's all done through a central automation system, there doesn't need to be
any *extra* cost, but then the automation system and/or the GUI will probably
have to pay for that in the common case... OTOH, you get rid of all GUI related
overhead when the user closes the GUI of a plug-in. (Screen space is limited
anyway...)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Sep 26 23:33:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA19006
	for <slinkp@ulster.net>; Sat, 25 Sep 1999 15:48:42 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA02659 for linux-audio-dev-list; Sat, 25 Sep 1999 15:07:58 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA02656 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 25 Sep 1999 15:07:53 -0400
Received: from localhost.localdomain (d212-151-85-90.swipnet.se [212.151.85.90]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id VAA00624; 
          Sat, 25 Sep 1999 21:03:20 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Benno Senoner <sbenno@gardena.net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Re: Some Event stuff for now...
Date: Sat, 25 Sep 1999 19:46:40 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <99092300183403.00699@goblin.flashnet.it>
MIME-Version: 1.0
Message-Id: <99092521093903.00516@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id VAA00624
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id PAA19006
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: c95206212946d5623095a40d39caa3c6

[Seems like I forgot to reply to this...]

On Wed, 22 Sep 1999, Benno Senoner wrote:
[...]
> David,
> I'm still missing a clear picture of the event buffer.
> David, you say that you want to flush the buffer on each buffer period.
> Do you plan to use per-plugin event buffers ?

Yes, that was the idea. However, there's a distinction between the buffers of
event pointers that are sent to the plug-ins, and the buffers (or heaps) that
hold the events. The pointer buffers are allocated per plug-in, while memory
for events is allocated from a heap that's local to the processing sub net. (The
definition here is that a sub net has a uniform cycle time.)

There's one basic rule required for this to work: All events should have time
stamps within the cycle/buffer for which they are queued. That is, event
buffers are indeed very similar to audio buffers - only more structured in
their internal format. (You could actually view them as data buffers with
dynamic size, where the internal details are handled by the plug-ins.)

> Sorry if I dont understand this, but I often have to think in terms of pratical
> examples.

I don't blame you! :-) This is far from trivial, and I have yet to release a
detailed description of the whole system...

> Assume a simple sampler-plugin:  
> input: MIDI NoteOn / NoteOff events  (to specify triggering and pitch)
> output: sample-stream in float format
> 
> assume that there are 2 sequencers bombarding the poor sampler-plugin
> with Note-on events.
> Of course you want to allow timestamped events, therefore the plugin has to
> schedule to events in right order.

Yes. And for performance reasons, only one event buffer for the plug-in to keep
track of. (Multiple input channels would result in extra conditional code in
the main paths of both plug-in and engine code.)

> When do you know to free the buffers ?

The buffers for the whole sub net the sampler is in can be flushed after the
full buffer cycle.

> You said "flushing on the next buffer period", but what if the timestamped
> event has to be scheduled several periods later.

You don't do that. The event system itself is not a sequencer. (It could be,
but that would complicate things a lot.)

> Do you need an additional buffer to queue up timestamped events ?

Well, kind of, just as you need to queue audio buffers to handle the
connections between sub nets with different cycle rates. So, if the sequencer
really has to run in a different sub net that is out-of-phase, or running at a
different cycle rate, the event timing code will have to take care of that,
just as it will take care of translating time stamps into local buffer frame
counts.

> Ok, you can advance the heap pointer for non-timestamped data, but
> for timed events you have to take an other buffer flushing mechanis.

...or, when you allocate memory for the event, make sure to pick a heap that
will not have been flushed before the event is to be processed. (That doesn't
mean that it has to be the destination sub net's heap...)

> But since David does have a diabolic mind, he has already solved this issue.
> :-)

Well, it's solved for the sub nets, but my mind is not as diabolic after a
tough week at work, so I have yet to sort out some of the inter sub net mess.

> > The reason for using arrays of pointers rather than just events as raw data
> > written sequentially into the output buffer is on the engine side - merging of
> > events from multiple sources etc...
> 
> Ok, but these pointer have to point so some useful data, and you must 
> alloc/free the data at some point, and this must be implemented using fast
> routines.

Yes. This is what the local sub net heaps with inline code is for. It's more
like a way for the whole sub net to share temporary storage, than a real memory
management subsystem.

> Again in the case of timestamped events you have to pay attention when
> to free the structs.
> Or is this problem already solved ?

As I said, it's solved inside sub nets, but it gets more complicated when
crossing sub net boundaries.

The easy hack is to do it by copying the events into the target heap when
translating time stamps (which is another inter sub net comm. only job - not
needed within sub nets), but that's not very efficient, and shouldn't be
necessary. I think some kind of circular buffers between sub nets could do the
job.

Other schemes may simplify this part, but does anyone have a suggestion that
does that without slowing down the average case? (The average case being
sending events between plug-ins in the same sub net, I believe.)

> > /*
> >  * The engine encode time stamps as samples from
> >  * start of the timing master buffer, which can be
> >  * selected by the plug-in.
> >  * (Alternatively, this could be a float, but I
> >  * think that should be optional for performance
> >  * reasons.)
> 
> Yes, but what if the samplerate changes ?

Should sample rates be allowed to change in the middle of a buffer for normal
plug-ins? (And that's the *output* buffer sample rate.) That could be handled,
but I think it would be adding very much overhead to support a very unusal
situation. While other plug-in systems can't handle sample rate changes *at
all*, isn't it enough for us to allow it between the buffer cycles?

> > struct event_t;
> > 
> > struct event_port_t {
> > 	int	events;		/* Number of events currently in the buffer */
> > 	int	maxevents;	/* Size of the buffer */
> > 	event_t	**buffer;
> > };
> 
> 
> what is exactly an event_port ?
> A place where you can send events ?
> in the sample-player-plugin case:
> it the input-port of the plugin where you send the MIDI events ? 

Yep. In the normal case (ie when plug-ins within the same sub net
communicate) it's little more than way to keep track of the event pointer
buffers. When sending events to someone in outside a sub net, it can actually
belong to an interface layer in the engine rather than to the plug-in you're
sending to, but that doesn't make any difference to you as a sender.

> > (event_t is of course just the header - any number of bytes of data may follow.)
> > 
> > Any ideas about the from field? What I mean is, a simple way of making sure that
> > no one tries to reply to an event from a port that was just removed? (I think
> > it'll become clear when dealing with the life time of event buffers. When all
> > buffers with events from a certain port have been flushed, it's safe to delete
> > the port - unless some plug-in decides to remember a reply port address for
> > later use... That should probably not be allowed.)
> 
> What about to require the event-senders to notify the event-receivers 
> that they want to exit ?
> Maybe we could use double indirection:
> the **from is a pointer to a function pointer which gets the real from address.

That's about what I had in mind, although I'd just say
	event_port_t	**from;
No function call. That is, when you register an event port to use as your "reply
address", you get a pointer to an entry in a static table. The table is an
array of event_port_t *, and all unused entries are set to a dummy event port
that just flushes it's heap (== clearing a variable or two in a struct) every
now and then. (You can also route it to a plug-in that yells "Coward!!!" when
someone sends a request event and then disappears without waiting for the reply.
:-)

[...]
> therefore in the case that the event-receiver wants to query data about the 
> event-sender, there will be a function which will return PORT_NOT_PRESENT (=
> plugin exited or so),

Design goal: No function calls from plug-ins in the event system! :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Sep 26 23:34:01 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA18466
	for <slinkp@ulster.net>; Sat, 25 Sep 1999 21:43:10 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA03249 for linux-audio-dev-list; Sat, 25 Sep 1999 21:08:30 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA03246 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 25 Sep 1999 21:08:26 -0400
Received: from op.net (d-bm3-09.ppp.op.net [209.152.194.73]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id VAA26123; Sat, 25 Sep 1999 21:03:41 -0400 (EDT)
Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id WAA18530; Sat, 25 Sep 1999 22:00:25 -0400
Date: Sat, 25 Sep 1999 22:00:25 -0400
Message-Id: <199909260200.WAA18530@op.net>
From: Paul Barton-Davis <pbd@Op.Net>
To: linux-audio-dev@ginette.musique.umontreal.ca, alsa-devel@alsa-project.org
Subject: [linux-audio-dev] drivers for SEK'D cards wanted/hammerfall price :(
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: df3ddf0e226ccedf8cf79d35ec1661dd

just back from AES, where i had some interesting discussions with
various manufacturers. more on that some other time. but for right
now, i wanted to alert everyone here that SEK'D want driver writers
for their cards. unfortunately, i don't have a contact address, but
the head of the US branch will probably call me next week, so if you
want to make it simple, just email me. they were very keen to get linux
drivers (at least 2 people had approached them already and asked about
linux), and are quite willing to supply the documentation that was
used by the MacOS driver company. they may need to translate them,
however, if the programmer doesn't speak german :)

they also have the RME Hammerfall in stock, but the price is quite a
bit higher than we were hoping for: $839. they were rather suprised to
hear that Linux almost has a driver for the card.

this is only for SEK'D's own cards, not those they just carry from
RME. 

--p

From - Sun Sep 26 23:34:16 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA09398
	for <slinkp@ulster.net>; Sun, 26 Sep 1999 11:01:46 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA04141 for linux-audio-dev-list; Sun, 26 Sep 1999 10:22:26 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA04138 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 10:22:23 -0400
Received: from op.net (d-bm2-0a.ppp.op.net [209.152.194.42]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id KAA21157 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 10:17:58 -0400 (EDT)
Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id LAA20646; Sun, 26 Sep 1999 11:14:50 -0400
Date: Sun, 26 Sep 1999 11:14:50 -0400
Message-Id: <199909261514.LAA20646@op.net>
From: Paul Barton-Davis <pbd@Op.Net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] AES report
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: bed0668833bbcd28900a2ae4e255076e

Well, AES this year seems full of new dedicated HDR's. Mackie's was
the best one I saw, but many other companies were making them. 

It became clear to me wandering around the vast hall of gadgets,
blinking lights and men (for it was almost entirely populated with
men) who haven't quite outgrown their passion for toys with buttons
and dials that as fantastic as it is to be able to use a computer to
do all the audio stuff you could imagine, it seemed really worthwhile
being able to put your hands on a physical interface that included the
*right* physical elements to control a device.

I managed to talk to quite a few companies about Linux support. I
spent a while with the Creamware guys, which was actually pretty
pathetic in some senses, but there seems to be some possibility that
they might have me write a driver for the SCOPE/Pulsar. I told them
that if it could be open source, I would do it for free. They got
incredibly nervous when a guy from Be Inc. entered them room, and
ushered me out as fast as they could. The SCOPE system does look
incredibly cool, but I still worry about the SHARC's being redundant
in a couple of years, or less. As far as I could tell, the only things
you get from the SCOPE that you don't get from the Pulsar are (1) 15
SHARCs instead of 4 and (2) their GUI development environment for
creating new DSP control surfaces.

I talked to Steinberg for a little bit, gave them my 20 page "Linux ?
Why should we care?" information packet. Unfortunately, Wolfgang,
their lead programmer, was not at the booth, but they assured me he
would get the info. Nuendo looks very, very nice. They seem to have
abandoned the idea of an IRIX port, and are focusing on BeOS. I gave
them a brief argument why this might be a bad idea.

I also talked to two people from Cakewalk, gave them the packet. They
seemed genuinely stunned at what Linux could do, and totally awestruck
that it would run on a PC *and* a Mac, though I am not sure they
understood what that actually meant. I think they were thinking that
it was a program, not an operating system. Anyway, I encouraged them
to help fill the holes outlined by Dave Philips in some July mail to
the Csound-Unix development mailing list.

I talked to Lexicon about Linux support - they don't even imagine
themselves as a software-related company, so I had to explain how we
need drivers for some of their very nice soundcard/outboard ADAC
systems.

Dididesign didn't seem interested at all, but I think I got a bad
rep. I have a couple of inside contacts for them, so I'll mail them a
packet direct. Discussions with SEK'D I've already mentioned here.

Overall, there were less oppurtunities to evangelize than I had hoped
for, but I think I got some useful stuff done, and saw some extremely
cool looking racks of blinking LED's. It was also a beautiful day in
Manhattan yesterday, which helped. I have several info packets left
that I will send to various companies I didn't get to see.

--p

ps. best inquiry of the day, to me, repeated several times after
    people looked at my badge: "Oh, you work for Linux ?" :)
	

From - Sun Sep 26 23:34:23 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA17416
	for <slinkp@ulster.net>; Sun, 26 Sep 1999 12:24:24 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA04255 for linux-audio-dev-list; Sun, 26 Sep 1999 11:44:56 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA04252 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 11:44:52 -0400
Received: from localhost.localdomain (d212-151-88-163.swipnet.se [212.151.88.163]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id RAA07721; 
          Sun, 26 Sep 1999 17:40:21 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] AES report
Date: Sun, 26 Sep 1999 17:24:06 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199909261514.LAA20646@op.net>
MIME-Version: 1.0
Message-Id: <99092617464300.00438@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id RAA07721
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id MAA17416
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 37204e4a351eb7fbd7369f160147b047

On Sun, 26 Sep 1999, Paul Barton-Davis wrote:
> Well, AES this year seems full of new dedicated HDR's. Mackie's was
> the best one I saw, but many other companies were making them. 

No wonder, the way Windoze "works" for HDR...

> It became clear to me wandering around the vast hall of gadgets,
> blinking lights and men (for it was almost entirely populated with
> men) who haven't quite outgrown their passion for toys with buttons
> and dials that as fantastic as it is to be able to use a computer to
> do all the audio stuff you could imagine, it seemed really worthwhile
> being able to put your hands on a physical interface that included the
> *right* physical elements to control a device.

<opinion subject="User interfaces">
Probably the biggest problem with DAWs, now that we have a solid foundation to
build them on. Cakewalk is getting on my nerves with these
<ALT>/<CRTL>-<whatever> based shourtcuts... (Can be reconfigured, but that
doesn't help much.) I've had in mind building a custom controller to send
keyboard events, but as Cakewalk now has a new feature - the ability to focus
bogus controls in it's own screen - that wouldn't work. :-/

Buttons and dials vs. GUIs is like keyboard shortcuts vs. drop-down menues.
That is, unless frequently used functions map directly to the keys on the
standard keyboard (no qualifier crap), custom hardware is needed.
</opinion>

[...Cakewalk, Lexicon...]
Seems like there's really a need to get accross with information - not only on
the latest multimedia performance achievements, but actually on the fact that
Linux exists, what it is, and what it's all about...

> ps. best inquiry of the day, to me, repeated several times after
>     people looked at my badge: "Oh, you work for Linux ?" :)

Well, don't we all? :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Sep 26 23:34:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA15575
	for <slinkp@ulster.net>; Sun, 26 Sep 1999 12:06:28 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA04231 for linux-audio-dev-list; Sun, 26 Sep 1999 11:32:35 -0400
Received: from servidor.unam.mx (servidor.unam.mx [132.248.10.1]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA04228 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 11:32:32 -0400
Received: from servidor.unam.mx ([132.248.111.60])
	by servidor.unam.mx (8.8.8/8.8.8) with ESMTP id KAA03691
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 10:22:35 -0600 (CST)
Message-ID: <37EE3B81.97AB07E@servidor.unam.mx>
Date: Sun, 26 Sep 1999 10:28:04 -0500
From: Pablo Silva <hpsilva@servidor.unam.mx>
X-Mailer: Mozilla 4.5 (Macintosh; I; PPC)
X-Accept-Language: en,es-MX
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] [Fwd: AES, Linux and BeOS]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 23ac9cb0e81f4cb3dc6e118915a48fac

[originally to Paul Barton-Davies]

Pablo Silva wrote:
> 
> Hello Paul, from a lurker namesake in the Linux-dev list.
> 
> I was very interested in what you had to say about the happenings at
> AES. We can only hope that some of the companies you mentioned will get
> interested in Linux!
> 
> I do, however have a couple of questions to ask, as I know you are very
> much involved in the development side of things. I have been wondering
> how Linux and BeOS compare to each other in terms of capacities apart
> from the fact that of course BeOS remains a privately held OS. In the
> University here I plan to set up a small effort to write shareware for
> audio applications, but I'm concerned about choosing the right OS to
> work with. I must say Linux does seem like the right choice, but at the
> present moment BeOS seems much more mature, and of course the fact that
> it's a private company has helped to put it more into the minds of
> commercial developers than Linux.
> 
> So, what's your take on this?
> 
> Thanks
> 
> Pablo Silva

From - Sun Sep 26 23:34:24 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA23575
	for <slinkp@ulster.net>; Sun, 26 Sep 1999 13:30:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA04342 for linux-audio-dev-list; Sun, 26 Sep 1999 12:47:51 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA04339 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 12:47:42 -0400
Received: from localhost.localdomain (d212-151-88-163.swipnet.se [212.151.88.163]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id SAA12127; 
          Sun, 26 Sep 1999 18:43:10 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Date: Sun, 26 Sep 1999 17:53:04 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199909261527.LAA24066@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99092618493201.00438@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id SAA12127
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id NAA23575
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3e6396ef1ce5232fb2492a78f7d94ddb

On Sun, 26 Sep 1999, Paul Barton-Davis wrote:
> >> it depends. anything which may have to mixdown a series of output
> >> buffers and/or constantly do mutex between plugins to make sure
> >> they are not touching the output buffer at the same time *does* fit
> >> into this category.
> 
> >The output buffer and the plug-ins are to be on the same CPU in that
> >case.  That's why it's so important to structure the processing net
> >correctly. And, as opposed to an OS running normal tasks, an audio
> >engine running plug-ins has quite a lot of control here.
> 
> excellent point(s). on an SMP system, one can run a set of FX plugins,
> for example, on 1 processor and then run the mixer and the output
> plugin on a processor designated to control the hardware output.
> 
> however, you may recall that the original context for this
> parallelization discussion was non-SMP systems ("clusters"). In such a
> system, shared memory is not available, so the event system you
> propose turns into a message passing system, complete with network
> latencies to contend with. trying to split the processing net up like this
> means that the plugins that don't write directly to the output buffer have
> to communicate their contribution to its intended contents over the net.

Of course. But there's a big difference between treating a cluster as if it
was a shared memory/SMP system, and treating it as what is is - a network with
message passing latencies. One or two cross-node dependencies/"latency problems"
explicitly controlled by the net builder is a lot better than dozens inserted
"randomly" by the cluster's OS...

> once again, for batch processing, a beowulf cluster doing this would
> be fantastic. my own interest (and hey, Linux is all about scratching
> one's own back!)

Yep. :-) And it saves time and work when APIs and code can be reused.

> is in live performance, and so i'm not thrilled about this kind of thing.

Ok, I see... Well, I'm more the studio kind of guy. If I can get 10 times the
CPU power without having to buy a $$,$$$ SMP box, I don't mind if most of the
processing of recorded material is done with some 100 ms latency or so.

Anyway, I'm trying hard to keep the overhead down, so my system isn't going to
be too expensive for low latency real time work. After all, that's what I
intended to use Audiality/RTLinux for in the first place! If my event system
ends up as too inefficient, I'll just have to start over.

> >> Not to mention dozens of researchers, and quite a few venture
> >> capitalists who got burned in the various ventures that tried to
> >> implement this kind of system.
> >
> >Hmm... I thought it was pretty obvious that you'll get problems if your
> >applications depend on latencies that you can't cut down.
> 
> thats not the process that i think occured. instead, the claim/belief
> was that the latencies would be small, and well understood. for the
> KSR, as far as i recall (its been 5 years or more since i even saw one
> of them), the basic latencies *were* small, but not well understood,
> and it turned out to be too easy to cause pathological cases rather
> more easily than anyone thought.

Well, I guess all kernel hacker know how "well understood" the spin locks and
other internal constructs are in this respect... And that's just for SMP
systems! *heh...*

Fortunately, an audio engine where all "threads" (plug-ins) within a "task"
(sub net) are scheduled in a fixed order, one at a time, is quite a bit simpler
than an OS meant to run lots of threads that may chose to sync to anything
whenever they please.

> >That depends on what you want to do, I guess. (And on the quality of the
> >implementation itself, of course. Crappy code can kill any design...)
> >Basically, my system should be more efficient if you really want high accuracy
> >without decreasing the buffer size. But if ultra low latency is the main goal,
> >my system will probably only result in a little more flexibility at a rather
> >high cost in the form of overhead.
> >
> >However, I think that when used in situations where "normal" kind of latencies
> >are good enough, this flexibility will be very good for the usefullness of the
> >plug-in API. Frankly, what's most important; a few % of CPU, or the ability to
> >use a common plug-in for just about anything, and not forcing end users to
> >fiddle with multiple, incompatible systems? True, the extra transparency that
> >a buffered event system provides is mostly of interest to high end users, but
> >that's not the only point with it.
> 
> I have to think about all this stuff.

Meanwhile, I'll try and sort out the added complexity that my system adds.
Ahem... :-) (It doesn't look all that hopeless ATM.)

> >> the notion of time is not based on "timestamps", but is synced to the
> >> DAC.
> >
> >Yes, but not with sample resolution...
> 
> Now we have to be careful about terminology again. No, events in
> Quasimodo don't come with timestamps that identify the sample at which
> they occured. This is for a couple of reasons. First of all, as
> sampling rates go up, certain key input event sources (MIDI and
> keyboard and mouse and serial ports) retain the same overall
> characteristics. At 96KHz, you've got 10usec per frame. Lets posit a
> processor running at 800MHz with an average of 1.5 instructions per
> cycle. Thats 533 instructions per frame. If you're running on a UP,
> which many people will be, I think that the chances of you
> timestamping the event with sample accuracy are not good.

Depends on where your input events come from. Trigging a soft synth with the
audio input from mics will give you a source of sample accurate events.

> Its worse than that, though. When an event happens, you can only
> timestamp it with your notion of the current time, in whatever units
> that happens to be. But time must stand still during the calls to
> "process()" for each plugin currently in the net. So you can either
> stamp the event with the time at the beginning of the control cycle,
> or the time at the end, but you cannot know the offset into the
> cycle. 

Not true with a driver that time stamps input data when the interrupts occur. (I
did that back in the Amiga days...) And you shouldn't even need that with real
"high accuracy" hardware.

> Its also important to note that not having time which ticks by "per
> frame" doesn't mean that you don't have "sample resolution" within the
> plugins. By making parameter updates happen asynchronously, the plugin
> can just concentrate on measuring the number of frames/samples it has
> generated so far, and doing various things accordingly. It can switch
> behaviour exactly on the 102nd sample, for example, or the 1999923'rd
> sample, or whatever. 
> 
> So no, its true that Quasimodo's engine can't tell you the time with
> sample resolution, but plugins know the time with sample
> resolution. Strange, eh ?

And? What to do with your perfect notion of time, when no one tells you
exactly when to do things?

> More broadly, can you outline your objections to a scheme in which
> non-net-reorganizing events are handled asynchronously (i.e. not
> routed to the plugin's process() call) ?

Well, the event can be passed at any time in any way, but I still want a way
to let plug-ins know *exactly* when to do something. The buffer size is to
severe a restriction in many cases. (Probably more important in other
situations than playing soft synths live.)

> >> if a plugin is executing in any given cycle, then its query of
> >> the current time will always return the same value. that doesn't mean
> >> there have been no events - its means its busy generating the same
> >> output buffer (and working on the same input buffer) as everybody
> >> else who will be executed during that cycle.
> >
> >"will be" is very important here.
> 
> why ?

They're not executed in parallel == not at the same time. Unless the code that
"sends" events is blocked by the engine code, events may occur in the middle of
the cycle - which means that some plug-ins will execute before that event and
others after it. So, who which group does the event reciever belong to...?

(And if the engine *is* blocking the process sending events, you end up with
the exact same behaviour as my system - events can only be passed between the
cycles.)

> >> and i know that you know this, but the system i'm describing is
> >> implemented, fully functional, and about to go to release 0.1.7 this
> >> weekend :)
> >
> >Yes, but does that mean it's the perfect solution? ;-)
> 
> oh, very definitely not, and i wouldn't want to give even the
> appearance of such arrogance. i mention it only because it represents
> a real working "plugin" system very much like the one under discussion
> (in terms of design goals) that embodies close to a year of evolution
> and use (plus all the experience of Csound behind it). there is no
> reason to believe its the right one, not least because it started out
> with the important goal for me of maintaining source code
> compatibility with Csound opcodes. I still think this is an excellent
> idea.

Indeed it is, and I'm not suggesting that your solution would be simply the
wrong way to go. I'm sorry if I came accros as believeing I have all the
Ultimate Solutions. (I don't, Benno... ;-)

I do appreciate your insightful comments, and I have had to do a lot of
thinking at times to see if I'd really got things right. :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Sep 26 23:34:20 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA15646
	for <slinkp@ulster.net>; Sun, 26 Sep 1999 12:07:26 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA04225 for linux-audio-dev-list; Sun, 26 Sep 1999 11:31:31 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA04222 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 11:31:27 -0400
Received: from someip.ppp.op.net (d-bm2-0a.ppp.op.net [209.152.194.42]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id LAA24066 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 11:27:02 -0400 (EDT)
Message-Id: <199909261527.LAA24066@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress? 
In-reply-to: Your message of "Sat, 25 Sep 1999 15:25:24 +0200."
             <99092515574400.00516@localhost.localdomain> 
Date: Sun, 26 Sep 1999 12:23:55 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4745596a6dfb206b3790c8c7545161c6

>> it depends. anything which may have to mixdown a series of output
>> buffers and/or constantly do mutex between plugins to make sure
>> they are not touching the output buffer at the same time *does* fit
>> into this category.

>The output buffer and the plug-ins are to be on the same CPU in that
>case.  That's why it's so important to structure the processing net
>correctly. And, as opposed to an OS running normal tasks, an audio
>engine running plug-ins has quite a lot of control here.

excellent point(s). on an SMP system, one can run a set of FX plugins,
for example, on 1 processor and then run the mixer and the output
plugin on a processor designated to control the hardware output.

however, you may recall that the original context for this
parallelization discussion was non-SMP systems ("clusters"). In such a
system, shared memory is not available, so the event system you
propose turns into a message passing system, complete with network
latencies to contend with. trying to split the processing net up like
this means that the plugins that don't write directly to the output
buffer have to communicate their contribution to its intended contents
over the net.

once again, for batch processing, a beowulf cluster doing this would
be fantastic. my own interest (and hey, Linux is all about scratching
one's own back!) is in live performance, and so i'm not thrilled about
this kind of thing.

>> Not to mention dozens of researchers, and quite a few venture
>> capitalists who got burned in the various ventures that tried to
>> implement this kind of system.
>
>Hmm... I thought it was pretty obvious that you'll get problems if your
>applications depend on latencies that you can't cut down.

thats not the process that i think occured. instead, the claim/belief
was that the latencies would be small, and well understood. for the
KSR, as far as i recall (its been 5 years or more since i even saw one
of them), the basic latencies *were* small, but not well understood,
and it turned out to be too easy to cause pathological cases rather
more easily than anyone thought.

>That depends on what you want to do, I guess. (And on the quality of the
>implementation itself, of course. Crappy code can kill any design...)
>Basically, my system should be more efficient if you really want high accuracy
>without decreasing the buffer size. But if ultra low latency is the main goal,
>my system will probably only result in a little more flexibility at a rather
>high cost in the form of overhead.
>
>However, I think that when used in situations where "normal" kind of latencies
>are good enough, this flexibility will be very good for the usefullness of the
>plug-in API. Frankly, what's most important; a few % of CPU, or the ability to
>use a common plug-in for just about anything, and not forcing end users to
>fiddle with multiple, incompatible systems? True, the extra transparency that
>a buffered event system provides is mostly of interest to high end users, but
>that's not the only point with it.

I have to think about all this stuff.

>> the notion of time is not based on "timestamps", but is synced to the
>> DAC.
>
>Yes, but not with sample resolution...

Now we have to be careful about terminology again. No, events in
Quasimodo don't come with timestamps that identify the sample at which
they occured. This is for a couple of reasons. First of all, as
sampling rates go up, certain key input event sources (MIDI and
keyboard and mouse and serial ports) retain the same overall
characteristics. At 96KHz, you've got 10usec per frame. Lets posit a
processor running at 800MHz with an average of 1.5 instructions per
cycle. Thats 533 instructions per frame. If you're running on a UP,
which many people will be, I think that the chances of you
timestamping the event with sample accuracy are not good.

Its worse than that, though. When an event happens, you can only
timestamp it with your notion of the current time, in whatever units
that happens to be. But time must stand still during the calls to
"process()" for each plugin currently in the net. So you can either
stamp the event with the time at the beginning of the control cycle,
or the time at the end, but you cannot know the offset into the
cycle. 

Its also important to note that not having time which ticks by "per
frame" doesn't mean that you don't have "sample resolution" within the
plugins. By making parameter updates happen asynchronously, the plugin
can just concentrate on measuring the number of frames/samples it has
generated so far, and doing various things accordingly. It can switch
behaviour exactly on the 102nd sample, for example, or the 1999923'rd
sample, or whatever. 

So no, its true that Quasimodo's engine can't tell you the time with
sample resolution, but plugins know the time with sample
resolution. Strange, eh ?

More broadly, can you outline your objections to a scheme in which
non-net-reorganizing events are handled asynchronously (i.e. not
routed to the plugin's process() call) ?

>> if a plugin is executing in any given cycle, then its query of
>> the current time will always return the same value. that doesn't mean
>> there have been no events - its means its busy generating the same
>> output buffer (and working on the same input buffer) as everybody
>> else who will be executed during that cycle.
>
>"will be" is very important here.

why ?

>> and i know that you know this, but the system i'm describing is
>> implemented, fully functional, and about to go to release 0.1.7 this
>> weekend :)
>
>Yes, but does that mean it's the perfect solution? ;-)

oh, very definitely not, and i wouldn't want to give even the
appearance of such arrogance. i mention it only because it represents
a real working "plugin" system very much like the one under discussion
(in terms of design goals) that embodies close to a year of evolution
and use (plus all the experience of Csound behind it). there is no
reason to believe its the right one, not least because it started out
with the important goal for me of maintaining source code
compatibility with Csound opcodes. I still think this is an excellent
idea.

--p

From - Sun Sep 26 23:34:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA00991
	for <slinkp@ulster.net>; Sun, 26 Sep 1999 15:21:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA04542 for linux-audio-dev-list; Sun, 26 Sep 1999 14:39:41 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA04539 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 14:39:37 -0400
Received: from localhost.localdomain (d212-151-88-163.swipnet.se [212.151.88.163]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id UAA10655; 
          Sun, 26 Sep 1999 20:35:03 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Benno Senoner <sbenno@gardena.net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: Some Event stuff for now...
Date: Sun, 26 Sep 1999 18:56:41 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <99092521093903.00516@localhost.localdomain>
MIME-Version: 1.0
Message-Id: <99092620412402.00438@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id UAA10655
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id PAA00991
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: cb50ce397221fb917f61bbcb1f844bf8

Back again. It's coming together, I think...

On Sat, 25 Sep 1999, David Olofson wrote:
> > Do you need an additional buffer to queue up timestamped events ?
> 
> Well, kind of, just as you need to queue audio buffers to handle the
> connections between sub nets with different cycle rates. So, if the sequencer
> really has to run in a different sub net that is out-of-phase, or running at a
> different cycle rate, the event timing code will have to take care of that,
> just as it will take care of translating time stamps into local buffer frame
> counts.

...and I have two changes that will make that a lot nicer, while also making
some event related operations more efficient. :-)

1) Time stamps should be ripped out of the events.
2) Dynamic memory allocation is handled by small heap buffers,
   moved from a global heap buffer list to the local context
   heap as needed.

---------------------------------
struct event_descriptor_t;

struct event_port_t {
	qm_heap_t		*heap;		/* For dynamic allocation */
	int			events;		/* Number of events
						 * currently in the buffer
						 */
	int			maxevents;	/* Size of the buffer */
	event_descriptor_t	**buffer;
};

struct event_t {
	event_code_t		code;		/* What is this? */
	event_port_t		**from;		/* Who is this from? */
	int			size;		/* Number of data bytes */
};

struct event_descriptor_t {
	event_time_t		time;
	event_t			*event;
};
---------------------------------

qm_heap_t will look something like
---------------------------------
/*
 * Every context should have one of these for memory allocation.
 * All memory blocks that have been allocated from one heap will
 * be flushed when the context the heap belongs to reaches the
 * of a cycle. (That is, when all data is "old" WRT this context.)
 */
struct qm_heap_t {
	int		size;
	int		end;	/* Where to grab a new block */
	void		*buffer;
};

/*
 * Aaargh! A function call! ;-)
 * It's only used when the allocation macros
 * run out of local heap space.
 */
extern int qm_new_buffer(qm_heap_t *heap);
---------------------------------

Memory allocation works something like this:

inline void *qm_malloc(qm_heap_t *heap, int size)
{
	void *ret;
	if(heap->size - heap->end < size)
		if(!qm_new_buffer(heap))
			return 0;	/* A *REAL* OOM! --> */
	ret = heap->buffer + heap->end;
	heap->end += size;
	return ret;
};

(Note that qm_heap_t has some private stuff hidden from the API. That's what
qm_new_buffer() uses to keep track of things when handling the heap buffers.)

qm_new_buffer() will send the current buffer to the flush list of the context
the qm_heap belongs to, and will then ask the global memory manager for a new
buffer to throw in. When it's "flush time" for the context, all buffers are
returned to the global heap. (Should end up on top for free cache
optimization! :-)

 >  > > Ok, you can advance the heap pointer for non-timestamped data, but
> > for timed events you have to take an other buffer flushing mechanis.
> 
> ...or, when you allocate memory for the event, make sure to pick a heap thhat
> will not have been flushed before the event is to be processed. (That doesn't
> mean that it has to be the destination sub net's heap...)

This will be handled by simply requireing that all event ports you can send to
(and thus recieve events from) belong to a *context* that's compatible with the
sub net you're in. That is, they do not necessarilly have the same cycle time,
but sending events to them will be handled correctly, and data will not be
flushed prematurely.

> [...]
> > therefore in the case that the event-receiver wants to query data about the 
> > event-sender, there will be a function which will return PORT_NOT_PRESENT (=
> > plugin exited or so),
> 
> Design goal: No function calls from plug-ins in the event system! :-)

...and it seems that I can get very close without presenting 70% of the
engine's implementation details through the API. The qm_new_buffer() call is
only performed when your event doesn't fit in the heap's current buffer.

BTW, is there much point in optimizing for mixed allocation sizes? That is,
should the allocation macro check the old heap buffer first, in case it was
replaced just because someone just allocated a huge block of memory? That would
mean a few instructions and one conditional jump (== frequent pipeline
flushes) to get a little more efficient memory management when you send a mix
of large and small events...


About the inter-sub-net interfacing
-----------------------------------
Implementation detail:
Sub nets could be executed by a built-in plug-in. That would require plug-ins
to be able to have multiple event ports in order to avoid one event port having
to use some kind of gateway protocol. Which starts to sound like the plug-in
API should be more similar to the client API or something... Not sure if this
is a good idea (with plug-in performance in mind). But OTOH, event ports only
have a cost when set up and when actually used, so I may not matter much. Will
hack a sub net scheduler plug-in model to see what it looks like...

Anyway, passing events from one sub net to another means setting up an extra
event port belonging to "this" sub net, to shadow the real destination on the
other sub net. The context the shadow port belongs to will be one that's under
control of the code that does the actual event passing/translation. (In order
to make sure that buffers aren't flushed before the events have been recieved.)

Event translation can now be done without even referencing the events
themselves, as the time stamps are moved up to the event pointer table level.

As a bonus, you can send events containing static data (just add events using
your own static data instead of allocating dynamically), send the same event
multiple times, send the same event to multiple recipients, and other cool
things - with no copying overhead for the event data.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Sep 26 23:34:37 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA05608
	for <slinkp@ulster.net>; Sun, 26 Sep 1999 16:17:47 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA04660 for linux-audio-dev-list; Sun, 26 Sep 1999 15:40:17 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA04657 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 15:40:13 -0400
Received: from someip.ppp.op.net (d-bm3-0d.ppp.op.net [209.152.194.77]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id PAA05166 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 15:35:47 -0400 (EDT)
Message-Id: <199909261935.PAA05166@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress? 
In-reply-to: Your message of "Sun, 26 Sep 1999 17:53:04 +0200."
             <99092618493201.00438@localhost.localdomain> 
Date: Sun, 26 Sep 1999 16:31:25 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: dea39f53b5ac5ca3285b53a34f720792

>> cycle. Thats 533 instructions per frame. If you're running on a UP,
>> which many people will be, I think that the chances of you
>> timestamping the event with sample accuracy are not good.
>
>Depends on where your input events come from. Trigging a soft synth with the
>audio input from mics will give you a source of sample accurate events.

i don't get this. are you suggesting that you are reading from an ADC,
and then using the time implied by the sample count ? this will work
for some cards, and not for others (some don't use the same clock for
input as for output). It certainly won't provide sample accurate
timestamping if you use one card for input and one for output: clock
drift. OK, so if you use a Hammerfall and something else with word
clock syncing, its not a problem, but I didn't think that you wanted
to depend on this kind of hardware detail. I know that I don't. And
sure, you can play games to resync the cards every so often, but this
is not the making of a reliable system ...

>Not true with a driver that time stamps input data when the
>interrupts occur. (I did that back in the Amiga days...) And you
>shouldn't even need that with real "high accuracy" hardware.

not sample accurate though, just real-world accurate. If you're
running with +/- 0.5ms scheduling jitter (woo-hoo!), thats still a lot
of samples that may or may not have been generated so far by any given
plugin. The timestamp will be accurate, but there is no way to sync it
to the sample generation process. The best you can do is sync it to
the state of the DAC, as understood by the engine, which is well known
immediately after a write to the DAC has returned, but not known at
any other time.

in short, you can't get sample accurate timestamping unless you reduce
the control cycle to 1, which we're agreed is a bad idea.

>> So no, its true that Quasimodo's engine can't tell you the time with
>> sample resolution, but plugins know the time with sample
>> resolution. Strange, eh ?
>
>And? What to do with your perfect notion of time, when no one tells you
>exactly when to do things?

Ah, now we begin to get down to the meat (although I don't eat the
stuff :)

What *are* the events that might tell a plugin to "do something" ? 

The class of events that I imagine to have important time properties
are those that reconfigure the processing net. Turning on a
plugin. Turning it off. Not much else.

When someone tweaks a MIDI CC, I expect the effect to take place right
*now*. When someone twiddles an on-screen control element, I expect
the effect to take place right *now*. I don't see where a notion of
"when to do things" enters into the area of parameter updates.

I consider a plugin to be a little piece of code that generates
samples according to an algorithm and the state of its parameters. It
doesn't change what it does unless you (1) change the algorithm, which
is nonsensical - the plugin *is* the algorithm (+) or (2) change the
parameters. The parameters can be updated in real time. So I can't see
what kind of effects you might be talking about.

Perhaps we have a different notion of what a plugin is ? It doesn't
seem that way, however.

(+) NOTE: this doesn't mean that the plugin can't contain conditional
code. But this is just handled with a parameter update. Consider a
plugin with a switch that toggles between two different choices. Right
now, the parameter that models the switch state is set to 1. Someone
clicks the GUI representation, and we decide to change it to a 2. No
problem: no timestamping needed - we just alter the parameter
asynchronously, and the plugin keeps running.

	process (MyClosureType *closure) 
        {

             while (samples_to_generate) {
		
		if (*closure->switch_state == 1) {
		    ... foo ...
 		} else {
                    ... bar ...
                }			       
            }

        }

There - we just told the plugin to do something, and it did it. No
events, no timestamps. What am I missing ?

>> >> if a plugin is executing in any given cycle, then its query of
>> >> the current time will always return the same value. that doesn't mean
>> >> there have been no events - its means its busy generating the same
>> >> output buffer (and working on the same input buffer) as everybody
>> >> else who will be executed during that cycle.
>> >
>> >"will be" is very important here.
>> 
>> why ?

>They're not executed in parallel == not at the same time. Unless the
>code that "sends" events is blocked by the engine code, events may
>occur in the middle of the cycle - which means that some plug-ins
>will execute before that event and others after it. So, who which
>group does the event reciever belong to...?

Once again, what kind of events are we talking about here ? Things
that reconfigure the net don't get handled until the end of the
control cycle. But there aren't very many events that do that ... Most
of them are just parameter updates. These don't change what the plugin
"does" in the sense that it needs to be told about it. They may well
change the output of the plugin, but it doesn't have to care about
that :)

>I do appreciate your insightful comments, and I have had to do a lot of
>thinking at times to see if I'd really got things right. :-)

Likewise. I am enjoying the challenge of figuring out if Quasimodo's
system really does make as much sense as I think it does, or if I
missed something large, or if I missed something small. Its all good
stuff.

--p

From - Sun Sep 26 23:34:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA06434
	for <slinkp@ulster.net>; Sun, 26 Sep 1999 16:26:56 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA04686 for linux-audio-dev-list; Sun, 26 Sep 1999 15:50:47 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA04683 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 15:50:41 -0400
Received: from someip.ppp.op.net (d-bm3-0d.ppp.op.net [209.152.194.77]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id PAA05606; Sun, 26 Sep 1999 15:45:49 -0400 (EDT)
Message-Id: <199909261945.PAA05606@renoir.op.net>
To: Pablo Silva <hpsilva@servidor.unam.mx>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: AES, Linux and BeOS 
In-reply-to: Your message of "Sun, 26 Sep 1999 10:26:47 CDT."
             <37EE3B34.3C005916@servidor.unam.mx> 
Date: Sun, 26 Sep 1999 16:41:27 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: b5d9341e707cc5c9602d7c6b5a61e92f

>I do, however have a couple of questions to ask, as I know you are very
>much involved in the development side of things. I have been wondering
>how Linux and BeOS compare to each other in terms of capacities apart
>from the fact that of course BeOS remains a privately held OS. In the
>University here I plan to set up a small effort to write shareware for
>audio applications, but I'm concerned about choosing the right OS to
>work with. I must say Linux does seem like the right choice, but at the
>present moment BeOS seems much more mature, and of course the fact that
>it's a private company has helped to put it more into the minds of
>commercial developers than Linux.

I don't think that BeOS is more mature. I think it is more focused. It
also has the benefit of being an identifiable corporation, which as
you say, tends to focus the minds of those who write software to make
a profit.

I don't know of any particular benefits that BeOS would have over
Linux 2.2.10-N6. Linux has better support for leading-edge audio
applications that integrate networking and database engines. It has
more users. Its been debugged more. I think it supports SMP better. It
supports more hardware. You can read the source to learn how things
are done and not done.

BeOS doesn't come with the same range of choices, which can often be a
good thing. No trying to decide between OSS or ALSA. No trying to
decide between GNOME or KDE. You use the MediaKit and/or the MidiKit,
and thats that. Sometimes no choice is the best choice of all.

BeOS asked me a while back to port Quasimodo. A month ago, I was
planning to do this. Now I am not. Thats my take on the two of them.

--p

From - Sun Sep 26 23:34:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA07770
	for <slinkp@ulster.net>; Sun, 26 Sep 1999 16:42:09 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA04726 for linux-audio-dev-list; Sun, 26 Sep 1999 16:03:49 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA04722 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 16:03:45 -0400
Received: from someip.ppp.op.net (d-bm3-0d.ppp.op.net [209.152.194.77]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id PAA06216 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 15:59:19 -0400 (EDT)
Message-Id: <199909261959.PAA06216@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] [Fwd: AES, Linux and BeOS] 
In-reply-to: Your message of "Sun, 26 Sep 1999 20:44:27 EST."
             <199909261847.UAA27467@bashir.belgium.eu.net> 
Date: Sun, 26 Sep 1999 16:54:58 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 96ba63a54761b15ee7f0aa952b5422bf

 [ .. excellent comments on BeOS and Linux elided ... ]

>We should all agree that BeOS and Linux are to be seen as the 
>competition against MacOS and Windows rather than competing themselves.

I wish I could agree with you. But I don't think that companies see it
that way. I was very upset about Creamware ushering me out of the room
when a guy from Be came in. For companies with limited resources, they
have to choose between potential areas to put their efforts
towards. BeOS and Linux are not so similar as to make porting trivial,
and so these companies *do* have to choose ...

>I don't like Paul saying, wrt Steinberg :
>
>"They seem to have
>abandoned the idea of an IRIX port, and are focusing on BeOS. I gave
>them a brief argument why this might be a bad idea."
>
>It is quite useless to tell Steinberg that this is a bad idea, since 
>
>a) it is a good idea ;-)

I said that *focusing* on BeOS was a bad idea, not Nuendo on BeOS was
a bad idea.

Alan Cox observed that BeOS is a really great OS for the current idea
of what a multimedia application should be. But the current idea has
been formed on systems like Windows and the MacOS which have not been
capable of the kinds of things that can be done on Linux. Integrating
large databases and networking into multimedia is going to be very hot
thing to do in the next 5 years or less. I don't see any evidence
that BeOS is going to be able to compete with Linux in these areas,
since we already have Oracle running, and we run "just over half the
internet". 

Look at it another way. It took Ingo, with some prodding from Benno, a
couple of weeks to implement a solution that got us reliable
scheduling for sub-5ms RTT latency, supposedly one of BeOS's crown
jewels. How long do you think it will be before BeOS can support the
kinds of networking hardware and technology that Linux does ? How long
until it supports an industrial strength RDBMS ?

Right now, nobody thinks that this kind of stuff is part of
"multimedia", but I think that Alan is right; a couple of years from
now, and mark my words, people will be trying to buy systems to do
webcasting from their Nuendo setups, and if they can buy them, they
won't be running BeOS. People will want to use the kinds of tricks
that oracle have mastered to access vast warehouses of sound and video
samples. I don't see Oracle running on BeOS in the next 5 years, if
ever.

So, in summary, I think its fine for Steinberg, or anyone else, to
port stuff to BeOS. But by *focusing* on BeOS, they may miss the boat,
or alternatively, a boat that could be built easily never will be.

--p

From - Sun Sep 26 23:34:46 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA19658
	for <slinkp@ulster.net>; Sun, 26 Sep 1999 18:41:54 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA04946 for linux-audio-dev-list; Sun, 26 Sep 1999 18:04:50 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA04943 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 18:04:46 -0400
Received: from localhost.localdomain (d212-151-63-52.swipnet.se [212.151.63.52]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA18470; 
          Mon, 27 Sep 1999 00:00:17 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Date: Sun, 26 Sep 1999 23:05:12 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199909261935.PAA05166@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99092700063804.00438@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id AAA18470
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA19658
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ce344abd2ebba92484f95f1fc2a3565c

On Sun, 26 Sep 1999, Paul Barton-Davis wrote:
> >> cycle. Thats 533 instructions per frame. If you're running on a UP,
> >> which many people will be, I think that the chances of you
> >> timestamping the event with sample accuracy are not good.
> >
> >Depends on where your input events come from. Trigging a soft synth with the
> >audio input from mics will give you a source of sample accurate events.
> 
> i don't get this. are you suggesting that you are reading from an ADC,
> and then using the time implied by the sample count ? this will work
> for some cards, and not for others (some don't use the same clock for
> input as for output).

In that case you're not using hardware that's can handle your
requirements...

> It certainly won't provide sample accurate
> timestamping if you use one card for input and one for output: clock
> drift.

True, it doesn't with current OSS or ALSA drivers. But drivers with sample
accurate sync support, it's not a problem. No hardware support needed as long
as the IRQ timing as precise enough, which it is on most main stream cards.
(That is, the ones that really need it, as they have no sync interfaces.)

I intend to add this capability to the drivers I port to RTL, which means that
most cards will provide better than sample accurate timing. Not sure, but I
think some kind of sync system has been discussed on the ALSA list as well.

> OK, so if you use a Hammerfall and something else with word
> clock syncing, its not a problem, but I didn't think that you wanted
> to depend on this kind of hardware detail.

It's nice with decent hardware, but as I said, it can be done in the driver as
well. You even get about the same precision as with "real" cards when using a
kernel with low latency IRQ handling.

> I know that I don't. And
> sure, you can play games to resync the cards every so often, but this
> is not the making of a reliable system ...

Resync? If the cards drift, you simply have to drop or insert samples, or if
the difference is big, resample. Or if you don't care about an exact
sample:sample relation between the trigger inputs (as in my example), just ask
the drivers about the exact time, and convert the event time stamps from the
trigger sensor plug-ins. (That would actually be handled automatically with a
sub net system as I think of it, as these plug-ins would end up in their own
sub net that's sync'ed with the input card.)

> >Not true with a driver that time stamps input data when the
> >interrupts occur. (I did that back in the Amiga days...) And you
> >shouldn't even need that with real "high accuracy" hardware.
> 
> not sample accurate though, just real-world accurate. If you're
> running with +/- 0.5ms scheduling jitter (woo-hoo!),

An RTL driver can easily catch events and time them within 5 s or so on an
average Celeron box. The hardware can be more troublesome...

> thats still a lot
> of samples that may or may not have been generated so far by any given
> plugin. The timestamp will be accurate, but there is no way to sync it
> to the sample generation process.

If you know the offset between the time base of the event and the time base of
the output device, there's no problem.

> The best you can do is sync it to
> the state of the DAC, as understood by the engine, which is well known
> immediately after a write to the DAC has returned, but not known at
> any other time.

True. With OSS and ALSA (currently, at least). What about an IOCTL that gives
you the exact time of the next sample you'll get if you do a read()?

> in short, you can't get sample accurate timestamping unless you reduce
> the control cycle to 1, which we're agreed is a bad idea.

Still don't agree. You can't get single sample latency without a single sample
cycle, but you *can* timestamp events as precicely as the hardware and OS
allows, and you *can* use that information to handle the events with a fixed,
sample accurate delay.

You can't do it without driver support (which may require a hard RT kernel if
there's no hardware support), but there's not really a technical problem.

> >> So no, its true that Quasimodo's engine can't tell you the time with
> >> sample resolution, but plugins know the time with sample
> >> resolution. Strange, eh ?
> >
> >And? What to do with your perfect notion of time, when no one tells you
> >exactly when to do things?
> 
> Ah, now we begin to get down to the meat (although I don't eat the
> stuff :)
> 
> What *are* the events that might tell a plugin to "do something" ? 
> 
> The class of events that I imagine to have important time properties
> are those that reconfigure the processing net. Turning on a
> plugin. Turning it off. Not much else.
> 
> When someone tweaks a MIDI CC, I expect the effect to take place right
> *now*. When someone twiddles an on-screen control element, I expect
> the effect to take place right *now*. I don't see where a notion of
> "when to do things" enters into the area of parameter updates.

Automation. Live systems are obviously *very* different from studio systems...
:-)

> I consider a plugin to be a little piece of code that generates
> samples according to an algorithm and the state of its parameters. It
> doesn't change what it does unless you (1) change the algorithm, which
> is nonsensical - the plugin *is* the algorithm (+) or (2) change the
> parameters. The parameters can be updated in real time. So I can't see
> what kind of effects you might be talking about.

The audio clip player of a hard disk recording engine. It's actually *required*
to work with at least sample accuracy.

Plug-ins that are modulated from envelope generators in a soft synth or
sampleplayer. These need to stay in sync with the audio data they process, or
you'll have "analog feel" no matter if you like it or not. I certainly don't
want that kind of behaviour from an all-digital system. It's a flaw that should
have gone away with the DSP + MCU synth design (although I believe some are
still doing it that way...), as it forces you to use samplers and static
waveforms in cases where you don't want to.

> Perhaps we have a different notion of what a plugin is ? It doesn't
> seem that way, however.

Perhaps a different notion of what a plug-in should be able to do, and with
what accuracy?

> (+) NOTE: this doesn't mean that the plugin can't contain conditional
> code. But this is just handled with a parameter update. Consider a
> plugin with a switch that toggles between two different choices. Right
> now, the parameter that models the switch state is set to 1. Someone
> clicks the GUI representation, and we decide to change it to a 2. No
> problem: no timestamping needed - we just alter the parameter
> asynchronously, and the plugin keeps running.
> 
> 	process (MyClosureType *closure) 
>         {
> 
>              while (samples_to_generate) {
> 		
> 		if (*closure->switch_state == 1) {
> 		    ... foo ...
>  		} else {
>                     ... bar ...
>                 }			       
>             }
> 
>         }
> 
> There - we just told the plugin to do something, and it did it. No
> events, no timestamps. What am I missing ?

1) The engine will most likely block the GUI code on a single CPU
   machine, so you'll never recieve events in the middle of the
   process loop.

2) An any machine (UP or SMP), this plug-in may execute within a
   fraction of the time it takes to play the buffer it's changing.
   That is, the time at which the plug-in recieves the event, and
   acts upon it has a very unlinear relation to the buffer time.

Besides, having the conditional code inside the inner loop isn't very nice from
a code optimisation POV. Even if the jump predictor will be right most of the
time on a modern CPU, it will fail two or three times in the start of a change,
and that may be a significant ammount of pipeline flushes with a small buffer
size. (A pipeline flush on a Pentium MMX, P-II/III or Celeron costs around 3
instruction cycles IIRC...)

And if you have more switches, you get more trouble... For such situations, you
would be better off using a function pointer that you change when you recieve an
event, or a swith() with an ordered list of cases, as that gets optimized into
a jump table. (And if the CPU and/or compiler is smart, there are no pipeline
flushes on jump tables, as other instructions can be executed while the jump
address is being calculated.)

> >> >> if a plugin is executing in any given cycle, then its query of
> >> >> the current time will always return the same value. that doesn't mean
> >> >> there have been no events - its means its busy generating the same
> >> >> output buffer (and working on the same input buffer) as everybody
> >> >> else who will be executed during that cycle.
> >> >
> >> >"will be" is very important here.
> >> 
> >> why ?
> 
> >They're not executed in parallel == not at the same time. Unless the
> >code that "sends" events is blocked by the engine code, events may
> >occur in the middle of the cycle - which means that some plug-ins
> >will execute before that event and others after it. So, who which
> >group does the event reciever belong to...?
> 
> Once again, what kind of events are we talking about here ? Things
> that reconfigure the net don't get handled until the end of the
> control cycle.

Plug-ins dont' recieve that kind of events. (They do, however, recieve events
telling them how to act after the net, if necessary, but such events are always
first in the buffer. [If I decide to send them to the process() function at all,
that is. I have to think more about that.])

> But there aren't very many events that do that ... Most
> of them are just parameter updates. These don't change what the plugin
> "does" in the sense that it needs to be told about it. They may well
> change the output of the plugin, but it doesn't have to care about
> that :)

MIDI events? I'd say they change things pretty much in soft synth... (Note: I'm
not thinking about soft synths built from lots of small plug-ins here. This is
raw, optimized code for generating N voices.)

> >I do appreciate your insightful comments, and I have had to do a lot of
> >thinking at times to see if I'd really got things right. :-)
> 
> Likewise. I am enjoying the challenge of figuring out if Quasimodo's
> system really does make as much sense as I think it does, or if I
> missed something large, or if I missed something small. Its all good
> stuff.

I think Quasimodo's system makes a lot of sense, especially for pure low
latency real time applications. There's no way my system will beat it WRT
performance in that kind of situations.

My goal is to design and implement a system that can cover the whole range
from ultra low latency real time to off-line processing - without ending up as
something that doesn't do anything too well... (Simple, eh? ;-) The low overhead
system of Quasimodo is very inspiring when trying to turn an inherently complex
design into something nice, efficient and useful. Remains to see what all this
results in...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Sep 26 23:34:42 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA17822
	for <slinkp@ulster.net>; Sun, 26 Sep 1999 18:24:27 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA04910 for linux-audio-dev-list; Sun, 26 Sep 1999 17:46:38 -0400
Received: from bashir.belgium.eu.net (bashir.Belgium.EU.net [193.74.208.147]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA04907 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 17:46:30 -0400
Received: from (adial041.liege.eunet.be [195.207.174.41])
	by bashir.belgium.eu.net  with SMTP id XAA00426 
	for <linux-audio-dev@ginette.musique.umontreal.ca>;
	Sun, 26 Sep 1999 23:42:01 +0200 (MET DST)
Message-ID: <001101bf0867$7f11f440$b087fea9@pcbenja>
Reply-To: "Benjamin GOLINVAUX" <golinvaux@benjamin.net>
From: "Benjamin GOLINVAUX" <golinvaux@benjamin.net>
To: <linux-audio-dev@ginette.musique.umontreal.ca>
References: <199909261959.PAA06216@renoir.op.net>
Subject: Re: [linux-audio-dev] [Fwd: AES, Linux and BeOS] 
Date: Sun, 26 Sep 1999 23:38:34 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c0d4bfe4a05e2214af12e522153faa2c

> So, in summary, I think its fine for Steinberg, or anyone else, to
> port stuff to BeOS. But by *focusing* on BeOS, they may miss the boat,
> or alternatively, a boat that could be built easily never will be.

ok Paul, let's make things clear about this discussion :

I minsunderstood your statements about BeOS and thought you were dismissing
it
for (nowadays) multimedia (which roughly summarizes, for me, to low
interrupt latency, drivers and stability)

I totally agree with you when it comes to extending multimedia to big
databases and heavy network stuff.

I selfishly did not take _at all_ into account these advantages of linux,
because I don't need them.... I should say I never thought about it.

But I keep on saying that some people will love a clean, small and fast OS
that'll let them use _some kind_ of multimedia/audio applications.

But if the way to go for big packages (audio/video/midi such as Nuendo or
Logic Audio) is the net and remote databases, then BeOS won't be able to
reinvent the wheel in just a few years and won't catch this train... It
would be useless.

Until then, I can clearly see _some_ advantages by using BeOS for _some_
people.

Benjamin-


From - Sun Sep 26 23:34:50 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA21608
	for <slinkp@ulster.net>; Sun, 26 Sep 1999 19:01:09 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA04997 for linux-audio-dev-list; Sun, 26 Sep 1999 18:23:14 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA04994 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 18:23:10 -0400
Received: from localhost.localdomain (d212-151-63-52.swipnet.se [212.151.63.52]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA29225; 
          Mon, 27 Sep 1999 00:18:33 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>, Pablo Silva <hpsilva@servidor.unam.mx>
Subject: Re: [linux-audio-dev] Re: AES, Linux and BeOS
Date: Mon, 27 Sep 1999 00:11:22 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <199909261945.PAA05606@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99092700245405.00438@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id AAA29225
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA21608
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 52d7615071f2b3f92108fa5272f0a24a

On Sun, 26 Sep 1999, Paul Barton-Davis wrote:
[...]
> I don't think that BeOS is more mature. I think it is more focused. It
> also has the benefit of being an identifiable corporation, which as
> you say, tends to focus the minds of those who write software to make
> a profit.
> 
> I don't know of any particular benefits that BeOS would have over
> Linux 2.2.10-N6. Linux has better support for leading-edge audio
> applications that integrate networking and database engines. It has
> more users. Its been debugged more. I think it supports SMP better. It
> supports more hardware. You can read the source to learn how things
> are done and not done.

True, nothing beats Linux, especially not in the long run, from the developer's
POV.

> BeOS doesn't come with the same range of choices, which can often be a
> good thing. No trying to decide between OSS or ALSA. No trying to
> decide between GNOME or KDE. You use the MediaKit and/or the MidiKit,
> and thats that. Sometimes no choice is the best choice of all.

Yes. The only problem is that choice is complicated to the average user (ie
non-hacker). That means we need to do some serious work on getting plug'n'play
distros together if we want our software to be used by non-hackers. Serious
users with the cash to pay for pre-configured, dedicated systems will go
wherever the solutions are (is they are actually made available and *visible*,
that is), but that's not the case with the average user; not event the
"serious" hobby musician. And those are the ones that hardware and software
companies are making money from...

> BeOS asked me a while back to port Quasimodo. A month ago, I was
> planning to do this. Now I am not. Thats my take on the two of them.

About the same story here... I was wasting my time around NT, and I had my
eyes on DOS (protected mode) extenders and Linux for a standalone box for the
real time stuff. Also looked at QNX... and it's price tag. When I saw BeOS, I
went "Wow! Here's something that could do the job. And looks nice, too... :-)".

But then I found RTLinux, and actually started to use (RT)Linux, GNOME, KDE and
so on. This is where I'll hang around for a long time.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Sep 26 23:34:53 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA32157
	for <slinkp@ulster.net>; Sun, 26 Sep 1999 20:31:00 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA05139 for linux-audio-dev-list; Sun, 26 Sep 1999 19:45:44 -0400
Received: from kaybee.org (kaybee.resnet.gatech.edu [128.61.15.250]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA05136 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 19:45:40 -0400
Received: from localhost (rob@localhost)
	by kaybee.org (8.8.7/8.8.7) with ESMTP id TAA03286
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 19:41:14 -0400
Date: Sun, 26 Sep 1999 19:41:14 -0400 (EDT)
From: rob <rob@kaybee.org>
To: linux-audio-dev@ginette.musique.umontreal.ca
Message-ID: <Pine.LNX.4.10.9909261722290.2939-100000@kaybee.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 1de6d93409ff2f4e60ac34967dd87ce1


hey, 
	anyone interested in getting together a set of semi-std gtk
widgets for music apps like say...a waveform editor, track display, staff
display/editor, piano roll display and the like.  it would seem that some
nice reusable componenets would make putting together apps a bit easier. 
	whatdya think? 
				rob	
		

----
Rob Melby
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
Internet: rob@kaybee.org, gt4255a@prism.gatech.edu

From - Sun Sep 26 23:34:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA01804
	for <slinkp@ulster.net>; Sun, 26 Sep 1999 15:31:08 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA04564 for linux-audio-dev-list; Sun, 26 Sep 1999 14:52:25 -0400
Received: from bashir.belgium.eu.net (bashir.Belgium.EU.net [193.74.208.147]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA04561 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 14:52:17 -0400
Received: from (adial174.liege.eunet.be [195.207.174.174])
	by bashir.belgium.eu.net  with SMTP id UAA27467 
	for <linux-audio-dev@ginette.musique.umontreal.ca>;
	Sun, 26 Sep 1999 20:47:47 +0200 (MET DST)
Message-Id: <199909261847.UAA27467@bashir.belgium.eu.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] [Fwd: AES, Linux and BeOS]
Date: Sun, 26 Sep 1999 20:44:27 Set the time zone in the Time preference utility
From: "Benjamin GOLINVAUX" <golinvaux@benjamin.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1251"
Reply-To: golinvaux@benjamin.net
X-Mailer: BeOS Mail [R4.5.2]
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7573eac7a8d7c46f4a8429f03fdee9be

Linux vs BeOS
------------

I would say that the two systems could coexist peacefully because they 
both have the potential to make power audio users happy.

I really don't see this as a ocmpetition. Do you rembember the early 
years of cheap HDR ? Some people had ST systems with custom hardware, 
while others were using a Mac... It could have lasted for years if ST 
systems were PC's...

For some people, BeOS is a dream to work with : it provides very low 
scheduling jitter, can turn a cheap PC into a guitar fx box, a reliable 
sequencer... And if you want to browse the web or write some documents 
while extracting audio tracks, that's ok. No brainer. 

Linux is the choice for many on this list who are reasonably aware of 
the inner working of a computer and how they can tune their box to use 
it a DAW _or_ find the correct information to do so...

There are very good applications for Linux, the new alsa API is good, 
IMHO, and the driver support is better than BeOS (but I'm afraid it 
will change very soon (BeOS on Envy24, Sonorus, Event, RME)). The 
potential of Linux as an audio workstation is IMMENSE but it's very 
complicated to use... Don't tell me it _can_ be turned into an easy to 
use OS, I know it... But people don't buy or use potentials.

I think both OSes are to be widely used by musicians and sound 
designers, but there are sufficient differences between these OSes to 
address diffrent people...

We should all agree that BeOS and Linux are to be seen as the 
competition against MacOS and Windows rather than competing themselves.

I don't like Paul saying, wrt Steinberg :

"They seem to have
abandoned the idea of an IRIX port, and are focusing on BeOS. I gave
them a brief argument why this might be a bad idea."

It is quite useless to tell Steinberg that this is a bad idea, since 

a) it is a good idea ;-)
b) they already have a working version.

It would be ALSO be a good idea to port it to Linux, but that's 
different.

Anyway, thank you for your good work, Paul...

Benjamin-


From - Sun Sep 26 23:34:54 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA12239
	for <slinkp@ulster.net>; Sun, 26 Sep 1999 22:05:19 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA05272 for linux-audio-dev-list; Sun, 26 Sep 1999 21:24:33 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA05269 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 21:24:29 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id VAA16211
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 21:19:00 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id VAA16086; Sun, 26 Sep 1999 21:18:58 -0400 (EDT)
Date: Sun, 26 Sep 1999 21:18:52 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] [Fwd: AES, Linux and BeOS]
In-Reply-To: <37EE3B81.97AB07E@servidor.unam.mx>
Message-ID: <Pine.GSO.4.10.9909262109280.15690-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: aaff50643d472e433f6d4ba8d64a664c

On Sun, 26 Sep 1999, Pablo Silva wrote:

> In the University here I plan to set up a small effort to write
> shareware for audio applications, but I'm concerned about choosing the
> right OS to work with.

If you really mean "shareware" not "freeware", you're likely to have a
very difficult time making any money if you release for Linux.  From what
I've seen, Linux users tend to be very reluctant to spend any money on
software, and when they begrudgingly do, it's only for the very best of
breed commercial products.

I don't mean to scare you off; have you considered releasing your
applications for free (or better yet, open source)?  There are numerous
advantages, and your work will stand a much better chance of being
embraced by the Linux community.

Now that I've said that, what do the rest of you folks on the list think?
Some of you have released programs as shareware before; do you in
retrospect think it was the right decision?

Div.

From - Sun Sep 26 23:34:55 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA12660
	for <slinkp@ulster.net>; Sun, 26 Sep 1999 22:07:25 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA05285 for linux-audio-dev-list; Sun, 26 Sep 1999 21:29:53 -0400
Received: from zed.access.net.au (zed.access.net.au [203.13.25.3]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA05282 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 21:29:44 -0400
Received: from response.cx (d043.meldas2.access.net.au [203.56.116.103])
	by zed.access.net.au (8.9.3/8.9.3) with ESMTP id LAA18793;
	Mon, 27 Sep 1999 11:25:07 +1000
Message-ID: <37EEC7EC.1B76E84@response.cx>
Date: Mon, 27 Sep 1999 11:27:08 +1000
From: josh <josh@response.cx>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: rob <rob@kaybee.org>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: Music GTK libs
References: <Pine.LNX.4.10.9909261722290.2939-100000@kaybee.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: ed204f5d354ea7898a348b285afb5160

check out some of my stuff at www.response.cx/shots/
there is some gtk stuff with wave view and other things
feel free to steal code

josh

-- 
---
josh@reponse.cx
www.response.cx

rob wrote:
> 
> hey,
>         anyone interested in getting together a set of semi-std gtk
> widgets for music apps like say...a waveform editor, track display, staff
> display/editor, piano roll display and the like.  it would seem that some
> nice reusable componenets would make putting together apps a bit easier.
>         whatdya think?
>                                 rob
> 
> 
> ----
> Rob Melby
> Georgia Institute of Technology, Atlanta Georgia, 30332
> uucp:     ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
> Internet: rob@kaybee.org, gt4255a@prism.gatech.edu

From - Sun Sep 26 23:34:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA13053
	for <slinkp@ulster.net>; Sun, 26 Sep 1999 22:11:00 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA05304 for linux-audio-dev-list; Sun, 26 Sep 1999 21:36:33 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA05301 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 21:36:29 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id VAA17086
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 21:30:48 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id VAA16297; Sun, 26 Sep 1999 21:30:47 -0400 (EDT)
Date: Sun, 26 Sep 1999 21:30:45 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] AES report
In-Reply-To: <99092617464300.00438@localhost.localdomain>
Message-ID: <Pine.GSO.4.10.9909262120300.15690-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: dea53d5fbe74174bfbcfe5a466022d0a

On Sun, 26 Sep 1999, David Olofson wrote:

> Buttons and dials vs. GUIs is like keyboard shortcuts vs. drop-down menues.
> That is, unless frequently used functions map directly to the keys on the
> standard keyboard (no qualifier crap), custom hardware is needed.

Agreed, but you don't really need 200 physical dials to control 200
different parameters (I certainly don't have enough fingers and toes to
control them all at once even if I could visualize it).  You can write a
small program that remaps the few physical knobs on your synth keyboard to
arbitrary controllers.

There's no reason that you couldn't remap program (patch) change events
into "remap mod wheel to continuous controller foo" events.  Then you're
only using two physical controls, but have access to 128 virtual ones,
with nary a GUI in sight.

With your concentration on realtime precision, you were probably too
disgusted with my "good-enough" attitude on latency to try my MIDI toys
when I posted them a while back, but a few of them do exactly what I'm
describing, if you're interested.

Div.

From - Sun Sep 26 23:34:57 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA16528
	for <slinkp@ulster.net>; Sun, 26 Sep 1999 22:40:31 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA05353 for linux-audio-dev-list; Sun, 26 Sep 1999 22:00:33 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA05350 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 22:00:29 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id VAA18778
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 21:55:44 -0400 (EDT)
Received: from localhost by ux02 (8.8.8+Sun) id VAA16814; Sun, 26 Sep 1999 21:55:43 -0400 (EDT)
Date: Sun, 26 Sep 1999 21:55:41 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: your mail
In-Reply-To: <Pine.LNX.4.10.9909261722290.2939-100000@kaybee.org>
Message-ID: <Pine.GSO.4.10.9909262145020.15690-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 6616206c9391d4374d68ba94bb39fa8d

On Sun, 26 Sep 1999, rob wrote:

> 	anyone interested in getting together a set of semi-std gtk
> widgets for music apps like say...a waveform editor, track display, staff
> display/editor, piano roll display and the like.  it would seem that some
> nice reusable componenets would make putting together apps a bit easier. 

Neat idea, but does it actually make sense?  The main differentiation
point between various music applications these days is the respective
quality of just these types of widgets.  

Why do I use Cakewalk instead of Cubase?  Because I like its piano roll
widget better.  But I don't like it enough, which is one of the primary
reasons I'm writing my own sequencer.  Why does Finale cost more than
Encore?  Because its staff widget is fuller-featured.  I'm sure the same
can be said of the other widgets you're describing.

If your common widgets were exceptionally well designed so that the
API user could add custom behaviours at nearly every stage of the widget
instance's life (like the Tk canvas, for instance), then they might be
usable, but it is very hard to design things in such a customizable
manner.

Sorry to be so negative about this though; I really do like the idea.
Div.

From - Sun Sep 26 23:43:24 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA22936
	for <slinkp@ulster.net>; Sun, 26 Sep 1999 23:46:40 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA05490 for linux-audio-dev-list; Sun, 26 Sep 1999 23:11:31 -0400
Received: from kaybee.org (kaybee.resnet.gatech.edu [128.61.15.250]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA05487 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 23:11:28 -0400
Received: from localhost (rob@localhost)
	by kaybee.org (8.8.7/8.8.7) with ESMTP id XAA04547;
	Sun, 26 Sep 1999 23:07:01 -0400
Date: Sun, 26 Sep 1999 23:07:01 -0400 (EDT)
From: rob <rob@kaybee.org>
To: David Slomin <dgslomin@CS.Princeton.EDU>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: music widgets
In-Reply-To: <Pine.GSO.4.10.9909262145020.15690-100000@ux02.CS.Princeton.EDU>
Message-ID: <Pine.LNX.4.10.9909262258090.4330-100000@kaybee.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5a7a756a97155f7bd69d7c81302e1da5

On Sun, 26 Sep 1999, David Slomin wrote:

> On Sun, 26 Sep 1999, rob wrote:
> Why do I use Cakewalk instead of Cubase?  Because I like its piano roll
> widget better.  But I don't like it enough, which is one of the primary
> reasons I'm writing my own sequencer.  Why does Finale cost more than
> Encore?  Because its staff widget is fuller-featured.  I'm sure the same
> can be said of the other widgets you're describing.

	you bring up a very important point.  a real common problem i
have is for example:  i like logic, except for the staff editing which
doesn't really suit me.  for staff editing i prefer cakewalk, however i
think that cakewalk is much less mature than logic.
	so why can't i have cake's staff editing in logic?  well, for
companies it would be silly to let a competitor have the things that make
their program unique.  this is best for the company but certainly not for
the consumer.
	as open source folk, there are two types of resuse.  modular
reuse, for example in libraries that are common, and cut and paste reuse,
where one can use another application's code as a starting point for my
own improvements.  and those improvements can be released back for others
to use.  this means that the advantage of creating a set of common music
widgets is not only in their use as is, but as starting points for other
to improve.
	i think that it would be interesting to have pluggable editors.
editing and composition styles create strong likes and dislikes of certain
interfaces, but there is no objective way to judge a particular widget as
the *best*.  so the easiest way to work with this, is to let the user have
a set of choices that they could easily use, and which needn't force them
to choose a program on the basis of a certain feature. 
	additionally scripting langauges....like lisp or scheme (guile) or
tcl can create a sort of emacs for music.  
	does this make any sense? 

				rob
----
Rob Melby
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
Internet: rob@kaybee.org, gt4255a@prism.gatech.edu

From - Sun Sep 26 23:34:59 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA19953
	for <slinkp@ulster.net>; Sun, 26 Sep 1999 23:14:26 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA05387 for linux-audio-dev-list; Sun, 26 Sep 1999 22:18:22 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA05383 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 22:18:19 -0400
Received: from someip.ppp.op.net (d-bm3-0b.ppp.op.net [209.152.194.75]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id WAA25486 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 22:13:51 -0400 (EDT)
Message-Id: <199909270213.WAA25486@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] AES report 
In-reply-to: Your message of "Sun, 26 Sep 1999 21:30:45 EDT."
             <Pine.GSO.4.10.9909262120300.15690-100000@ux02.CS.Princeton.EDU> 
Date: Sun, 26 Sep 1999 23:09:34 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4905d56c7707711856c2f53feeda90aa

>> Buttons and dials vs. GUIs is like keyboard shortcuts vs. drop-down menues.
>> That is, unless frequently used functions map directly to the keys on the
>> standard keyboard (no qualifier crap), custom hardware is needed.
>
>Agreed, but you don't really need 200 physical dials to control 200
>different parameters (I certainly don't have enough fingers and toes to
>control them all at once even if I could visualize it).  You can write a
>small program that remaps the few physical knobs on your synth keyboard to
>arbitrary controllers.
>
>There's no reason that you couldn't remap program (patch) change events
>into "remap mod wheel to continuous controller foo" events.  Then you're
>only using two physical controls, but have access to 128 virtual ones,
>with nary a GUI in sight.

Although I personally agree, I would say from watching people's
response to "proper" physical interface design at AES that people who
work with this stuff all day don't like that kind of approach. 

The new Mackie HDR is a case in point. From what I could tell, its
nothing much more than a EIDE drive coupled to a very minimal OS (it
might even run DOS internally for all I know or care), and some
appropriate data interfaces. As a computer geek, I'm standing there
looking at it saying "yeah, so what ?" But the crowd was wildly
enthusiastic. Similarly with related products from OMD and
others. Mackie added an on-off button for each track, a play/record
button for each track, regular tape/CD transport controls, and they're
golden. 

The "virtual" device interface, wherein a single set of controls can
be remapped to many different copies of the same device was very
popular a few years back. It makes sense for things like mixing
consoles, where there is massive duplication of hardware without
it. But only to a point. I've heard studio engineers complain that
even living with 16 strips on a 24 track console can be annoying.

Yeah, it saves money, and it works. But its not the best solution. I
say that with a heavy heart, since I'm about to buy a Mackie HUI for
exactly this kind of thing.

--p

From - Sun Sep 26 23:43:18 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA22759
	for <slinkp@ulster.net>; Sun, 26 Sep 1999 23:44:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA05441 for linux-audio-dev-list; Sun, 26 Sep 1999 23:04:28 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA05437 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 23:04:21 -0400
Received: from someip.ppp.op.net (d-bm3-0b.ppp.op.net [209.152.194.75]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id WAA28109 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 26 Sep 1999 22:59:47 -0400 (EDT)
Message-Id: <199909270259.WAA28109@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress? 
In-reply-to: Your message of "Sun, 26 Sep 1999 23:05:12 +0200."
             <99092700063804.00438@localhost.localdomain> 
Date: Sun, 26 Sep 1999 23:55:30 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ec17555f68c7936bd44b512750f174f7

>An RTL driver can easily catch events and time them within 5 usecs or so on an
>average Celeron box. The hardware can be more troublesome...

regular Linux can do the same thing - remember, RTL doesn't improve
the latency of an ISR (sti/cli excepted). 

>> thats still a lot
>> of samples that may or may not have been generated so far by any given
>> plugin. The timestamp will be accurate, but there is no way to sync it
>> to the sample generation process.
>
>If you know the offset between the time base of the event and the time base of
>the output device, there's no problem.

sure, but there is no fixed offset if its measured with sample
resolution. you simply don't know the difference at any particular
point in time.

>> The best you can do is sync it to
>> the state of the DAC, as understood by the engine, which is well known
>> immediately after a write to the DAC has returned, but not known at
>> any other time.
>
>True. With OSS and ALSA (currently, at least). What about an IOCTL that gives
>you the exact time of the next sample you'll get if you do a read()?

ALSA provides an ioctl that does something fairly close to this, so it
wouldn't be hard to fix i think. but this still won't give you sample
accuracy unless you read the data from the driver in single samples.

Consider the following scenario:

	 * engine has just finished a control cycle, and has
	   returned from sending data to the output interface (DAC,
	   ADAT, whatever). We assume that it blocks until space
	   is available there, assuring us that we are synced with
	   the output stream.

	 * engine grabs a control-cycle's worth of input samples
	   to make them available for the next cycle of plugin
	   execution.

	 * engine starts plugin cycle. 

	 * interrupt occurs from some external h/w source (not audio). its
	   timestamped, preferably by the driver, but possibly in user
	   space, and the event it represents becomes available for
	   use by the engine. 

	 * the engine finishes the plugin cycle, and sends the data
	   to the output interface. 

	 * the engine gets the cycle's worth of input data.

	 * it starts the next plugin cycle, queueing the event in the
	   plugins' event buffers.

OK, so how is that event supposed to have sample accurate sound ? All
we know at that point that the event occurs is that a control cycle
has started. We have no idea how far along we are, because we could be
in the middle of any given plugin, or the beginning or the end, or in
between them. We could estimate how long the cycle will take, based on
previous cycles with the same net, and then judge from that, but this
is not going to provide sample accuracy. 

The best I can see is to use the ioctl call to determine the current
time as far as the *output* interface is concerned. You can't use the
*input* interface, because it will give a time based on the samples
you've already read, rounding its accuracy to the buffer size.

But this implies that timestamping happens in user space, because
otherwise its a cross driver call, which may not be a very good idea
from an ISR context. If its in user space, I don't think that the
timing will be better than 0.5ms, and even that is with the user
thread running SCHED_FIFO, and presumably not the engine thread - bad
news on a UP box ...

>> What *are* the events that might tell a plugin to "do something" ? 
>> 
>> The class of events that I imagine to have important time properties
>> are those that reconfigure the processing net. Turning on a
>> plugin. Turning it off. Not much else.
>> 
>> When someone tweaks a MIDI CC, I expect the effect to take place right
>> *now*. When someone twiddles an on-screen control element, I expect
>> the effect to take place right *now*. I don't see where a notion of
>> "when to do things" enters into the area of parameter updates.
>
>Automation. Live systems are obviously *very* different from studio systems...
>:-)

Nope. The automation I've seen in ProTools, Logic, the Pulsar and
others tells something when to change a parameter. It doesn't tell a
plugin to *do* anything.

>> I consider a plugin to be a little piece of code that generates
>> samples according to an algorithm and the state of its parameters. It
>> doesn't change what it does unless you (1) change the algorithm, which
>> is nonsensical - the plugin *is* the algorithm (+) or (2) change the
>> parameters. The parameters can be updated in real time. So I can't see
>> what kind of effects you might be talking about.

>The audio clip player of a hard disk recording engine. It's actually
>*required* to work with at least sample accuracy.

thats a different issue. we're talking about events that alter the
behaviour of the plugin. perhaps i'm missing something here.

>Plug-ins that are modulated from envelope generators in a soft synth
>or sampleplayer. These need to stay in sync with the audio data they
>process,

are you talking about envelope generators that are part of the same
system ? once again, these just do parameter updates - they do not
change the code that a plugin executes.

>2) An any machine (UP or SMP), this plug-in may execute within a
>   fraction of the time it takes to play the buffer it's changing.
>   That is, the time at which the plug-in recieves the event, and
>   acts upon it has a very unlinear relation to the buffer time.

Right this is a point you've made before. I accept it, and I'm not
trying to get around it. But my point is that the example shows how
async parameter updates remove any need for events or timestamps for
the most common class of events. Whether or not they actually occur
asynchronously with plugin execution is a side-effect, and mostly
irrelevant. 

 [ ... code criticism elided ... ]

OK, OK. I didn't mean this as a piece of production code, just psuedo
code for pedagogical purposes. If I have to write it reasonably
efficiently, it would look something like this:

process (MyClosureType *closure)
{
	unsigned int nframes = control_cycle_frames;

	switch (*closure->switch_state) {
	case 1:
		while (--nframes) {
			... foo ...
		};
		break;
	case 2:
		while (--nframes) {
			... bar ...
		};
		break;
	.
        .
        .
        }
}

>> But there aren't very many events that do that ... Most
>> of them are just parameter updates. These don't change what the plugin
>> "does" in the sense that it needs to be told about it. They may well
>> change the output of the plugin, but it doesn't have to care about
>> that :)

>MIDI events? I'd say they change things pretty much in soft
>synth... (Note: I'm not thinking about soft synths built from lots of
>small plug-ins here. This is raw, optimized code for generating N
>voices.)

ah, thats what I mean by having a different idea of what a plugin
should be.  

i don't want to use such a piece of code - its just doesn't do what i
want, which is to be modular, flexible, reusable and extensible. ok,
so you gain a few percent speed by coding it that way, but by next
year, we'll be back to square one on that count as long as N stays the
same (which I'd argue it basically does). 

every time i want to rip out the oscillator algorithm, it means
recompiling the plugin. every time i decide i want to alter the filter
design, it means more code, possible slowdowns if I want to be able to
select different filters at runtime, etc. for me, the whole attraction of
"plugins" is that they avoid this kind of thing.

so, yes, in the case you describe, MIDI events would be significant,
since they may fundamentally alter what the plugin does. but in a
system where all a MIDI note does is to insert a new copy of the
plugin into the processing net, there is no reason to communicate such
events to plugins at all.

[ just a note on something related to this: polyphonic plugins are one
  area of quasimodo where things don't feel quite right. because there
  is only one copy of the output buffer for the plugin, each "voice" (an
  instance of the plugin within the current DSP program/net) has to
  cooperate a little bit to avoid trashing the current contents of the
  buffer. This is easily accomplished: the plugin uses a special DSP
  instruction that resets the output buffer(s) once per control cycle
  regardless of the number of voices, and the plugin uses "+=" instead
  of "=" when assigning values to the output buffer, so that we end up
  with the summed output of all the voices, not just the output of the
  last voice to run.

  even so, it bothers me.
]

i don't think that our aims for Audiality and Quasimodo really differ
at all. my purpose in discussing all this has been to try to see if I
am not noticing something that would prevent Quasimodo from evolving
into exactly the kind of system we are both talking about. I mean, as
far as offline processing goes, Quasimodo already handles Csound
scores, which in many cases can never be handled in real-time. You
just turn on Quasimodo's "tape" interface, shutdown the DAC, and let
it run. By morning, your 512-piece orchestra, which individual reverb
for each instrument, should have finished playing "Happy Birthday" or
its equivalent in Sweden :)

--p

From - Mon Sep 27 01:23:20 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA30655
	for <slinkp@ulster.net>; Mon, 27 Sep 1999 01:26:28 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA05690 for linux-audio-dev-list; Mon, 27 Sep 1999 00:47:15 -0400
Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [207.175.42.154]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA05687 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Sep 1999 00:47:12 -0400
Received: from localhost (sopwith@localhost)
	by lacrosse.corp.redhat.com (8.9.3/8.9.3) with ESMTP id AAA13146;
	Mon, 27 Sep 1999 00:42:31 -0400
Date: Mon, 27 Sep 1999 00:42:31 -0400 (EDT)
From: Elliot Lee <sopwith@redhat.com>
X-Sender: sopwith@lacrosse.corp.redhat.com
To: josh <josh@response.cx>
cc: rob <rob@kaybee.org>, linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Music GTK libs
In-Reply-To: <37EEC7EC.1B76E84@response.cx>
Message-ID: <Pine.LNX.4.10.9909270041160.10161-100000@lacrosse.corp.redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 57f86db0a9aba806531e8799fb6b98a9

On Mon, 27 Sep 1999, josh wrote:

> check out some of my stuff at www.response.cx/shots/

Just in case anyone is trying to get to this, I think the correct URL is
http://www.response.cx/shots.html

-- Elliot					http://developer.gnome.org/
The first thing a programmer needs to admit is that any program is by far
more complex than his own mind. Thats why he partitions it into neat
pieces and avoids complexity.

From - Tue Sep 28 00:32:28 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA16834
	for <slinkp@ulster.net>; Mon, 27 Sep 1999 07:46:35 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA06291 for linux-audio-dev-list; Mon, 27 Sep 1999 06:48:28 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA06288 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Sep 1999 06:48:22 -0400
Received: from gardena.net ([194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id MAA15466;
	Mon, 27 Sep 1999 12:43:38 +0200
Received: from localhost (localhost [[UNIX: localhost]])
	by gardena.net (8.9.3/8.9.3) id MAA00590;
	Mon, 27 Sep 1999 12:30:51 +0200
From: Benno Senoner <sbenno@gardena.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Fullduplex audio client/server implementation
Date: Mon, 27 Sep 1999 11:19:19 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: audiality@swipnet.se, Paul Barton-Davis <pbd@Op.Net>
MIME-Version: 1.0
Message-Id: <99092712305000.00540@goblin.flashnet.it>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: eae95492631d1df4b747fae6ea90fa5b

Hi,

I'm still thinking about an ideal audio-server implementation (userspace).
I'm trying to introduce as few as possible sync points between client and
server.
what about this implementation:
Please read carefully it should be quite optimal.

(we assume blocking read/write to /dev/dsp)

SERVER:
-------
while(1)
{
  read() from /dev/dsp  to a shared mem input buffer
  for(i=0;i<NUM_CLIENTS;i++)
  {
    if(client[i]->shmem.ready)    // when client is ready it sets the ready flag
in the shmem buffer
     {
       read audiodata from client i via shmem
       mix audiodata ( client[i].shmem.oubuf ) to output buffer  
    }
  }
  write() output buffer to /dev/dsp
  for(i=0;i<NUM_CLIENTS;i++)
  {
    client[i]->shmem.ready=0;
    wakeup client i  (through a semaphore or message)
  }
}  
-----

CLIENT:
----
clear client's audio output buffer
shmem.ready=1;
wait for wakeup from server ( through msgrcv() or a semaphore)
while(1)
{
  do DSP computations using as input buffer the server's shared audio input
buffer
  write results to shmem.outbuf
  shmem.ready=1;
  wait for wakeup from server
}
------


Note that the server gets the processed fragment from the client one iteration
later, since the client does it's own computations during the client blocks on
the read() from /dev/dsp.

The only drawback of this approach is that the minimum Input-to-output latency
you get is 3 fragments.

with a monolithic implementation ( no client/server )
while()
{
  read() from /dev/dsp
  do_processing()
  write() to /dev/dsp
}

you can get a minimum of 2 fragments latency, but if you want to use up to 100%
of the CPU, you can't afford even a minimal jitter amount,
since after the do_processing() there are only very few bytes in the audio
buffer left.
That means you need the 3rd fragment anyway.

The difference between my audio server implementation, and the above monolithic
implementation is that, if we assume we want 3 fragments I/O latency,
in the audio server case we have to preload the output buffer with 2 fragments,
while in the other case you have to preload it with 3 fragments.

look at the audio server example:
we assume we want 3 fragments I/O latency,
we need only a 2 fragments bufffer for output
W: write buffer
R: read buffer 
[    ]  fragment
[ 00000000 ]  fragment filled with 0's
[ ________ ]  empty fragment 


1) server writes 2 fragments to the output buffer

W  [ 00000000 ]  [ 00000000 ]
R   [ ________ ]  [ ________ ]

server enters main loop:

2) server does blocking read() from /dev/dsp to shared mem buffer, 
    the first output fragment got played, the read buffer contains exactly 1
fragment of audio data

W  [ 00000000 ]  [ ________ ]
R   [ ________ ]  [ 11111111 ]

3) server reads data processed data from client , but since it is the first
loop we get a 0-filled buffer. The server now writes the client data to the
output buffer (we assume only 1 client here, but the behavior is the same with
multiple clients, except that you have to mix the client's data first before
writing to output buffer)

W  [ 00000000 ]  [ 00000000 ]
R   [ ________ ]  [ ________ ]

4) is the same step as 2)  ( read() from /dev/dsp ... etc. )

W  [ ________ ]  [ 00000000 ]
R   [ ________ ]  [ 22222222 ]


5) server reads data from client ( "11111111" fragment ) and writes data to
output buffer.

W  [ 11111111 ]  [ 00000000 ]  
R   [ ________ ]  [ ________ ]

now our first fragment read from the ADC is finally in the audio output buffer,
but we see that it takes 3 fragments until the "11111111" fragment get into the
output buffer, since we have to play the first 2 zero-filled fragments,
plus the frist 0-filled fragment from the client since the client gets the ADC
data from the server one fragment later.

But we see that there is always at least 1 fragment in the buffer, that means
the scheduling jitter can be as high as one fragment-play-time.


This audio client-server model seems quite optimized to me since there
is only 1 sync point per DSP cycle between server and clients (= less scheduling
overhead), no additional mem copying is involved since it's all implemented via
shared memory buffers and you can get as low as 3 fragments effective I/O audio
latency, which is the pratical minimum in a system where you have to
take scheduling jitter into account.

Of course the the server doesn't wait for clients, therefore a too slow client
(perhaps because it doesn't run SCHED_FIFO due to lack of permissions etc.),
can't ruin the behaviour of other audio streams.
The udible effect will be that only the audio stream produced by the slow
client, will be affected by "audio drop-outs" but not the rest of streams.

comments ?

regards,
Benno.






From - Tue Sep 28 00:32:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA14473
	for <slinkp@ulster.net>; Mon, 27 Sep 1999 11:28:35 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA06650 for linux-audio-dev-list; Mon, 27 Sep 1999 10:10:27 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA06647 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Sep 1999 10:10:20 -0400
Received: from gardena.net ([194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id QAA18879;
	Mon, 27 Sep 1999 16:05:35 +0200
Received: from localhost (localhost [[UNIX: localhost]])
	by gardena.net (8.9.3/8.9.3) id PAA01052;
	Mon, 27 Sep 1999 15:56:06 +0200
From: Benno Senoner <sbenno@gardena.net>
To: David Olofson <audiality@swipnet.se>, Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Date: Mon, 27 Sep 1999 15:05:46 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <99092700063804.00438@localhost.localdomain>
MIME-Version: 1.0
Message-Id: <99092715560501.00540@goblin.flashnet.it>
X-MIME-Autoconverted: from 8bit to quoted-printable by em.gardena.net id QAA18879
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id LAA14473
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7cfe4a969609c99b52cf744926eaded8

On Sun, 26 Sep 1999, David Olofson wrote:
> 
> An RTL driver can easily catch events and time them within 5 s or so on an
> average Celeron box. The hardware can be more troublesome...

Yes, but audiality will run as a userspace process on most systems,
therefore we should include a solution optimized for that case:
ignore (do not generate/process) timestamps for realtime data,
like MIDI input.

>> 
> > in short, you can't get sample accurate timestamping unless you reduce
> > the control cycle to 1, which we're agreed is a bad idea.
> 
> Still don't agree. You can't get single sample latency without a single sample
> cycle, but you *can* timestamp events as precicely as the hardware and OS
> allows, and you *can* use that information to handle the events with a fixed,
> sample accurate delay.

I agree with David:
a MIDI/audio sequencer which generates timestamped events a few msecs ahead,
can provide sample accurate audio output.
The only effect of the scheduling jitter is that the output buffers get more or
less filled ( = no effect at all) , but the audio output will be 100% sample
accurate.
For realtime MIDI input we have to live with the scheduling jitter, but since
it is below/within the MIDI byte transfer time, we are better/as good as
hardware counterparts.
Therefore I'm not worried about this issue.

> > When someone tweaks a MIDI CC, I expect the effect to take place right
> > *now*. When someone twiddles an on-screen control element, I expect
> > the effect to take place right *now*. I don't see where a notion of
> > "when to do things" enters into the area of parameter updates.
> 
> Automation. Live systems are obviously *very* different from studio systems...
> :-)
> 

>> > (+) NOTE: this doesn't mean that the plugin can't contain conditional
> > code. But this is just handled with a parameter update. Consider a
> > plugin with a switch that toggles between two different choices. Right
> > now, the parameter that models the switch state is set to 1. Someone
> > clicks the GUI representation, and we decide to change it to a 2. No
> > problem: no timestamping needed - we just alter the parameter
> > asynchronously, and the plugin keeps running.
> > 
> > 	process (MyClosureType *closure) 
> >         {
> > 
> >              while (samples_to_generate) {
> > 		
> > 		if (*closure->switch_state == 1) {
> > 		    ... foo ...
> >  		} else {
> >                     ... bar ...
> >                 }			       
> >             }
> > 
> >         }
> > 
> > There - we just told the plugin to do something, and it did it. No
> > events, no timestamps. What am I missing ?
> 
> 1) The engine will most likely block the GUI code on a single CPU
>    machine, so you'll never recieve events in the middle of the
>    process loop.

Agreed.

> 
> 2) An any machine (UP or SMP), this plug-in may execute within a
>    fraction of the time it takes to play the buffer it's changing.
>    That is, the time at which the plug-in recieves the event, and
>    acts upon it has a very unlinear relation to the buffer time.

Agreed.
> 
> Besides, having the conditional code inside the inner loop isn't very nice from
> a code optimisation POV. Even if the jump predictor will be right most of the
> time on a modern CPU, it will fail two or three times in the start of a change,
> and that may be a significant ammount of pipeline flushes with a small buffer
> size. (A pipeline flush on a Pentium MMX, P-II/III or Celeron costs around 3
> instruction cycles IIRC...)
> 
> And if you have more switches, you get more trouble... For such situations, you
> would be better off using a function pointer that you change when you recieve an
> event, or a swith() with an ordered list of cases, as that gets optimized into
> a jump table. (And if the CPU and/or compiler is smart, there are no pipeline
> flushes on jump tables, as other instructions can be executed while the jump
> address is being calculated.)

Yes, all this overhead for only reaching a bit better realtime response ?
No thanks.
I *STRONGLY* dislike conditionals in the innermost loop,
plus the unlinear relation to the buffer time makes this almost worthless to me.
Not to mention weird things like plugin-B getting the new parameter change,
while plugin-A was already processed and generated data with the old parameter
settings
= unwanted "analog feel" ??
:-)

With David's event approach, not only you get almost all the time the same
performance as with non-sample accurate processing (per-fragment parameter
changes), since the parameter density most of the time is much lower than
the fragment cycle-frequency,
but things will stay perfectly in sync, since all plugins get the events at the
right time, regardless of the order of processing.

the sample accurate event positioning, adds only a conditional buffer-split at
the begin of the fragment processing, like David described.

event_time=event.time;  (in samples)
samples_before_event=actual_time-event_time;
rest_samples=samples_per_buffer=samples_before_event;
while(--samples_before_event)
{
  process_sample()
}
process the event (change parameters etc)
while(--rest_samples)
{
  process_sample();
}


as you see , just setting samples_before_event=0, just quantizes 
events to fragment boundaries.
The overhead of the first while is very low, compared to Paul's
"event-happened" checking at the innermost loop.
Of the above example doesn't cover the "more than 1 event per fragment" case
but it's almost trivial to implement, without adding much overhead.
(can be implemented by wrapping the above code fragment around a
while(--num_events_in_this_fragment) { ... }  or so)
Right David ?
I too, was sceptical about the sample accurate event system but I'm
now almost 100% convinced, since it doesn't seem to have conceptual
design flaws to me.
Of course the sample accurate event processing will slow down very much,
if you send a huge number of events per fragment, but that's another story,
and we assume that it will not happen in real world.
For oscillator modulations we will use low frequency wavetables, instead
of sending myriads of events, stressing the David's poor memory management
system.   
:-)


> I think Quasimodo's system makes a lot of sense, especially for pure low
> latency real time applications. There's no way my system will beat it WRT
> performance in that kind of situations.

Agreed, the goal is to make a framework which is flexible *AND* doesn't add
much overhead compared to Quasimodo.

> 
> My goal is to design and implement a system that can cover the whole range
> from ultra low latency real time to off-line processing - without ending up as
> something that doesn't do anything too well... (Simple, eh? ;-) The low overhead
> system of Quasimodo is very inspiring when trying to turn an inherently complex
> design into something nice, efficient and useful. Remains to see what all this
> results in...

To me the event overhead seems not too heavy compared to other processing
tasks you have to do when doing DSP stuff in software.

regards,
Benno.

From - Tue Sep 28 00:32:43 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA27879
	for <slinkp@ulster.net>; Mon, 27 Sep 1999 12:48:40 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA06903 for linux-audio-dev-list; Mon, 27 Sep 1999 12:01:28 -0400
Received: from www.tomy.net (www.tomy.net [209.186.149.104]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA06900 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Sep 1999 12:01:24 -0400
From: thudson@cygnus.com
Received: from cygnus.com (IDENT:thudson@jimi.tomy.net [192.168.1.2])
	by www.tomy.net (8.9.3/8.9.3) with ESMTP id GAA13298;
	Mon, 27 Sep 1999 06:53:49 -0400
Message-ID: <37EF93D2.8A0555DC@cygnus.com>
Date: Mon, 27 Sep 1999 11:57:06 -0400
Organization: Cygnus Solutions
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: rob <rob@kaybee.org>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: 
References: <Pine.LNX.4.10.9909261722290.2939-100000@kaybee.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: a576a10cecaa5f4b82d67ad8da913b8d

rob wrote:
> 
> hey,
>         anyone interested in getting together a set of semi-std gtk
> widgets for music apps like say...a waveform editor, track display, staff
> display/editor, piano roll display and the like.  it would seem that some
> nice reusable componenets would make putting together apps a bit easier.

I think this is a great idea, a sort of music app toolkit. A few others
I've been thinking about:

- Dial widget: With some nice bitmaps of real knobs.
- Transient generator editor widget (variant of the gtk curve widget): Allows
one to draw a curve repesenting things like attack, decay, release, etc.
- Abstract connection widget: Some abstraction of the canvas widget that
 would allow programmers to describe inputs and outputs of modules and
allow the user to make connections between them. 

Of course, it might be worthwile to go beyond just gui elements. I've
been toying with a System Exclusive Editor/Librarian toolkit. The other
idea I have is something similar to OMS, that would discover (allow a 
user to describe) a midi setup, so that midi apps could specify connections
to real midi (or software) devices rather than "/dev/midi0." 

"Connect keyboard to midi-in of sequencer"
"Connect output of sequencer to input of Midi Echo program"
"Connect output of Midi Echo program to Expensive External Synth"

Thomas

From - Tue Sep 28 00:32:49 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA14279
	for <slinkp@ulster.net>; Mon, 27 Sep 1999 14:47:00 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA07210 for linux-audio-dev-list; Mon, 27 Sep 1999 14:02:48 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA07207 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Sep 1999 14:02:45 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id NAA09862;
	Mon, 27 Sep 1999 13:55:37 -0400 (EDT)
Received: from localhost by ux02 (8.9.1b+Sun) id NAA03643; Mon, 27 Sep 1999 13:55:33 -0400 (EDT)
Date: Mon, 27 Sep 1999 13:55:26 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: rob <rob@kaybee.org>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: music widgets
In-Reply-To: <Pine.LNX.4.10.9909262258090.4330-100000@kaybee.org>
Message-ID: <Pine.GSO.4.10.9909271332380.3193-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ad6aeac72c75ffb7fa723abaa91403e7

On Sun, 26 Sep 1999, rob wrote:

> 	i think that it would be interesting to have pluggable editors.
> editing and composition styles create strong likes and dislikes of certain
> interfaces, but there is no objective way to judge a particular widget as
> the *best*.  so the easiest way to work with this, is to let the user have
> a set of choices that they could easily use, and which needn't force them
> to choose a program on the basis of a certain feature. 

I rather like that idea, because it extends the small, focussed, reusable,
and replacable tool design of Unix-style command line tools to the GUI
construction domain.  Think of the host app as a command shell and the
widgets as command-line programs.

My only objection is just how are you going to plug them in?  How do I
plug a staff widget written using GTK into a host app written using Qt? In
my analogy to shell programming, you have stdin, stdout, environment
variables, and files as standardized methods of communication between the
"plugins".  Just about the only means of communication I can think of
that's standard across toolkits for widgets is the X clipboard, and even
that's a little shaky.

> 	additionally scripting langauges....like lisp or scheme (guile) or
> tcl can create a sort of emacs for music.  

I personally prefer the bottom-up approach (common widgets which can be
reused in different host apps) to the top-down approach (a single host app
which is customizable through heavy scripting support), but both are very
valid and useful.  Keep in mind, the top-down approach has been tried many
times in music apps (I can think of examples for each of the languages you
mentioned), and has not necessarily proven to be a solution to all life's
problems.  

So I prefer the bottom-up approach in general, and the
language/platform/toolkit (Java) of the host app I'm currently writing
(Songpad) has strong support for reusable widgets (Beans).  However, I'm
still probably going to end up using the top-down approach because it is
excruciatingly difficult to design a complex widget to be flexible enough
for reuse.  Designing cripting hooks to be sufficiently flexible is also
difficult, but not quite as bad, it seems to me.

Div.

From - Tue Sep 28 00:32:52 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA15851
	for <slinkp@ulster.net>; Mon, 27 Sep 1999 14:57:22 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA07257 for linux-audio-dev-list; Mon, 27 Sep 1999 14:09:23 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA07253 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Sep 1999 14:09:20 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id OAA11114
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Sep 1999 14:04:37 -0400 (EDT)
Received: from localhost by ux02 (8.9.1b+Sun) id OAA04013; Mon, 27 Sep 1999 14:04:33 -0400 (EDT)
Date: Mon, 27 Sep 1999 14:04:30 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: 
In-Reply-To: <37EF93D2.8A0555DC@cygnus.com>
Message-ID: <Pine.GSO.4.10.9909271401050.3193-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b2719a71f37d2bee27e5171d38f25de4

On Mon, 27 Sep 1999 thudson@cygnus.com wrote:

> "Connect keyboard to midi-in of sequencer"
> "Connect output of sequencer to input of Midi Echo program"
> "Connect output of Midi Echo program to Expensive External Synth"

I have already implemented this and it works very nicely.  I do it from
the shell, using conventional pipes (or named pipes) and sockets as
transports for the connections.  Take a look at my NetMIDI toys
(http://patriot.altavista-software.com/~div/xfr/); I'll have a decent web
page for them soon.

Div.

From - Tue Sep 28 00:32:46 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA08585
	for <slinkp@ulster.net>; Mon, 27 Sep 1999 14:11:26 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA07126 for linux-audio-dev-list; Mon, 27 Sep 1999 13:23:08 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA07123 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Sep 1999 13:22:59 -0400
Received: from someip.ppp.op.net (d-bm2-12.ppp.op.net [209.152.194.50]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id NAA22374 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Sep 1999 13:18:28 -0400 (EDT)
Message-Id: <199909271718.NAA22374@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress? 
In-reply-to: Your message of "Mon, 27 Sep 1999 15:05:46 +0200."
             <99092715560501.00540@goblin.flashnet.it> 
Date: Mon, 27 Sep 1999 14:14:05 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4d18be9311f7b92da11ff4a1c4462522

>Yes, all this overhead for only reaching a bit better realtime response ?

Look, it was pedagogical code, not optimized real time stuff. I was
trying to illustrate that you don't need an event system to do this.

>No thanks. I *STRONGLY* dislike conditionals in the innermost loop,
>plus the unlinear relation to the buffer time makes this almost
>worthless to me.  Not to mention weird things like plugin-B getting
>the new parameter change, while plugin-A was already processed and
>generated data with the old parameter settings = unwanted "analog
>feel" ??  :-)

NO! parameters cannot, by definition, be shared across plugins. One
exception to this that Csound permits is direct access to MIDI
controller values, but I haven't seen or written any plugins that use
this feature. So what you describe doesn't happen, not precisely like
that anyway.

>With David's event approach, not only you get almost all the time the same
>performance as with non-sample accurate processing (per-fragment parameter
>changes), since the parameter density most of the time is much lower than
>the fragment cycle-frequency,
>but things will stay perfectly in sync, since all plugins get the events at th
>e
>right time, regardless of the order of processing.
 ^^^^^
   lets just say "same" time, please.

David's event-based system instead delays the parameter change by up
to 1 control cycle in the interest of synchronization. But then he
points out that its extremely unlikely that any given parameter change
will arrive *during* the execution of any particular plugin, and we
all agree on that, with the exception of running a CPU-intensive
single plugin, which we also agree on.

So, here I am, presenting a close-to-zero overhead system which has
probability overwhelmingly on its side, and you're complaining about
pipeline and cache flushing issues in my pedagogical code ? Please
guys, lets talk about orders of magnitude here ...

Yes, the event system synchronizes everything, but it synchronizes a
bunch of stuff that we already agree is phenomenally unlikely to ever
need synchronization, at the cost of significant organizational
overhead. 

Let just go over it again: lets say that two parameters get tweaked,
each belonging to independent plugins. They are both updated, and
because of the serial nature of user-interfaces, if not the actual
CPU, this doesn't happen at exactly the same time. So its possible
that plugin-A might run with its old parameter value and plugin-B with
its new one. Right. For one control cycle's worth of data. Yes, this
*might* happen, but its incredibly unlikely, because its incredibly
unlikely that a parameter update will happen at all during the
execution of either A *or* B. So queueing up the parameter changes and
sending them to the plugins make the plugin's larger, forces them all
to potentially split their buffer processing across multiple loops,
makes plugins with large numbers of parameters more difficult to code,
and so on. All this because there is a tiny, tiny chance that you
might get plugin's executing with non-synchronized parameter
changes.

And besides, if this bothers you that much, then fine: buffer the
changes but still execute them asychronously so that plugins don't
have to do this stuff. I mean, stuff like this:

     while (first_section) {
	   process_with_first_value;
     }

     ... futz with parameter updates ...

     while (second_section) {
           process_with_second_value;
     }

is, by the standards that you're both using, incredibly inefficient
code, especially if the loop cannot be unrolled. 

Finally, I would point out that strictly speaking, if I am so damn
fast with my control system that I can get both parameter changes
effected in the way that Benno is describing, then I would argue that
its actually *correct* to have the plugins operate in the way he
described. There is still an explicit model of signal flow in all
these schemes, and if you're so lightning-fast that you can execute
one of them just after plugin-A finishes, but the second before
plugin-B runs, then you've managed to modify the signal as it passes
through plugin-B: which is the correct semantics for what your
incredible speed has let you do, because the correct semantics *are*
analog: sound is analog! but this all hogwash, because you could
almost never, ever, ever do this.

>the sample accurate event positioning, adds only a conditional buffer-split at
>the begin of the fragment processing, like David described.

 [ illustrative code elided ... ]

yes, but so does my more likely example of what the code would look
like.

>I too, was sceptical about the sample accurate event system but I'm
>now almost 100% convinced, since it doesn't seem to have conceptual
>design flaws to me.

I agree. There are no conceptual flaws with it. But it is trying to
achieve design goals that I claim are irrelevant at the expense of
others that do.

>> I think Quasimodo's system makes a lot of sense, especially for pure low
>> latency real time applications. There's no way my system will beat it WRT
>> performance in that kind of situations.
>
>Agreed, the goal is to make a framework which is flexible *AND* doesn't add
>much overhead compared to Quasimodo.

Can you tell me what is not flexible about Quasimodo's system ? I
don't understand what is being referred to here.

>To me the event overhead seems not too heavy compared to other processing
>tasks you have to do when doing DSP stuff in software.

Right, but why bother with *any* overhead, when it doesn't buy you
anything ? Quasimodo's basic system (asynchronous parameter updates)
can be used to do sample-accurate processing too, with a tiny cost in
the engine, but at the same time avoiding complexity in *every*
plugin. 

Sorry if I sound a little, uh, angry. Just a rough morning :)

--p

From - Tue Sep 28 00:32:54 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA18936
	for <slinkp@ulster.net>; Mon, 27 Sep 1999 15:16:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA07293 for linux-audio-dev-list; Mon, 27 Sep 1999 14:28:03 -0400
Received: from kaybee.org (kaybee.resnet.gatech.edu [128.61.15.250]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA07290 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Sep 1999 14:28:00 -0400
Received: from localhost (rob@localhost)
	by kaybee.org (8.8.7/8.8.7) with ESMTP id OAA10800;
	Mon, 27 Sep 1999 14:23:22 -0400
Date: Mon, 27 Sep 1999 14:23:22 -0400 (EDT)
From: rob <rob@kaybee.org>
To: David Slomin <dgslomin@CS.Princeton.EDU>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: music widgets
In-Reply-To: <Pine.GSO.4.10.9909271332380.3193-100000@ux02.CS.Princeton.EDU>
Message-ID: <Pine.LNX.4.10.9909271408100.10508-100000@kaybee.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 865d58448d68f5b9250359d7854f170c

On Mon, 27 Sep 1999, David Slomin wrote:

> My only objection is just how are you going to plug them in?  How do I
> plug a staff widget written using GTK into a host app written using Qt? In
> my analogy to shell programming, you have stdin, stdout, environment
> variables, and files as standardized methods of communication between the
> "plugins".  Just about the only means of communication I can think of
> that's standard across toolkits for widgets is the X clipboard, and even
> that's a little shaky.

assuming that everyone has the libs available for linking, QT in GTK
(or vice-versa) wouldn't be a big problem, although it would look wierd.  
the only thing necessary would be some common data conventions, and
dynamic lib hooks. there are lots of problems you could come up with, but
in general, i think such a thing would be nice to have even without a 100%
solution to all problems. again, cut and paste reuse will allow people to
cross these gaps when they like.
	

> So I prefer the bottom-up approach in general, and the
> language/platform/toolkit (Java) of the host app I'm currently writing
> (Songpad) has strong support for reusable widgets (Beans).  However, I'm
> still probably going to end up using the top-down approach because it is
> excruciatingly difficult to design a complex widget to be flexible enough
> for reuse.  Designing cripting hooks to be sufficiently flexible is also
> difficult, but not quite as bad, it seems to me.

i think that a middle path can be found, which would provide a little of
the best and worst worlds of either.  hopefully, having the widget set
will make it easy enough to design applications that there will be
several allowing the user to choose which approach most closely follows
their own, without having to give up features. 
	
----
Rob Melby
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
Internet: rob@kaybee.org, gt4255a@prism.gatech.edu

From - Tue Sep 28 00:32:57 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA30228
	for <slinkp@ulster.net>; Mon, 27 Sep 1999 16:24:52 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA07463 for linux-audio-dev-list; Mon, 27 Sep 1999 15:37:57 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA07460 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Sep 1999 15:37:54 -0400
Received: from localhost.localdomain (d212-151-87-164.swipnet.se [212.151.87.164]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id VAA04317; 
          Mon, 27 Sep 1999 21:33:22 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: rob <rob@kaybee.org>, linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: (GTK widgets for music apps)
Date: Mon, 27 Sep 1999 21:20:07 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <Pine.LNX.4.10.9909261722290.2939-100000@kaybee.org>
MIME-Version: 1.0
Message-Id: <99092721394600.00410@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id VAA04317
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id QAA30228
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 178ae2c06942bc1a925bc85360a13f48

On Mon, 27 Sep 1999, rob wrote:
> hey, 
> 	anyone interested in getting together a set of semi-std gtk
> widgets for music apps like say...a waveform editor, track display, staff
> display/editor, piano roll display and the like.  it would seem that some
> nice reusable componenets would make putting together apps a bit easier. 
> 	whatdya think? 
> 				rob	

Sound nice, but far from trivial. That kind of widgets would have to be very
flexible to be adopted, and flexible designs are hard to make efficient.

A basic rule: Build functionality into the *design*, not the code. Or; usable
features, rather than lots of features. Kind of the way to design hardware, as
opposed to the way way too much software is designed... Computers are *NOT*
infinitely fast, as high level language folks seem to think. *hehe*

Anyway, I've thought about that kind of stuff before, and I'm probably not
alone, so feel free to describe your ideas on the list - I'm sure you can get
some useful feedback. :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Sep 28 00:33:01 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA07288
	for <slinkp@ulster.net>; Mon, 27 Sep 1999 17:20:55 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA07565 for linux-audio-dev-list; Mon, 27 Sep 1999 16:21:40 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA07560 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Sep 1999 16:21:27 -0400
Received: from localhost.localdomain (dialup57-1-28.swipnet.se [130.244.57.28]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id WAA17811; 
          Mon, 27 Sep 1999 22:16:46 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Benno Senoner <sbenno@gardena.net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: Fullduplex audio client/server implementation
Date: Mon, 27 Sep 1999 22:15:13 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: audiality@swipnet.se, Paul Barton-Davis <pbd@Op.Net>
References: <99092712305000.00540@goblin.flashnet.it>
MIME-Version: 1.0
Message-Id: <99092722231002.00410@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id WAA17811
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id RAA07288
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: acfc6819b26ddec5805dfac6afaa5ff5

On Mon, 27 Sep 1999, Benno Senoner wrote:
> SERVER:
> -------
> while(1)
> {
>   read() from /dev/dsp  to a shared mem input buffer
>   for(i=0;i<NUM_CLIENTS;i++)
>   {
>     if(client[i]->shmem.ready)    // when client is ready it sets the ready flag
> in the shmem buffer
>      {
>        read audiodata from client i via shmem
>        mix audiodata ( client[i].shmem.oubuf ) to output buffer  
>     }
>   }
>   write() output buffer to /dev/dsp
>   for(i=0;i<NUM_CLIENTS;i++)
>   {
>     client[i]->shmem.ready=0;
>     wakeup client i  (through a semaphore or message)
>   }
> }  
> -----
> 
> CLIENT:
> ----
> clear client's audio output buffer
> shmem.ready=1;
> wait for wakeup from server ( through msgrcv() or a semaphore)
> while(1)
> {
>   do DSP computations using as input buffer the server's shared audio input
> buffer
>   write results to shmem.outbuf
>   shmem.ready=1;
>   wait for wakeup from server
> }
> ------

Looks nice to me, unless I've missed something... :-)

However, how about extending shmem.ready to a queue system? That is, you set up
a couple of buffers in shared memory, and instead of telling the engine that
you have one ready for output, you tell the egine which buffer is the last one
ready for playback.

In order to be useful, this scheme should allow that the application takes
back buffers that aren't already in the process of being mixed, so that you can
mix ahead, and then change your mind and add some extra sounds to your buffers
if something "unexpected" happens.

Target: Games sound engines and soft synths running under non-RT scheduling.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Sep 28 00:33:02 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA08419
	for <slinkp@ulster.net>; Mon, 27 Sep 1999 17:27:01 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA07667 for linux-audio-dev-list; Mon, 27 Sep 1999 16:41:54 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA07664 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Sep 1999 16:41:50 -0400
Received: from localhost.localdomain (dialup57-1-28.swipnet.se [130.244.57.28]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id WAA01701; 
          Mon, 27 Sep 1999 22:37:12 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: David Slomin <dgslomin@CS.Princeton.EDU>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] AES report
Date: Mon, 27 Sep 1999 22:29:09 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <Pine.GSO.4.10.9909262120300.15690-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Message-Id: <99092722433603.00410@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id WAA01701
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id RAA08419
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3642ef94730d054197f146f0b4fd7144

On Mon, 27 Sep 1999, David Slomin wrote:
> On Sun, 26 Sep 1999, David Olofson wrote:
> 
> > Buttons and dials vs. GUIs is like keyboard shortcuts vs. drop-down menues.
> > That is, unless frequently used functions map directly to the keys on the
> > standard keyboard (no qualifier crap), custom hardware is needed.
> 
> Agreed, but you don't really need 200 physical dials to control 200
> different parameters (I certainly don't have enough fingers and toes to
> control them all at once even if I could visualize it).  You can write a
> small program that remaps the few physical knobs on your synth keyboard to
> arbitrary controllers.

That's not really what I had in mind... What I meant is very carefully designed
physical user interfaces, like a jog wheel with the transport buttons located
just where you want them - not a matrix of generic controller knobs.

> There's no reason that you couldn't remap program (patch) change events
> into "remap mod wheel to continuous controller foo" events.  Then you're
> only using two physical controls, but have access to 128 virtual ones,
> with nary a GUI in sight.

Indeed, and that's kind of how I use the MIDI keyboard controller. The
computer decides where to send the events. Only a different kind of input
device.

> With your concentration on realtime precision, you were probably too
> disgusted with my "good-enough" attitude on latency to try my MIDI toys
> when I posted them a while back, but a few of them do exactly what I'm
> describing, if you're interested.

There's a huge difference between audio and MIDI... And there's a lot of
interesting software I'd like to play with, but I got to work, and I'm trying
to get some useful contribution to the plug-in API together. I'm also trying to
hack a Driver Programming Interface for Linux/RTLinux, and I'm about to write
an article on the Audiality concept... And the Audiality site needs to be
rebuilt. Sorry if I don't seem to pay attention at times...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Sep 28 00:33:05 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA11917
	for <slinkp@ulster.net>; Mon, 27 Sep 1999 17:47:15 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA07728 for linux-audio-dev-list; Mon, 27 Sep 1999 16:59:04 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA07725 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Sep 1999 16:58:57 -0400
Received: from localhost.localdomain (dialup57-1-28.swipnet.se [130.244.57.28]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id WAA01048; 
          Mon, 27 Sep 1999 22:54:23 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] AES report
Date: Mon, 27 Sep 1999 22:53:21 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199909270213.WAA25486@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99092723004804.00410@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id WAA01048
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id RAA11917
Status: U
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 646949a361518f5c94a3ae77854bfbd8

On Mon, 27 Sep 1999, Paul Barton-Davis wrote:
[...]
> >There's no reason that you couldn't remap program (patch) change events
> >into "remap mod wheel to continuous controller foo" events.  Then you're
> >only using two physical controls, but have access to 128 virtual ones,
> >with nary a GUI in sight.
> 
> Although I personally agree, I would say from watching people's
> response to "proper" physical interface design at AES that people who
> work with this stuff all day don't like that kind of approach. 

I hardly work all day with music, but I can certainly see why mapping physical
controllers around isn't popular. I just *hate* that extra level of complexity
in the UI, and the extra steps to reach the function you want to tweak is very
annoying in the long run. It's ok for playing a little with a machine, but even
programming a synth using 4 dials and a set of buttons becomes irritating after
a while. Not to mention the JV-1080 with ONE wheel... (I like the
push-for-high-speed function of that wheel, though.) When I know all the
parameters of a machine, I want to be able to just change the one I want
directly, without having to locate it in some menu or something first.

But that's me... I don't like tweaking - I want the sound I hear in my mind -
before I forget it.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Sep 28 00:33:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA27874
	for <slinkp@ulster.net>; Mon, 27 Sep 1999 19:09:41 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA08039 for linux-audio-dev-list; Mon, 27 Sep 1999 18:41:23 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA08033 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Sep 1999 18:41:10 -0400
Received: from localhost.localdomain (dialup57-1-28.swipnet.se [130.244.57.28]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA22217; 
          Tue, 28 Sep 1999 00:36:24 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Date: Mon, 27 Sep 1999 23:01:33 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199909270259.WAA28109@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99092800424805.00410@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id AAA22217
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA27874
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 8521eaa2975d0c15c65bc5825962d260

On Mon, 27 Sep 1999, Paul Barton-Davis wrote:
> >An RTL driver can easily catch events and time them within 5 usecs or so on an
> >average Celeron box. The hardware can be more troublesome...
> 
> regular Linux can do the same thing - remember, RTL doesn't improve
> the latency of an ISR (sti/cli excepted). 
                         ^^^^^^^^^^^^^^^^
                         That's *exactly* the point with RTL.
As an RT/control kind of guy, I'm not very interested in the average case...
But yes, if the jitter of standard Linux IRQs isn't a problem, you're right.
(IRQs are not preemptive on x86 hardware, unless you make them so by
reenabling the interrupts in the start of the handlers...)

> >> thats still a lot
> >> of samples that may or may not have been generated so far by any given
> >> plugin. The timestamp will be accurate, but there is no way to sync it
> >> to the sample generation process.
> >
> >If you know the offset between the time base of the event and the time base of
> >the output device, there's no problem.
> 
> sure, but there is no fixed offset if its measured with sample
> resolution. you simply don't know the difference at any particular
> point in time.

Why not?

RDTSC gives you the absolute time right now, and an IRQ from a sound card tells
you that the card just reached a known state - usually that it has
played/recorded the requested number of fragments, and is going to need a new
buffer after the current fragment has been played/filled. The sample frequency
can be considered as known to be what you requested, or you can measure the
exact rate compared to the CPU clock (if you're using RDTC) if you really don't
trust the sound card. (Pointless, as you'll never see an error bigger than a
fraction of a % of a sample even with a rather crappy card, with normal real
time audio buffer sizes.)

Now, if you get the current time at *any* time, you can just check the latest
buffer timestamp from the driver, and calculate what sample is playing right
now. (Or calculate whatever you want to know, like the offset between two
cards - in samples or whatever...)

> >> The best you can do is sync it to
> >> the state of the DAC, as understood by the engine, which is well known
> >> immediately after a write to the DAC has returned, but not known at
> >> any other time.
> >
> >True. With OSS and ALSA (currently, at least). What about an IOCTL that gives
> >you the exact time of the next sample you'll get if you do a read()?
> 
> ALSA provides an ioctl that does something fairly close to this, so it
> wouldn't be hard to fix i think. but this still won't give you sample
> accuracy unless you read the data from the driver in single samples.
> 
> Consider the following scenario:
> 
> 	 * engine has just finished a control cycle, and has
> 	   returned from sending data to the output interface (DAC,
> 	   ADAT, whatever). We assume that it blocks until space
> 	   is available there, assuring us that we are synced with
> 	   the output stream.
> 
> 	 * engine grabs a control-cycle's worth of input samples
> 	   to make them available for the next cycle of plugin
> 	   execution.
> 
> 	 * engine starts plugin cycle. 
> 
> 	 * interrupt occurs from some external h/w source (not audio). its
> 	   timestamped, preferably by the driver, but possibly in user
> 	   space, and the event it represents becomes available for
> 	   use by the engine. 
> 
> 	 * the engine finishes the plugin cycle, and sends the data
> 	   to the output interface. 
> 
> 	 * the engine gets the cycle's worth of input data.
> 
> 	 * it starts the next plugin cycle, queueing the event in the
> 	   plugins' event buffers.
> 
> OK, so how is that event supposed to have sample accurate sound ? All
> we know at that point that the event occurs is that a control cycle
> has started.

Why are you forgetting that you can calculate the exact play time of every
single sample of the buffer you're about to generate? The sound driver just
told you when the first sample of the next buffer will be played (or similar
information), right? (I'm assume we're dealing with *real* multimedia drivers
and an API to handle them, of course. ALSA will probably do this, if it doesn't
already.)

> We have no idea how far along we are, because we could be
> in the middle of any given plugin, or the beginning or the end, or in
> between them. We could estimate how long the cycle will take, based on
> previous cycles with the same net, and then judge from that, but this
> is not going to provide sample accuracy. 

With a timestamped event system, it doesn't matter where in the cycle you are.
It's actually a system that could run off-line just as well, using events from
a sequencer.

> The best I can see is to use the ioctl call to determine the current
> time as far as the *output* interface is concerned. You can't use the
> *input* interface, because it will give a time based on the samples
> you've already read, rounding its accuracy to the buffer size.

Nope. Just ask the input and output cards about the start time (or whatever) of
each buffer, and you have the exact offset between them. That is, the offset
you need to translate the event timing accurately. (You don't have to do this
very frequently BTW, unless the cards have unstable oscillators...)

> But this implies that timestamping happens in user space, because
> otherwise its a cross driver call, which may not be a very good idea
> from an ISR context. If its in user space, I don't think that the
> timing will be better than 0.5ms, and even that is with the user
> thread running SCHED_FIFO, and presumably not the engine thread - bad
> news on a UP box ...

You shouldn't have to deal with this with sync capable drivers. All you need is
a way to get audio data timestamped using a global clock. The CPU clock should
do, I think.

> >> What *are* the events that might tell a plugin to "do something" ? 
> >> 
> >> The class of events that I imagine to have important time properties
> >> are those that reconfigure the processing net. Turning on a
> >> plugin. Turning it off. Not much else.
> >> 
> >> When someone tweaks a MIDI CC, I expect the effect to take place right
> >> *now*. When someone twiddles an on-screen control element, I expect
> >> the effect to take place right *now*. I don't see where a notion of
> >> "when to do things" enters into the area of parameter updates.
> >
> >Automation. Live systems are obviously *very* different from studio systems...
> >:-)
> 
> Nope. The automation I've seen in ProTools, Logic, the Pulsar and
> others tells something when to change a parameter. It doesn't tell a
> plugin to *do* anything.

About the same way VST does it (although it uses callbacks to change
parameters)... but not for VST 2.0 soft synths. They use a timed event system
similar to my design.

Anyway, "when to do things"... Simple answer: Do <parameter change> at sample
<sample> in this buffer makes a lot of sense to me, as it means you get
automation resolution that's completely independent of the buffer size. Ruining
things like a compressor side chain gating another track just because you want
to save some CPU by using bigger buffers when mixing down isn't a very goo
idea, it is? And you certainly need small buffers to get decent resolution in
the first place...

> >> I consider a plugin to be a little piece of code that generates
> >> samples according to an algorithm and the state of its parameters. It
> >> doesn't change what it does unless you (1) change the algorithm, which
> >> is nonsensical - the plugin *is* the algorithm (+) or (2) change the
> >> parameters. The parameters can be updated in real time. So I can't see
> >> what kind of effects you might be talking about.
> 
> >The audio clip player of a hard disk recording engine. It's actually
> >*required* to work with at least sample accuracy.
> 
> thats a different issue. we're talking about events that alter the
> behaviour of the plugin. perhaps i'm missing something here.

audio clip player == sampleplayer

Or; someone will have to make sure the audio clips get mixed in at the exact
sample positions they're supposed to - and I intend to allow plug-ins to do
this kind of work, controlled through the event system.

> >Plug-ins that are modulated from envelope generators in a soft synth
> >or sampleplayer. These need to stay in sync with the audio data they
> >process,
> 
> are you talking about envelope generators that are part of the same
> system ? once again, these just do parameter updates - they do not
> change the code that a plugin executes.

What's the difference? You still need to make sure the "update" takes place at
the right position in the buffer - which is impossible to do without some form
of timestamping, at least in the environments we're dealing with.

> >2) An any machine (UP or SMP), this plug-in may execute within a
> >   fraction of the time it takes to play the buffer it's changing.
> >   That is, the time at which the plug-in recieves the event, and
> >   acts upon it has a very unlinear relation to the buffer time.
> 
> Right this is a point you've made before. I accept it, and I'm not
> trying to get around it. But my point is that the example shows how
> async parameter updates remove any need for events or timestamps for
> the most common class of events. Whether or not they actually occur
> asynchronously with plugin execution is a side-effect, and mostly
> irrelevant. 

I don't think so. How would you make sure an automation system repeats the
*exact* same control sequence that you just recorded? (I think that's the most
obvious scenario for making the difference obvious.)

Oh, well, perhaps the discussion below the code example will make more sense.

> 
>  [ ... code criticism elided ... ]
> 
> OK, OK. I didn't mean this as a piece of production code, just psuedo
> code for pedagogical purposes. If I have to write it reasonably
> efficiently, it would look something like this:
> 
> process (MyClosureType *closure)
> {
> 	unsigned int nframes = control_cycle_frames;
> 
> 	switch (*closure->switch_state) {
> 	case 1:
> 		while (--nframes) {
> 			... foo ...
> 		};
> 		break;
> 	case 2:
> 		while (--nframes) {
> 			... bar ...
> 		};
> 		break;
> 	.
>         .
>         .
>         }
> }

Yes, that looks a lot better. :-)

However, now, it will ignore asynchrounous changes of switch_state while
processing... Which means that if a change occurs just before the call to
process(), it'll take effect starting with buffer[now], while the external
event casuing the change coming in just a little later, will make it take
effect starting with buffer[now+1].

With timestamped events, the external event will be timestamped, the
timestamp will be converted to the sample time base of the plug-in, and the
process() function will get an event that tells it to perform the change at an
exact place in the buffer. What you get is a chance to replace one cycle of
jitter with one cycle of constant delay. (In the ideal case; add enough delay
to make sure the system's scheduling jitter doesn't cause events to arrive one
buffer too late every now and then.)

> >> But there aren't very many events that do that ... Most
> >> of them are just parameter updates. These don't change what the plugin
> >> "does" in the sense that it needs to be told about it. They may well
> >> change the output of the plugin, but it doesn't have to care about
> >> that :)
> 
> >MIDI events? I'd say they change things pretty much in soft
> >synth... (Note: I'm not thinking about soft synths built from lots of
> >small plug-ins here. This is raw, optimized code for generating N
> >voices.)
> 
> ah, thats what I mean by having a different idea of what a plugin
> should be.  

Yep, I though so!

> i don't want to use such a piece of code - its just doesn't do what i
> want, which is to be modular, flexible, reusable and extensible. ok,
> so you gain a few percent speed by coding it that way, but by next
> year, we'll be back to square one on that count as long as N stays the
> same (which I'd argue it basically does). 
> 
> every time i want to rip out the oscillator algorithm, it means
> recompiling the plugin. every time i decide i want to alter the filter
> design, it means more code, possible slowdowns if I want to be able to
> select different filters at runtime, etc. for me, the whole attraction of
> "plugins" is that they avoid this kind of thing.

very good point...

> so, yes, in the case you describe, MIDI events would be significant,
> since they may fundamentally alter what the plugin does. but in a
> system where all a MIDI note does is to insert a new copy of the
> plugin into the processing net, there is no reason to communicate such
> events to plugins at all.

...but I don't fully agree that it's that black and white. Just because
proprietary soft synths often work like you describe, there's no requirement to
do it that way. (It the event system gets *that* expensive, I'd better scratch
it and start over...) On the contrary, I intend to use very small plug-ins as
synth modules.

The *point* is that, as long as I don't require feed-back with a shorter delay
than the cycle time, there's no need to decrease the buffer size to get
acceptable resolution of the control. One plug-in could route MIDI style events
forward to oscillators, envelope generators, VCOs etc, without limiting the
resolution to the buffer size.

And, just to point out an important difference between our systems; my system
normally doesn't remove and insert plug-ins at all as a response to a real
time events. (The engine will temporarily disable silent plug-ins if they're
smart enough to notify the engine about their state, but that's not quite the
same thing.)

Note that the same rules apply to event buffers as to audio buffers - plug-ins
that aren't sending events to other plug-ins the "wrong way" (ie cause
feedback loops) can send events to other plug-ins that will be called later on
during the cycle. The net builder keeps track of this, just at it does for the
audio data flow.

That means that one plug-ins can send an event to a plug-ins farther down the
processing net, and tell it to change some parameter *at the exact same sample*
as an event it recieved itself.

> [ just a note on something related to this: polyphonic plugins are one
>   area of quasimodo where things don't feel quite right. because there
>   is only one copy of the output buffer for the plugin, each "voice" (an
>   instance of the plugin within the current DSP program/net) has to
>   cooperate a little bit to avoid trashing the current contents of the
>   buffer. This is easily accomplished: the plugin uses a special DSP
>   instruction that resets the output buffer(s) once per control cycle
>   regardless of the number of voices, and the plugin uses "+=" instead
>   of "=" when assigning values to the output buffer, so that we end up
>   with the summed output of all the voices, not just the output of the
>   last voice to run.
> 
>   even so, it bothers me.
> ]

This is one part of signal processing that seems to quite often result in
not-so-sexy solutions... VST does it by using two versions of process(); one
that overwrites (to avoid the clear operation - pays off when you're dealing
with insert effects that only output to the next insert effect in the line),
and one that adds to the output buffer. I'll use a similar system, where the
very inflexible mixing process() call is replaced with process_mix(), that is
required to feature a standard output gain control. That means you can build a
virtual mixer without using extra plug-ins for send levels, gain and so on.

> i don't think that our aims for Audiality and Quasimodo really differ
> at all. my purpose in discussing all this has been to try to see if I
> am not noticing something that would prevent Quasimodo from evolving
> into exactly the kind of system we are both talking about. I mean, as
> far as offline processing goes, Quasimodo already handles Csound
> scores, which in many cases can never be handled in real-time. You
> just turn on Quasimodo's "tape" interface, shutdown the DAC, and let
> it run. By morning, your 512-piece orchestra, which individual reverb
> for each instrument, should have finished playing "Happy Birthday" or
> its equivalent in Sweden :)

Certainly, our aims are very similar. However, I think there is a little
difference in the perspectives. The event system/direct access discussion isn't
much more than a matter of me being very careful about getting the best
possible accuracy at an acceptable cost. (And I'm known to have very high
demands - even if it nearly kills me sometimes...)

There are more important (possible) difference though.

First, I'm not quite happy with "If it sounds good, it *is* good" in this case
- future developments may render systems built after that motto obsolete,
especially in the case with digital systems. (As in: "Analog distortion is
useful, while digital distortion just sucks." Applies to other digital specific
problems as well.)

Second, I don't think separating audio, video and other data formats into
completely different worlds is a good thing in the long run. That's why I want
a powerful, high resolution event system, and support for dynamic buffer sizes.
It's also the reason why I *don't* want audio specific stuff in the low level
details of the API. It should be generic, like a real time round-robin RT
scheduler with IPC functionality optimised for high bandwidths and high
accuracy real time communication. As a system based on cycles and timestamped
events can be run without the time base being real time, the off-line
processing capabilities come as a (virtually) free bonus.

Finally, I'm just about crazy enough to believe this is actually possible to
achieve. ;-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Sep 28 00:33:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA08563
	for <slinkp@ulster.net>; Mon, 27 Sep 1999 17:27:43 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA07655 for linux-audio-dev-list; Mon, 27 Sep 1999 16:39:08 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA07651 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Sep 1999 16:39:04 -0400
Received: from someip.ppp.op.net (d-bm3-04.ppp.op.net [209.152.194.68]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id QAA15419 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Sep 1999 16:34:29 -0400 (EDT)
Message-Id: <199909272034.QAA15419@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: music widgets 
In-reply-to: Your message of "Mon, 27 Sep 1999 14:23:22 EDT."
             <Pine.LNX.4.10.9909271408100.10508-100000@kaybee.org> 
Date: Mon, 27 Sep 1999 17:30:08 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 9d1726f4c910c3181ca12efdf1d9223a

I think that the usefulness depends on what you want to do.

First of all, I am strongly for the separation of UI and actual
functionality. But I work in C++, which makes it pretty trivial to do
this. In C, its not quite so straightforward, and often involves some
ugly looking syntax.

Even so, I would strongly suggest that anyone thinking about this pays
more attention to the functional hooks you want dangling from the
widgets than their visual appearance. That enables different visual
incarnations of the same functional widget to be created. That is:
define the functionality presented by the widget's API, and then allow
creativity to roam freely on the visual appearance. 

I would be very happy if some of these things came to be - I need some
self-contained widgets for extending Quasimodo's visual elements. a
GTK widget for waveform editing would be awesome, even if it couldn't
do everything that ProTools can :)

But OTOH, there I am, looking through Dave Philip's Audio+MIDI
page(s), noting things like Audiotechque and others that were all
"design" driven. Code first, redesign later ...

--p

From - Tue Sep 28 00:33:07 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA26767
	for <slinkp@ulster.net>; Mon, 27 Sep 1999 19:03:41 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA08022 for linux-audio-dev-list; Mon, 27 Sep 1999 18:30:24 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA08019 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Sep 1999 18:30:21 -0400
Received: from someip.ppp.op.net (d-bm3-04.ppp.op.net [209.152.194.68]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id QAA17501 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Sep 1999 16:53:34 -0400 (EDT)
Message-Id: <199909272053.QAA17501@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: 
In-reply-to: Your message of "Mon, 27 Sep 1999 11:57:06 EDT."
             <37EF93D2.8A0555DC@cygnus.com> 
Date: Mon, 27 Sep 1999 17:49:14 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b20506954117fb5d23a9ab47ac5548be

>- Dial widget: With some nice bitmaps of real knobs.

I have a bunch of these for Gtk--, but not for GTK+. In particular, I
have:

	MotionFeedback - a widget which cycles through a set of
	                 pixmaps to reflect various kinds of mouse
			 motion and/or keyboard input. By changing the
	                 pixmap sets, you can get totally different 
			 visual appearances - for instance, there is
	                 no difference between a fader and a knob
	                 except the set of pixmaps that they both use.
        
	MidiControllable - a virtual object which can be hooked up
	                   to incoming MIDI signals from my libmidi classes.

>- Transient generator editor widget (variant of the gtk curve widget): Allows
>one to draw a curve repesenting things like attack, decay, release, etc.

i have such a beast for GTK+. Its a variant of the gtk curve widget. I
can't remember right now what it does, but I use it for the Enveloper
visual element in gtk-quasimodo. It allows up to 6 set points.

>- Abstract connection widget: Some abstraction of the canvas widget that
> would allow programmers to describe inputs and outputs of modules and
> allow the user to make connections between them. 

But the canvas widget isn't part of GTK+ ... please don't make us use
GNOME :) I don't how close the versions of these things in Quasimodo
are to what you mean, but they might be good places to start. I have a
Gtk_Ellipsoid widget for Gtk--, which draw dangling patch cords
between two points. It uses my own mini-canvas GTK+ widget,
GtkTransparency, which allows for multiple draws/erases in the same
area and is more efficient (though not as flexible) as the GnomeCanvas.

If anyone wants to look at any of this stuff, its in the src
distribution at http://www.op.net/~pbd/quasimodo/

--p

From - Tue Sep 28 00:33:18 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA14990
	for <slinkp@ulster.net>; Mon, 27 Sep 1999 21:04:33 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA08248 for linux-audio-dev-list; Mon, 27 Sep 1999 20:34:19 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA08244 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Sep 1999 20:34:15 -0400
Received: from localhost.localdomain (d212-151-40-59.swipnet.se [212.151.40.59]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA07712; 
          Tue, 28 Sep 1999 02:29:28 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Benno Senoner <sbenno@gardena.net>, Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Date: Tue, 28 Sep 1999 00:43:50 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <99092715560501.00540@goblin.flashnet.it>
MIME-Version: 1.0
Message-Id: <99092801153706.00410@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id CAA07712
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA14990
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 978fd4b2053db1e405b240a86671af64

On Mon, 27 Sep 1999, Benno Senoner wrote:
> On Sun, 26 Sep 1999, David Olofson wrote:
> > 
> > An RTL driver can easily catch events and time them within 5 s or so on an
> > average Celeron box. The hardware can be more troublesome...
> 
> Yes, but audiality will run as a userspace process on most systems,
> therefore we should include a solution optimized for that case:
> ignore (do not generate/process) timestamps for realtime data,
> like MIDI input.

Actually, it doesn't matter in what context the engine runs, as long as the
drivers can provide correct timing info for audio data. But yes, if an API
for this is not available, or the user doesn't consider this extra resolution
useful, we can just clear all timestamps so that plug-ins will handle all
events before they start processing. (Plug-ins don't need to be aware of this
possibility.)

> For realtime MIDI input we have to live with the scheduling jitter, but since
> it is below/within the MIDI byte transfer time, we are better/as good as
> hardware counterparts.

Yep. And if anyone believes there's more info to get from a MIDI port, there's
always RTL, and the "timestamped MIDI events" solution. However, as most MIDI
controler devices have a scan rate that won't even allow ms accuracy, I guess
it's pretty pointless...

[...]
> Not to mention weird things like plugin-B getting the new parameter change,
> while plugin-A was already processed and generated data with the old parameter
> settings
> = unwanted "analog feel" ??
> :-)

<mode tool="chainsaw" >:-> >
Hmm... I didn't even think about events being sent to multiple plug-ins.
Indeed, that would break the attack of the analog bass drum, that uses two
envelope controlled resonant filters in parallel to get the right punch.
Believe me, I've seen (uhm, heard) this, and I won't have it again... (BTW,
samplers are *samplers* - not workaround solutions. Imagine more dynamic sounds
than a simple bass drum...)
</mode>

[...]
> Of the above example doesn't cover the "more than 1 event per fragment" case
> but it's almost trivial to implement, without adding much overhead.
> (can be implemented by wrapping the above code fragment
around a > while(--num_events_in_this_fragment) { ... }  or so)
> Right David ?

Yes, you can do it as I did in some previous example - with an outer loop
decoding events. The only difference would be that with the new
timestamp-per-event system, you'll get an extra check for samples_to_process==0
(the inner loop not doing anything, that is) for each extra event on the same
time stamp.

> I too, was sceptical about the sample accurate event system but I'm
> now almost 100% convinced, since it doesn't seem to have conceptual
> design flaws to me.

Nice! I hope you're right... :-)

> Of course the sample accurate event processing will slow down very much,
> if you send a huge number of events per fragment, but that's another story,
> and we assume that it will not happen in real world.

The input data interfaces (plug-ins, as I would like to do it) and more
importantly, the sequencer, should make sure to send sensible ammounts of
events. Same thing as with MIDI sequencers. A maxed out MIDI port is rather
useles...

> For oscillator modulations we will use low frequency wavetables, instead
> of sending myriads of events, stressing the David's poor memory management
> system.   
> :-)

Exactly. I'll hardly manage to get it *that* efficient... And, "parsing" a
control signal buffer will always be the most efficient way it can possibly be
done. It can even be optimized into SIMD code without reducing the timing
accuracy.

[...]
> > My goal is to design and implement a system that can cover the whole range
> > from ultra low latency real time to off-line processing - without ending up as
> > something that doesn't do anything too well... (Simple, eh? ;-) The low overhead
> > system of Quasimodo is very inspiring when trying to turn an inherently complex
> > design into something nice, efficient and useful. Remains to see what all this
> > results in...
> 
> To me the event overhead seems not too heavy compared to other processing
> tasks you have to do when doing DSP stuff in software.

Yes, and with the high quality resampling discussion in mind, we're hardly
expecting *less* expensive DSP code in future systems, are we? Remember the
days when you had to code even the control system of a game in optimised asm
code not to slow the whole game down significantly? Nowadays, even the rendering
code of the 3D engine is mostly C or C++... And it doesn't make much difference
trying to optimize it.

I still think fast code rocks, of course. (Hey, I used to be an asm die-hard...
:-) The Linux kernel is a good place to look for fast code that's still possible
to understand, reuse and improve.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Sep 28 00:33:20 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA15209
	for <slinkp@ulster.net>; Mon, 27 Sep 1999 21:05:41 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA08242 for linux-audio-dev-list; Mon, 27 Sep 1999 20:34:12 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA08239 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Sep 1999 20:34:08 -0400
Received: from localhost.localdomain (d212-151-40-59.swipnet.se [212.151.40.59]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA07743; 
          Tue, 28 Sep 1999 02:29:31 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: thudson@cygnus.com, rob <rob@kaybee.org>
Subject: Re: [linux-audio-dev] Re:
Date: Tue, 28 Sep 1999 01:17:00 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <37EF93D2.8A0555DC@cygnus.com>
MIME-Version: 1.0
Message-Id: <99092801263107.00410@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id CAA07743
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA15209
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1438b0a18bd021cf33dcce8c1d4457d1

On Mon, 27 Sep 1999, thudson@cygnus.com wrote:
> Of course, it might be worthwile to go beyond just gui elements. I've
> been toying with a System Exclusive Editor/Librarian toolkit. The other
> idea I have is something similar to OMS, that would discover (allow a 
> user to describe) a midi setup, so that midi apps could specify connections
> to real midi (or software) devices rather than "/dev/midi0." 

Hmm... I think that kind of functionality should go into a central system
service - not into applications or even toolkits. What I mean is, SysEx
interfaces, MIDI mappers and that kind of things should be realized as plug-ins
of some kind.

One part of the logic behind this lies in the design I'm working on for
Audiality. As I intend to use a generic event system - much more powerful than
MIDI - throughout the system, MIDI data on the application level would only
result in added complexity. Interface plug-ins will handle the translation
from/to MIDI events, and they could also provide a basic SysEx interface, so
that a special librarian client can request, record and send raw MIDI SysEx
data. (Actually, SysEx can be sent through my proposed event system, so there
are many ways to do it.)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Sep 28 00:33:14 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA14947
	for <slinkp@ulster.net>; Mon, 27 Sep 1999 21:04:21 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA08252 for linux-audio-dev-list; Mon, 27 Sep 1999 20:34:30 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA08249 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Sep 1999 20:34:19 -0400
Received: from localhost.localdomain (d212-151-40-59.swipnet.se [212.151.40.59]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA07765; 
          Tue, 28 Sep 1999 02:29:33 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Date: Tue, 28 Sep 1999 01:42:12 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199909271718.NAA22374@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99092802354608.00410@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id CAA07765
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA14947
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ff65014e8969d5c391f2a868a30dbfcd

On Mon, 27 Sep 1999, Paul Barton-Davis wrote:
[...]
> David's event-based system instead delays the parameter change by up
> to 1 control cycle in the interest of synchronization. But then he
> points out that its extremely unlikely that any given parameter change
> will arrive *during* the execution of any particular plugin, and we
> all agree on that, with the exception of running a CPU-intensive
> single plugin, which we also agree on.

I think you missed the point... No, a parameter change will not *arrive* to the
plug-in during it's execution, or even during the whole engine cycle. But
external events that will result in parameter changes *will* be recieved and
time stamped by hardware or drivers all the time. These event will be fed to the
engine at the start of the next cycle, and as the timestamps are there, there
can be no doubt about when changes should take effect. The cycle time related
jitter is eliminated, as every plug-in knows exactly when to process the events
in the buffers they recieved.

This is how lots of industrial control systems work. Jitter in the input/output
data timing is *dangerous* and is among the worst problems you can have,
especially with PID regulators and the like. It may not be that critical in
audio systems, but I certainly don't want my MIDI events quantisized to the
current cycle time of the engine. My event system takes care of that by keeping
track of time without getting the engine's scheduling timing in between.

> So, here I am, presenting a close-to-zero overhead system which has
> probability overwhelmingly on its side, and you're complaining about
> pipeline and cache flushing issues in my pedagogical code ? Please
> guys, lets talk about orders of magnitude here ...
> 
> Yes, the event system synchronizes everything, but it synchronizes a
> bunch of stuff that we already agree is phenomenally unlikely to ever
> need synchronization, at the cost of significant organizational
> overhead. 

Not quite. I wasn't only talking about *synchronization* of events. The big
point is preservingng the timing precision of input data. That is, the
engine's cycle time shouldn't be able reduce the quality of the input data used
to control it, to use control engineering style terms.

> Let just go over it again: lets say that two parameters get tweaked,
> each belonging to independent plugins. They are both updated, and
> because of the serial nature of user-interfaces, if not the actual
> CPU, this doesn't happen at exactly the same time. So its possible
> that plugin-A might run with its old parameter value and plugin-B with
> its new one. Right. For one control cycle's worth of data. Yes, this
> *might* happen, but its incredibly unlikely, because its incredibly
> unlikely that a parameter update will happen at all during the
> execution of either A *or* B. So queueing up the parameter changes and
> sending them to the plugins make the plugin's larger, forces them all
> to potentially split their buffer processing across multiple loops,
> makes plugins with large numbers of parameters more difficult to code,
> and so on. All this because there is a tiny, tiny chance that you
> might get plugin's executing with non-synchronized parameter
> changes.

No. If the automation system, or the UI, runs in between the engine cycles, the
synchronization problem you're describing doesn't even exist, and I didn't even
take it into account when I started designing my system. It doesn't happen *at
all*, unless you're running on an SMP system.

The whole point with *timestamping* the events is accuracy. This sub-buffer
accuracy is *required* to separate the engine's cycle time from the timing
resolution of the audio output, which I believe is essential unless you really
can use single sample cycles without wasting most of the CPU time on nothing.

> And besides, if this bothers you that much, then fine: buffer the
> changes but still execute them asychronously so that plugins don't
> have to do this stuff. I mean, stuff like this:
> 
>      while (first_section) {
> 	   process_with_first_value;
>      }
> 
>      ... futz with parameter updates ...
> 
>      while (second_section) {
>            process_with_second_value;
>      }
> 
> is, by the standards that you're both using, incredibly inefficient
> code, especially if the loop cannot be unrolled. 

That's why it should be handled *inside" the plug-ins. Buffer splitting is far
to expensive, as is breaks any chance for plug-ins to keep things in registers
and preserve internal state information while processing a few events.

> Finally, I would point out that strictly speaking, if I am so damn
> fast with my control system that I can get both parameter changes
> effected in the way that Benno is describing, then I would argue that
> its actually *correct* to have the plugins operate in the way he
> described. There is still an explicit model of signal flow in all
> these schemes, and if you're so lightning-fast that you can execute
> one of them just after plugin-A finishes, but the second before
> plugin-B runs, then you've managed to modify the signal as it passes
> through plugin-B: which is the correct semantics for what your
> incredible speed has let you do, because the correct semantics *are*
> analog: sound is analog!

So you should actually take the plug-in execution times into account to be
correct then, even though they all operate on the same output buffer? I can't
agree there. An analog system does all processing in parallel, so as opposed to
the case with a digital system, there's no time but real time.

> but this all hogwash, because you could
> almost never, ever, ever do this.

Not quite. What's wrong with an analog automation system controlling multiple
destinations at once? Or the user sliding a few faders on his hardware
controller at the same time? I'm not going to limit myself to handling serial
UI's in a supposedly correct way.

[...]
> >I too, was sceptical about the sample accurate event system but I'm
> >now almost 100% convinced, since it doesn't seem to have conceptual
> >design flaws to me.
> 
> I agree. There are no conceptual flaws with it. But it is trying to
> achieve design goals that I claim are irrelevant at the expense of
> others that do.

Is elimination of the cycle time dependency irrelevant? Is sub 50 ms latency
relevant? Where do we draw the line...?

[...]
> >To me the event overhead seems not too heavy compared to other processing
> >tasks you have to do when doing DSP stuff in software.
> 
> Right, but why bother with *any* overhead, when it doesn't buy you
> anything ? Quasimodo's basic system (asynchronous parameter updates)
> can be used to do sample-accurate processing too, with a tiny cost in
> the engine, but at the same time avoiding complexity in *every*
> plugin. 

Good point, but I'm not so sure it holds true in real life. There's more
overhead than for an event system using inline code, and this starts to become
important as the event traffic increase. And there's a hidden problem as well:
How does the _engine_ keep track of which buffers/process() calls to split, and
for what reason? True, perhaps it can be better optimized in the engine code,
but how much better than inline code in the plug-ins? Enough to make up for the
function call overhead? Yes, I've thought about this solution before.

And keep in mind that my event system isn't meant only for UI -> DSP
communication. It'll also be used for automation and inter-plug-in
communication, as an alternative to control signals in the form of extra
"audio" channels.

> Sorry if I sound a little, uh, angry. Just a rough morning :)

That's ok. We might actually get some work done around here if we think some
more about the actual subject, and some less about trying to be nice, every now
and then. :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Sep 28 00:33:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA08844
	for <slinkp@ulster.net>; Tue, 28 Sep 1999 00:03:14 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA08580 for linux-audio-dev-list; Mon, 27 Sep 1999 23:33:12 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA08577 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Sep 1999 23:33:08 -0400
Received: from someip.ppp.op.net (d-bm2-07.ppp.op.net [209.152.194.39]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id XAA19745 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Sep 1999 23:28:37 -0400 (EDT)
Message-Id: <199909280328.XAA19745@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress? 
In-reply-to: Your message of "Mon, 27 Sep 1999 23:01:33 +0200."
             <99092800424805.00410@localhost.localdomain> 
Date: Tue, 28 Sep 1999 00:24:20 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 96abe5b7b20da3dcf4fe0e2f2370b2b7

I think, though I am not sure, that I am beginning to be convinced by
David's arguments, mostly because he has finally made clear to me what
he has in mind for measuring time (and more precisely, sample time)
accurately.

Unfortunately, I see no way to use an event system and stick to my
original design goal of code compatibility with Csound. Csound has
already provided more than 400 opcodes to Quasimodo, with another
hundred or so left to go. Were I to get enough volunteer activity to
rewrite most of the Csound opcodes to work with an event system, I
think it would be fairly easy to switch to using it (I have already
done some other, more sweeping changes than this, and they went in
very simply). But that seems unlikely. The legacy of its opcodes is
just too good to walk away from - tens of thousands of lines of useful
code, just waiting to be used.

So for now, I will stick to Quasimodo's current timestamp free,
asynchronous parameter update model. But adding an event buffer to
each closure would be simple, and so if anyone wants to start
rewriting the opcodes to use it, just let me know :)

--p

From - Tue Sep 28 01:52:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA16434
	for <slinkp@ulster.net>; Tue, 28 Sep 1999 01:39:34 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id BAA08735 for linux-audio-dev-list; Tue, 28 Sep 1999 01:17:18 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA08732 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 28 Sep 1999 01:17:15 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id BAA14598
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 28 Sep 1999 01:11:47 -0400 (EDT)
Received: from localhost by ux02 (8.9.1b+Sun) id BAA12562; Tue, 28 Sep 1999 01:11:45 -0400 (EDT)
Date: Tue, 28 Sep 1999 01:11:43 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: music widgets
In-Reply-To: <Pine.LNX.4.10.9909271408100.10508-100000@kaybee.org>
Message-ID: <Pine.GSO.4.10.9909280055360.12356-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: a3670785ab6535d7ee1256a3c0c5027b

On Mon, 27 Sep 1999, rob wrote:

> assuming that everyone has the libs available for linking, QT in GTK
> (or vice-versa) wouldn't be a big problem, although it would look wierd.  
> the only thing necessary would be some common data conventions, and
> dynamic lib hooks. 

I wonder if this has ever been done.  I agree it would look very weird
unless you "themed" things very carefully, but I'm more curious about the
technical feasibility.  Every widget set I've ever looked at (with the
possible exception of the interchangable Athena widget implementations)
uses a unique underlying programming model.  In order to do a Windows port
of NetMIDI, I just this weekend learned the native Windows GUI programming
model ("platform SDK" style), which uses rather different event
dispatching and layout models than, say, Java's AWT/Swing.  I can say from
personal experience that Tk, Wx, GTK, Qt, and even VB have their own
variations.  I'd be truly intrigued to find that arbitrary combinations
(for those toolkits available on the same windowing system) were
intermixable.

> there are lots of problems you could come up with, but
> in general, i think such a thing would be nice to have even without a 100%
> solution to all problems. again, cut and paste reuse will allow people to
> cross these gaps when they like.

I personally don't work well with cut and paste reuse.  I'm happy to make
use of a decently documented API, but I hate having to edit somebody
else's code; I usually end up trying to rewrite it before I can feel that
I properly grok it.  (Yes, editing existing code is an important part of
my day job, and I anticipate that I'll get better at it as time goes by.)
Hopefully, not everybody shares my problem...

Oh well,
Div.

From - Tue Sep 28 01:52:23 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA16354
	for <slinkp@ulster.net>; Tue, 28 Sep 1999 01:38:33 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id BAA08705 for linux-audio-dev-list; Tue, 28 Sep 1999 01:11:08 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA08702 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 28 Sep 1999 01:11:04 -0400
Received: from ulster.net (port227.ts2.ulster.net [208.242.164.227])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id BAA14017
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 28 Sep 1999 01:06:28 -0400
Message-ID: <37F04EBD.FF9330F0@ulster.net>
Date: Tue, 28 Sep 1999 01:14:37 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] AES report
References: <199909270213.WAA25486@renoir.op.net> <99092723004804.00410@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ff26f9e047144b9b9cb12af7df9984dc

Just jumping in from lurking...

David Olofson wrote:
> 
> On Mon, 27 Sep 1999, Paul Barton-Davis wrote:
> [...]
> > >There's no reason that you couldn't remap program (patch) change events
> > >into "remap mod wheel to continuous controller foo" events.  Then you're
> > >only using two physical controls, but have access to 128 virtual ones,
> > >with nary a GUI in sight.
> >
> > Although I personally agree, I would say from watching people's
> > response to "proper" physical interface design at AES that people who
> > work with this stuff all day don't like that kind of approach.
> 
> I hardly work all day with music, but I can certainly see why mapping physical
> controllers around isn't popular. I just *hate* that extra level of complexity
> in the UI, and the extra steps to reach the function you want to tweak is very
> annoying in the long run. 
(snip)

I'm put in mind of a studio where I was trying to get my foot in the
door as an apprentice engineer a few years back-- they had just bought
the then-new Yamaha ProMix 01 (I think) which was a pretty impressive
board for the price. I thought it was great until I started trying to do
something I consider essential when mixing multi-miked sources like drum
kits -- trying lots of combinations of channel phase buttons (well,
polarity buttons, but for some reason we're stuck with calling it
"phase"). On an analog board you can just punch the snare bottom mic out
of phase, then back in, then out, then try the overheads out of phase,
then try it with a room mic, etc etc... everything's bleeding into
everything else so every combination of phase switches sounds a little
different...

this was sheer agony on the Pro Mix board. To hit one phase switch you
had to select the channel and then scroll through the list of parameters
for that channel until you found "phase". At the very least they should
have given the user a way to scroll through channels in a truly
independent two-dimensional way...
so going from [channel1][parameter8] to [channel2][parameter8] is a
single action...

</rant>

--PW


 ---------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Wed Sep 29 20:34:53 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA28661
	for <slinkp@ulster.net>; Tue, 28 Sep 1999 06:08:38 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA09212 for linux-audio-dev-list; Tue, 28 Sep 1999 05:35:17 -0400
Received: from pat.bath.ac.uk (pat.bath.ac.uk [138.38.32.2]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id FAA09209 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 28 Sep 1999 05:35:13 -0400
Received: (qmail 15006 invoked from network); 28 Sep 1999 09:30:40 -0000
Received: from mary.bath.ac.uk (HELO bath.ac.uk) (mmdf@138.38.32.14)
  by pat.bath.ac.uk with SMTP; 28 Sep 1999 09:30:40 -0000
Received: from tobi.bath.ac.uk by mary.bath.ac.uk id aa13229;
          28 Sep 99 10:30 BST
Message-ID: <37F08ABF.4487@bath.ac.uk>
Date: Tue, 28 Sep 1999 10:30:39 +0100
From: "P.J.Leonard" <P.J.Leonard@bath.ac.uk>
Organization: Applied Electromagnetic Research Centre
X-Mailer: Mozilla 3.0 (X11; I; OSF1 V2.0 alpha)
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: [l Re: Plug-in API progress?
References: <99092415293900.01521@goblin.flashnet.it> <99092502060902.00438@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 289b7fac6d08a87094d1eca1a1468992

David Olofson wrote:
+
> > In short, I wat that my own process is able to get parameter-changes
> > notifications from the engine, and is allowed to send parameter-changes to any
> > plugin. (with immediate reflection on the GUI sliders, other
> > automation-recorders etc).
> 
> Yes, that's basic. That's what the client/server/plug-in architecture is all
> about in this case, IMO.
> > what about the following scenario:
> > sequencer1 continuously changes the cutoff frequency of a LP filter-plugin,
> > the GUI slider moves reflecting the changes.
> 
> Ok. Sequencer 1 somehow (directly or indirectly) sends events to both the
> filter plug-in, and the GUI element (which is in fact a plug-in as well).
> 
> > sequencer2 records the automation parameters.
> 
> It could request to become another recipient of all events sent to the filter
> plug-in. That is, another port to recieve a pointer to the same event buffer.


 There are 3 options here.

 1. server sends events to notify GUI of changes.
 2. GUI asks the server it's current state.
 3. Mixture of 1 and 2

 (1) Is conceptually more attractive but you run the risk of clogging
the system up
with event messages if you have fine grain controllers changing fast.
Here I speak from 
my own experience (I have Qt widgets for adjusting midi parameters I
also map midi controllers
onto parameters and monitor the state with the sliders). The pitch
change wheel generates
quiet a lot of events !!!)

 (2) requires the GUI to poll the server on a timer which is a bit ugly
but reduces the 
time spent doing X11 stuff. I update widgets every 1/10 of a second. You
can change
the pitch wheel from min to max in this time.


 I think any system should allow both schemes (1) and (2).

 
-- 
 Cheers Paul (P.J.Leonard)                                        

 Tel: +44 (0)1225 826108  Applied Electromagnetic Research Centre,
 Fax: +44 (0)1225 826305   University of Bath, BATH. BA2 7AY  UK

From - Wed Sep 29 20:34:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA29168
	for <slinkp@ulster.net>; Tue, 28 Sep 1999 06:17:49 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA09225 for linux-audio-dev-list; Tue, 28 Sep 1999 05:45:00 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA09222 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 28 Sep 1999 05:44:57 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46635AbPI1JkH>; Tue, 28 Sep 1999 12:40:07 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <99092501364301.00438@localhost.localdomain> (message from David
	Olofson on Sat, 25 Sep 1999 01:24:05 +0200)
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Message-Id: <19990928094007Z46635-606+180@nic.funet.fi>
Date:   Tue, 28 Sep 1999 12:40:07 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: aada1735d9fa054cfee04734fc82eb33

>From:   David Olofson <audiality@swipnet.se>
>> 
>> my pro studio friends tell me that they *rarely* (if ever) record more
>> than 16 tracks at once. keep this in mind. playback of, say 64 tracks,
>
>in? Anyway, personally, I rarely record more than 4 tracks at a time (partly

One application for really needed multitrack recording could be a recording
of a concert or a play. I guess 16 tracks is then quite minimum number
of channels.

Yours,

Juhana

From - Wed Sep 29 20:35:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA14039
	for <slinkp@ulster.net>; Tue, 28 Sep 1999 09:16:10 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA09530 for linux-audio-dev-list; Tue, 28 Sep 1999 08:46:34 -0400
Received: from pat.bath.ac.uk (pat.bath.ac.uk [138.38.32.2]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id IAA09527 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 28 Sep 1999 08:46:30 -0400
Received: (qmail 14254 invoked from network); 28 Sep 1999 12:41:57 -0000
Received: from mary.bath.ac.uk (HELO bath.ac.uk) (mmdf@138.38.32.14)
  by pat.bath.ac.uk with SMTP; 28 Sep 1999 12:41:57 -0000
Received: from tobi.bath.ac.uk by mary.bath.ac.uk id aa26593;
          28 Sep 99 13:41 BST
Message-ID: <37F0B794.52BF@bath.ac.uk>
Date: Tue, 28 Sep 1999 13:41:56 +0100
From: "P.J.Leonard" <P.J.Leonard@bath.ac.uk>
Organization: Applied Electromagnetic Research Centre
X-Mailer: Mozilla 3.0 (X11; I; OSF1 V2.0 alpha)
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: [l Re: Plug-in API progress?
References: <199909250520.BAA10873@renoir.op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3e376b3b8c95cffb3c8d0edfee3adc86

Paul Barton-Davis wrote:

> typically, parameter updates occur because of the GUI requesting
> them. therefore, under most circumstances, the GUI does not want to be
> notified of a parameter update event - it was the sender! however, if
> the parameter update was caused by something else, the GUI *does* need
> to be notified.
> 
> how to distinguish cheaply and easily between these two cases ?


 I would not bother. Conceptually the GUI has controllers and observers
(any visual component). You may have many visual components displaying
the same parameter. e.g. in my sequencer changing a note pitch is
displayed
in the event list, the score and the piano roll. It is a lot simpler to
let
the visual state be driven by the real thing. You should of course block
an update
if you are already displaying that state.




-- 
 Cheers Paul (P.J.Leonard)                                        

 Tel: +44 (0)1225 826108  Applied Electromagnetic Research Centre,
 Fax: +44 (0)1225 826305   University of Bath, BATH. BA2 7AY  UK

From - Wed Sep 29 20:35:25 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA17757
	for <slinkp@ulster.net>; Tue, 28 Sep 1999 09:39:50 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA09569 for linux-audio-dev-list; Tue, 28 Sep 1999 09:07:23 -0400
Received: from ccrma.stanford.edu (ccrma.Stanford.EDU [36.49.0.84]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA09566 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 28 Sep 1999 09:07:19 -0400
Received: from cmn14.stanford.edu (cmn14.stanford.edu [36.49.0.93])
	by ccrma.stanford.edu (8.9.3/8.9.3) with ESMTP id GAA11647
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 28 Sep 1999 06:02:46 -0700 (PDT)
Received: (from bil@localhost)
	by cmn14.stanford.edu (8.9.3/8.9.3) id GAA05145
	for linux-audio-dev@ginette.musique.umontreal.ca; Tue, 28 Sep 1999 06:02:44 -0700 (PDT)
Message-Id: <199909281302.GAA05145@cmn14.stanford.edu>
Content-Type: text/plain
MIME-Version: 1.0 (NeXT Mail 3.3 v148.2.1)
In-Reply-To: <Pine.GSO.4.10.9909280055360.12356-100000@ux02.CS.Princeton.EDU>
X-Nextstep-Mailer: Mail 3.3 [m68k] (Enhance 2.2p2)
Received: by NeXT.Mailer (1.148.2.1)
From: Bill Schottstaedt <bil@ccrma.Stanford.EDU>
Date: Tue, 28 Sep 1999 06:02:42 -0700
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: music widgets
References: <Pine.GSO.4.10.9909280055360.12356-100000@ux02.CS.Princeton.EDU>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 68bd549f7bf7bf4cb6b78dddb5a1253e

> I wonder if this has ever been done.

I've used gtk stuff in Snd which is currently Motif-based (there's
a guile-gtk module that makes it easy to do this); it does
look strange, but I think gtk has a "notif" choice.  I didn't
push it very hard, but noticed some problems, such
as the gtk dialog deciding to exit the main program -- I
expect these are easily fixable if you know both widget sets.

From - Wed Sep 29 20:35:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA25037
	for <slinkp@ulster.net>; Tue, 28 Sep 1999 10:26:12 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA09644 for linux-audio-dev-list; Tue, 28 Sep 1999 09:35:43 -0400
Received: from icemserv.folkwang.uni-essen.de (icemserv.folkwang.uni-essen.de [132.252.170.129]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA09641 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 28 Sep 1999 09:35:34 -0400
Received: from folkwang.uni-essen.de (nettings@dialup9.folkwang.uni-essen.de [132.252.170.9]) by icemserv.folkwang.uni-essen.de (8.8.8/8.7.3) with ESMTP id OAA25354 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 28 Sep 1999 14:16:19 +0200 (CEST)
Message-ID: <37F0D332.AD95609D@folkwang.uni-essen.de>
Date: Tue, 28 Sep 1999 14:39:46 +0000
From: =?iso-8859-1?Q?J=F6rn?= Nettingsmeier <nettings@folkwang.uni-essen.de>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] [Fwd: AES, Linux and BeOS] die !
References: <199909261959.PAA06216@renoir.op.net> <001101bf0867$7f11f440$b087fea9@pcbenja>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 747b1e818cf4c8dc02eaf20df1a1b7ff

dear audio enthusiasts !

i have read paul's report on aes, expecting yet another extensive
thread about linux vs. beos...
and there it is. 

all i want to add is that IMVHO we (read: the linux fans) should
promote our dear os by pointing out its advantages and features, and
*not* by repeating again and again the drawbacks and closed-source
nature of beos and other "rivals".

let customers and card manufacturers decide on their own. just show
them some user statistics. they will probably not want to miss the
linux user base anyway. if they do, theyll lose money. 

i think the only part of the linux vs. beos discussion that is
appropriate to l-a-d is:
which nifty features and concepts can we rip off to incorporate them
into linux ?

everything else belongs to c.o.l.advocacy, alt.holywars or better
yet, /dev/null.
i believe there is room for more than one os in the world.

all the best,

jrn


-- 
Jrn Nettingsmeier     
Kurfrstenstr. 49        
45138 Essen, Germany


From - Wed Sep 29 20:35:28 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA24715
	for <slinkp@ulster.net>; Tue, 28 Sep 1999 10:23:59 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA09662 for linux-audio-dev-list; Tue, 28 Sep 1999 09:40:33 -0400
Received: from icemserv.folkwang.uni-essen.de (icemserv.folkwang.uni-essen.de [132.252.170.129]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA09659 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 28 Sep 1999 09:40:23 -0400
Received: from folkwang.uni-essen.de (nettings@dialup9.folkwang.uni-essen.de [132.252.170.9]) by icemserv.folkwang.uni-essen.de (8.8.8/8.7.3) with ESMTP id OAA25387; Tue, 28 Sep 1999 14:18:59 +0200 (CEST)
Message-ID: <37F0D573.97947C31@folkwang.uni-essen.de>
Date: Tue, 28 Sep 1999 14:49:23 +0000
From: =?iso-8859-1?Q?J=F6rn?= Nettingsmeier <nettings@folkwang.uni-essen.de>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Brunel <brunel@nortelnetworks.com>,
        linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Any news from Boris Nagels / Multitrack ?
References: <37EB36A1.CFDB0332@europem01.nt.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f09760e4a15c4bc82d9486b9a7dcb73c

eric,

i dont know your setup in detail, but your kernel seems ancient
compared to the oss version.
maybe an update to 2.2.x would fix this ??

all the best,
jrn


Eric Brunel wrote:
> 
> Hi everybody,
>
> Just in case any of you know how to solve the problem, here it is: I
> downloaded a few weeks ago the latest version of the OSS driver (3.9)
> and since then, Multitrack won't record anything. 
> <...>
> Multitrack's
> version is 2.2 and my Linux is RH5.1 (kernel 2.0.35 I think...). 
-- 
Jrn Nettingsmeier     
Kurfrstenstr. 49        
45138 Essen, Germany

From - Wed Sep 29 20:35:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA04818
	for <slinkp@ulster.net>; Tue, 28 Sep 1999 11:44:13 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA09836 for linux-audio-dev-list; Tue, 28 Sep 1999 11:07:22 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA09833 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 28 Sep 1999 11:07:17 -0400
Received: (from sbenno@localhost)
	by em.gardena.net (8.9.1/8.9.0) id RAA06634;
	Tue, 28 Sep 1999 17:02:30 +0200
From: Benno Senoner <sbenno@em.gardena.net>
Message-Id: <199909281502.RAA06634@em.gardena.net>
Subject: Re: [linux-audio-dev] [Fwd: AES, Linux and BeOS] die !
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Tue, 28 Sep 1999 17:02:30 +0200 (MET DST)
Cc: pbd@Op.Net
In-Reply-To: <37F0D332.AD95609D@folkwang.uni-essen.de> from "=?iso-8859-1?Q?J=F6rn?= Nettingsmeier" at Sep 28, 99 02:39:46 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: a29c5e48fa38e51e41c7a499851bed94

> 
> dear audio enthusiasts !
> 
> 
> all i want to add is that IMVHO we (read: the linux fans) should
> promote our dear os by pointing out its advantages and features, and
> *not* by repeating again and again the drawbacks and closed-source
> nature of beos and other "rivals".

I fully agree,

Linux gained it's reputation through technical merits,
(efficiency, reliability (uptime measured in years :-) ),
speed, low cost of ownership etc.)
Linux isn't popular due to huge marketing etc.

linux-audio should be the same:
attract vendors and users because of technical advantages
like for example reliable 2.1ms audio latency on a P133.

Of course we need some promoting, because many companies
are just not aware of the real capabilities of Linux.
Paul did a very good job at the AES, even if he was not
treated as well as the BeOS guy.
:-)

But if I were a programmer at Steinberg, I would
STRONGLY try to convince my boss to perform a Cubase port
for Linux, since a VST enviroment running virtually latency free
would be the dream of most studio folks.

Paul: what were the comments at Steinberg
(or other firms interested in low-latency) when you
showed them the low-latency diagrams ?
Or were there only marketing people around ?



regards,
Benno.




From - Wed Sep 29 20:35:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA16786
	for <slinkp@ulster.net>; Tue, 28 Sep 1999 13:01:44 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA09940 for linux-audio-dev-list; Tue, 28 Sep 1999 12:03:48 -0400
Received: from www.tomy.net (www.tomy.net [209.186.149.104]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA09937 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 28 Sep 1999 12:03:40 -0400
From: thudson@cygnus.com
Received: from cygnus.com (IDENT:thudson@jimi.tomy.net [192.168.1.2])
	by www.tomy.net (8.9.3/8.9.3) with ESMTP id GAA14829;
	Tue, 28 Sep 1999 06:55:57 -0400
Message-ID: <37F0E5D9.AC4A397E@cygnus.com>
Date: Tue, 28 Sep 1999 11:59:21 -0400
Organization: Cygnus Solutions
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Barton-Davis <pbd@Op.Net>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: music widgets
References: <199909272034.QAA15419@renoir.op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 785d98fa43a1896da2b432c6d8fa50ea

Paul Barton-Davis wrote:

> Even so, I would strongly suggest that anyone thinking about this pays
> more attention to the functional hooks you want dangling from the
> widgets than their visual appearance. That enables different visual
> incarnations of the same functional widget to be created. That is:
> define the functionality presented by the widget's API, and then allow
> creativity to roam freely on the visual appearance.
> 
I totally agree with this. For example, if a standard interface exists
for plugin transient generator editing, then multiple "styles" could 
be created for editing them, and possibly be completely different
widget implementations.

I've been toying with ideas for a generic sysex editor/librarian. If
any of you are familiar w/ the current offerings on any platform, they
are pretty weak. The "look" is as generic as the functionality.
My idea is to use xml to describe editing parameters. However, the
presentation to the user would be a separate file, a "style-sheet."

There is actually a good open-source business model in this. Give
away the source and tools to make it a standard, and then sell
consulting services to synth manufacturers to have support for
their machines. Emagic does something similar (though closed-source
and proprietary) with their Soundiver product. Unfortunately (or
fortunate for their competition), Soundiver and Music Quest both
deliver a product that doesn't really distinguish the synth they
interface with.

Like pdb I tend to use C++, and thus think in terms of abstract 
interfaces. For example our transient generator editor might
look like:

class TransientGeneratorEditor
{
  public:
    setTitle(const String& title);
    setStageCount(int i);
    setTime(int index, int value);
    setLevel(int index, int value);

    // using libSigC++-style signals
    Signal2<void, int, int> levelChanged; // args: index, level
    Signal2<void, int, int> timeChanged;  // args: index, time
};

Visually I could represent this as a group box of vertical sliders,
two for each stage (time and level), or get fancy and have an
editable, graphical representation of the actual curve.

Thomas

From - Wed Sep 29 20:36:08 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA06937
	for <slinkp@ulster.net>; Tue, 28 Sep 1999 18:49:51 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA10544 for linux-audio-dev-list; Tue, 28 Sep 1999 18:27:18 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA10541 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 28 Sep 1999 18:27:14 -0400
Received: from localhost.localdomain (d212-151-85-137.swipnet.se [212.151.85.137]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA18633; 
          Wed, 29 Sep 1999 00:22:31 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Date: Tue, 28 Sep 1999 21:38:34 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199909280328.XAA19745@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99092822033000.00439@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id AAA18633
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA06937
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: cfe4d572be15d0d1b3b9705c3694c253

On Tue, 28 Sep 1999, Paul Barton-Davis wrote:
[...]
> Unfortunately, I see no way to use an event system and stick to my
> original design goal of code compatibility with Csound. Csound has
> already provided more than 400 opcodes to Quasimodo, with another
> hundred or so left to go. Were I to get enough volunteer activity to
> rewrite most of the Csound opcodes to work with an event system, I
> think it would be fairly easy to switch to using it (I have already
> done some other, more sweeping changes than this, and they went in
> very simply). But that seems unlikely. The legacy of its opcodes is
> just too good to walk away from - tens of thousands of lines of useful
> code, just waiting to be used.

Well, even if you'll have some problems with sample accuracy/resolution, you
have lots of cool, working code that can do what it was designed for pretty
well. While I don't even have a complete API spec yet...

> So for now, I will stick to Quasimodo's current timestamp free,
> asynchronous parameter update model. But adding an event buffer to
> each closure would be simple, and so if anyone wants to start
> rewriting the opcodes to use it, just let me know :)

Hmm... Events would map to the parameters of the opcodes. And the event parsing
code inlined in the outer loops should access the parameter variables instead
of the UI code doing it directly... Some copy-paste into an "opcode ->
Audiality" (or whatever) conversion skeleton or something, perhaps. Some parts
of the work could probably be rationalised a bit (macros, template plug-in
sources adapted to the opcode interface...), but it probably can't be done
automatically if we want efficient plug-ins.

Of course, it would probably be quite easy to run one or more opcodes inside a
plug-in, with the current direct access scheme, but that would break the
design rules and eliminate most of the advantages of both systems at once...
Sounds like a very temporary solution to me, and not at all in the Open Source
spirit. (Well, perhaps you've heard of Amulet and other cross-plug-in-API
adaptors for the proprietary systems... Emergency solution hacks IMO.)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Compose

From - Wed Sep 29 20:36:12 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA08760
	for <slinkp@ulster.net>; Tue, 28 Sep 1999 19:03:42 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA10587 for linux-audio-dev-list; Tue, 28 Sep 1999 18:40:13 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA10584 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 28 Sep 1999 18:40:09 -0400
Received: from localhost.localdomain (d212-151-85-137.swipnet.se [212.151.85.137]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA18665; 
          Wed, 29 Sep 1999 00:22:35 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: "P.J.Leonard" <P.J.Leonard@bath.ac.uk>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: [l Re: Plug-in API progress?
Date: Tue, 28 Sep 1999 22:27:37 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <37F08ABF.4487@bath.ac.uk>
MIME-Version: 1.0
Message-Id: <99092822324002.00439@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id AAA18665
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA08760
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 40fe045cd4ee5dac3ee3e08f16d4d82e

On Tue, 28 Sep 1999, P.J.Leonard wrote:
[...]
>  There are 3 options here.
> 
>  1. server sends events to notify GUI of changes.
>  2. GUI asks the server it's current state.
>  3. Mixture of 1 and 2
> 
>  (1) Is conceptually more attractive but you run the risk of clogging
> the system up
> with event messages if you have fine grain controllers changing fast.
> Here I speak from 
> my own experience (I have Qt widgets for adjusting midi parameters I
> also map midi controllers
> onto parameters and monitor the state with the sliders). The pitch
> change wheel generates
> quiet a lot of events !!!)
> 
>  (2) requires the GUI to poll the server on a timer which is a bit ugly
> but reduces the 
> time spent doing X11 stuff. I update widgets every 1/10 of a second. You
> can change
> the pitch wheel from min to max in this time.
> 
> 
>  I think any system should allow both schemes (1) and (2).

...or you could have the engine keep track of time (which it is doing with very
fine accuracy all the time anyway), and start to thin the event stream to the
GUI elements. GUI elements could tell the engine how high event frequencies
they want to handle. Could easily be done per GUI element if desired.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Sep 29 20:36:10 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA07209
	for <slinkp@ulster.net>; Tue, 28 Sep 1999 18:52:10 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA10549 for linux-audio-dev-list; Tue, 28 Sep 1999 18:27:26 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA10546 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 28 Sep 1999 18:27:22 -0400
Received: from localhost.localdomain (d212-151-85-137.swipnet.se [212.151.85.137]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA18750; 
          Wed, 29 Sep 1999 00:22:44 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Juhana Sadeharju <kouhia@nic.funet.fi>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Date: Tue, 28 Sep 1999 22:33:28 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <19990928094007Z46635-606+180@nic.funet.fi>
MIME-Version: 1.0
Message-Id: <99092822393203.00439@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id AAA18750
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA07209
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 265e61646c09fd5f45b72caa6e669afe

On Tue, 28 Sep 1999, Juhana Sadeharju wrote:
> >From:   David Olofson <audiality@swipnet.se>
> >> 
> >> my pro studio friends tell me that they *rarely* (if ever) record more
> >> than 16 tracks at once. keep this in mind. playback of, say 64 tracks,
> >
> >in? Anyway, personally, I rarely record more than 4 tracks at a time (partly
> 
> One application for really needed multitrack recording could be a recording
> of a concert or a play. I guess 16 tracks is then quite minimum number
> of channels.

Indeed. And that's also an application where you *really* need high
reliability.

And while we're back to this subject again; My experience is that recording is
*not* more expensive than playback. Not even with Windoze is there a noticable
difference. (Actually, for some reason, Windoze often get twice the read
transfer rate when writing!) The cost of allocating new sectors is only
significant in crappy filesystems, and other than that, there's not much
difference.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Sep 29 20:36:13 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA14483
	for <slinkp@ulster.net>; Tue, 28 Sep 1999 19:45:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA10683 for linux-audio-dev-list; Tue, 28 Sep 1999 19:26:51 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA10680 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 28 Sep 1999 19:26:47 -0400
Received: from localhost.localdomain (d212-151-85-137.swipnet.se [212.151.85.137]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA09710; 
          Wed, 29 Sep 1999 01:22:05 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>
Subject: [linux-audio-dev] Fwd: [rtl] Beowulf and RTLinux (and NIC latency)
Date: Wed, 29 Sep 1999 00:57:27 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
MIME-Version: 1.0
Message-Id: <99092901283100.00530@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id BAA09710
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA14483
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: b93f83dd76edb5ef7cf73bc5a96e150e

For those interested in real time processing using Beowulf clusters and similar
solutions; here's a post from the RTLinux list...

The point: I certainly don't see a significant hardware problem with real time
audio processing on clusters.

An engine that keeps track of inter-plug-in dependencies shouldn't have much
trouble making use of a Beowulf. There would be very few points in the net
where the network transfer latency come in, so the sub nets on the nodes would
be running nicely in parallel, with a time offset that depends on the transfer
latency/bandwidth ratio.

What's a few ms (if even that much) extra per node crossing (one or two in the
normal case) for mix down processing and playing from the sequencer? People are
actually *using* Windoze for that kind of work... (*muhahaha...!* Sorry. I
sure know what it feels like. ;-)

...so for the post:

---------------------------------------------------------
From: David Schleef <ds@stm.lbl.gov>
To: David Olofson <david.olofson@reologica.se>
Cc: yodaiken@fsmlabs.com,
 "Cesar A.R.G" <cero@beta.sucre.udo.edu.ve>,
 Beowulf <beowulf@beowulf.gsfc.nasa.gov>,
 RTLinux <rtl@rtlinux.cs.nmt.edu>
Subject: Re: [rtl] Beowulf and RTLinux (and NIC latency)
---------------------------------------------------------

On Mon, Sep 27, 1999 at 04:23:45PM +0200, David Olofson wrote:

> I'd like to see some more figures on actual transfer rates and latencies
> that
> can be achieved with RTLinux drivers.


Here's some latency numbers for the RT networking stuff that I'm
doing.  The numbers aren't very good, but the code is in the "Make
It Work Right" stage, and not tuned.

Computer 1: Pentium 90, 3c905b 100baseT NIC, Linux-2.2.10-rtl11

Computer 2: dual-P150, 3c905b 100baseT NIC, Linux-2.2.10-rtl11 (running
single processor, 'cuz it crashed otherwise)

connected by a 100baseT crossover cable

I'm getting round-trip times for ~60 byte UDP packets of consistently
less than 500 us for 100 million packets over 14 hours.  This number is
from RT task to RT task on the other computer and back using a simple
UDP echo server (port 7).

I have good reason to believe that with faster computers, the round trip
time should be less than 100 us.  Theoretically, it could be even as the
25-50 us range, but this might require significant hacks.  I get ping times
between a PII-400 and PPro200 (i.e., faster computers) of 0.1 ms with
normal Linux networking.

As for bandwidth, haven't tested it.



dave...
---------------------------------------------------------


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Sep 29 20:36:15 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA01486
	for <slinkp@ulster.net>; Tue, 28 Sep 1999 21:43:06 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA10936 for linux-audio-dev-list; Tue, 28 Sep 1999 21:22:02 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA10932 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 28 Sep 1999 21:21:58 -0400
Received: from someip.ppp.op.net (d-bm3-06.ppp.op.net [209.152.194.70]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id VAA28372 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 28 Sep 1999 21:17:21 -0400 (EDT)
Message-Id: <199909290117.VAA28372@renoir.op.net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Fwd: [rtl] Beowulf and RTLinux (and NIC latency) 
In-reply-to: Your message of "Wed, 29 Sep 1999 00:57:27 +0200."
             <99092901283100.00530@localhost.localdomain> 
Date: Tue, 28 Sep 1999 22:13:18 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f04feedca9caec4d19b67ca4ca2662f1

>The point: I certainly don't see a significant hardware problem with
>real time audio processing on clusters.

The figures cited don't measure the kind of latency that I consider
important in any likely audio system running on Beowulf.

I would be excited about these figures if they were for the *first*
packet after, say, 10ms of no packets at all. If they are, then
whoo-hoo! 

>What's a few ms (if even that much) extra per node crossing (one or
>two in the normal case) for mix down processing and playing from the
>sequencer? People ar e actually *using* Windoze for that kind of
>work... (*muhahaha...!* Sorry. I sure know what it feels like. ;-)

well, it depends on whether you're doing production/mixdown, or
real-time performance. most of my interest is in the latter, which is
why, for example, i consider quasimodo to be an instrument rather than
an equivalent to, say, ProTools or Logic. 

but sure, if you're mixing down 128 stereo tracks of 32bit/192KHz
audio, a beowulf cluster or three would be mighty handy, and would
work just fine.

--p


From - Wed Sep 29 20:36:16 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA03194
	for <slinkp@ulster.net>; Tue, 28 Sep 1999 21:52:37 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA10975 for linux-audio-dev-list; Tue, 28 Sep 1999 21:34:29 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA10972 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 28 Sep 1999 21:34:24 -0400
Received: from someip.ppp.op.net (d-bm3-06.ppp.op.net [209.152.194.70]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id VAA29185 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 28 Sep 1999 21:29:48 -0400 (EDT)
Message-Id: <199909290129.VAA29185@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress? 
In-reply-to: Your message of "Tue, 28 Sep 1999 22:33:28 +0200."
             <99092822393203.00439@localhost.localdomain> 
Date: Tue, 28 Sep 1999 22:25:44 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: df9bd710e5e785c21c8288e8b5c1f539

>> One application for really needed multitrack recording could be a recording
>> of a concert or a play. I guess 16 tracks is then quite minimum number
>> of channels.
>
>Indeed. And that's also an application where you *really* need high
>reliability.

Yeah, so high that Studer or OMB will charge you an incredibly large
amount of money to provide it.

As much of an audio evangelist for Linux as I might be, I don't think
that 48 or 64 track recording consoles have ever been built around
generalized microprocessors, and I suspect that because of the
reliability issue, they likely never will be. One of the more
expensive 24 track (analog) consoles I've seen has modular strips in
it, and this is apparently highly sought after, since real studios
can't afford to lose the whole console if there is failure in a key
component. modular strips reduce the chances of this by a large
amount- making the whole based around a single motherboard with 1 or
more CPU's on it will likely get someone pretty pissed off when there
is a problem.

The places that do this kind of thing with *digital* mixers, at least
for now, are also the kind of places that are going to want to run
real hardware consoles, and its going to be a while before Linux or
any other non-custom OS is going to be capable of running that kind of
beast with 48 or 64 channels of 48KHz+ audio. No self-respecting or
even semi-intelligent recording engineer is going to settle for a
couple of physical faders and a monitor or two.

I did see a Paris system at AES with 4 monitors and 4 control surfaces
(48 tracks) running on a Pentium III in one of those cryo-cooled boxes
allowing it run at 800MHz. Ensoniq rhetorically asked if this was the
most powerful DAW ever built ... I can't imagine anyone being willing
to use it for live recording of a professional event, and for lesser
events, the number of channels is probably down around 16.

On the other hand, running, say, 3 RME Hammerfalls (3 x 3 ADAT = 72
channels), with the DAC(s) in some hardware digital console, and Linux
as the raw HDR seems pretty feasible.

--p


From - Wed Sep 29 20:36:18 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA26819
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 01:13:37 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA11233 for linux-audio-dev-list; Wed, 29 Sep 1999 00:31:20 -0400
Received: from naps.uwindsor.ca (dns.uwindsor.ca [137.207.232.1]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA11230 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 00:31:17 -0400
Received: 	id AAA05958; Wed, 29 Sep 1999 00:25:54 -0400
Received: by gateway id AAA89894; Wed, 29 Sep 1999 00:24:11 -0400 (EDT)
Date: Wed, 29 Sep 1999 00:25:40 -0400
From: Stewart M <stewars@server.uwindsor.ca>
To: Paul Barton-Davis <pbd@Op.Net>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress? 
In-Reply-To: <199909290129.VAA29185@renoir.op.net>
Message-ID: <Pine.SGI.4.10.9909290004540.749671-100000@server.uwindsor.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1d5e06899444cdb172152fe92732499b

> >> One application for really needed multitrack recording could be a recording
> >> of a concert or a play. I guess 16 tracks is then quite minimum number
> >> of channels.
> >
> >Indeed. And that's also an application where you *really* need high
> >reliability.
> 
> The places that do this kind of thing with *digital* mixers, at least
> for now, are also the kind of places that are going to want to run
> real hardware consoles, and its going to be a while before Linux or

I worked at a place that did this kind of thing with a digital mixer and
the world class digital console was replaced by it's analog brother
shortly after it crashed during a live broadcast.  Those things are great
for studio work where the automation and recall features save tons of time
and you can afford the odd reboot.  But when you are live to four networks
with an orchestra it can make for a really bad day.

-MArk

From - Wed Sep 29 20:37:28 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA14740
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 11:24:01 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA12185 for linux-audio-dev-list; Wed, 29 Sep 1999 10:47:50 -0400
Received: from pat.bath.ac.uk (pat.bath.ac.uk [138.38.32.2]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id KAA12182 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 10:47:42 -0400
Received: (qmail 18657 invoked from network); 29 Sep 1999 14:43:00 -0000
Received: from mary.bath.ac.uk (HELO bath.ac.uk) (mmdf@138.38.32.14)
  by pat.bath.ac.uk with SMTP; 29 Sep 1999 14:43:00 -0000
Received: from tobi.bath.ac.uk by mary.bath.ac.uk id aa13248;
          29 Sep 99 15:42 BST
Message-ID: <37F22572.6231@bath.ac.uk>
Date: Wed, 29 Sep 1999 15:42:58 +0100
From: "P.J.Leonard" <P.J.Leonard@bath.ac.uk>
Organization: Applied Electromagnetic Research Centre
X-Mailer: Mozilla 3.0 (X11; I; OSF1 V2.0 alpha)
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: [l Re: Plug-in API progress?
References: <37F08ABF.4487@bath.ac.uk> <99092822324002.00439@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0c972419bd425632913d8ad285627b0c

David Olofson wrote:
> 
> On Tue, 28 Sep 1999, P.J.Leonard wrote:
> [...]
> >  There are 3 options here.
> >
> >  1. server sends events to notify GUI of changes.
> >  2. GUI asks the server it's current state.
> >  3. Mixture of 1 and 2
> >
> >  (1) Is conceptually more attractive but you run the risk of clogging
> > the system up
> > with event messages if you have fine grain controllers changing fast.
> > Here I speak from
> > my own experience (I have Qt widgets for adjusting midi parameters I
> > also map midi controllers
> > onto parameters and monitor the state with the sliders). The pitch
> > change wheel generates
> > quiet a lot of events !!!)
> >
> >  (2) requires the GUI to poll the server on a timer which is a bit ugly
> > but reduces the
> > time spent doing X11 stuff. I update widgets every 1/10 of a second. You
> > can change
> > the pitch wheel from min to max in this time.
> >
> >
> >  I think any system should allow both schemes (1) and (2).
> 
> ...or you could have the engine keep track of time (which it is doing with very
> fine accuracy all the time anyway), and start to thin the event stream to the
> GUI elements. GUI elements could tell the engine how high event frequencies
> they want to handle. Could easily be done per GUI element if desired.

<start of 2 cents>

 Yes, I think a design goal should be make things as simple as possible.
But
also as flexible as possible. I guess we should really have a wish list
and 
see what scheme is the best balance. 

 I am assuming the engine model is a network of components each with an
artbitary number
of input and output ports. Ports could be for signals, controllers or
monitors.

 Engine components.

  Treated like black boxes. They export a list of input and outputs
(ports) with names and types.
This would allow a generic type of GUI interface to control a new black
box. OK if you
know what all the things do you can design a fancy widget but let people
create engine
components without the pain of doing a GUI (in any case the GUI flavour
of the day tends
to change rapidly). 

 The main engine component (hub) would provide an interface for create
instances of components
and connecting them together. I guess we need to register components
with hub that then provides
the user with a list of available components. Again this could be done
in a generic fashion
(just rules about what types of connections can be made with other
ports)

 By defualt all engine components would broadcast events at top speed. I
would implement
your frequency filter with another engine component that  had a fast
input but an output
that broadcasts the last value at user defined rate (keeping the job of
the main elements
simple).


<end of 2 cents>

-- 
 Cheers Paul (P.J.Leonard)                                        

 Tel: +44 (0)1225 826108  Applied Electromagnetic Research Centre,
 Fax: +44 (0)1225 826305   University of Bath, BATH. BA2 7AY  UK

From - Wed Sep 29 20:37:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA19462
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 15:29:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA12916 for linux-audio-dev-list; Wed, 29 Sep 1999 14:50:07 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA12913 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 14:49:58 -0400
Received: from someip.ppp.op.net (d-bm3-00.ppp.op.net [209.152.194.64]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id OAA12836 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 14:45:09 -0400 (EDT)
Message-Id: <199909291845.OAA12836@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: [l Re: Plug-in API progress? 
In-reply-to: Your message of "Wed, 29 Sep 1999 15:42:58 BST."
             <37F22572.6231@bath.ac.uk> 
Date: Wed, 29 Sep 1999 15:41:16 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: dac6d9b94a6e4868f08780501b265e7f

><start of 2 cents>

	[ ... at least 2 pounds worth of comments elided ... ]

Just a quick detail to mention, arising from something that just came
up in Quasimodo.

If you assume that one of the targets of communication is a thread
running some of UI, and your further allow for the possibility that
this might be a different thread than the one in which the
communication originates, then you have to be *very* careful about
designing the messaging system.

As long as events which ultimately cause "messages" to be sent are
caused by the UI, then there is no problem.

However, I am just trying to get Quasimodo in shape to handle
automation down the line, and this changes things
substantially. Because X is not now, and probably never will be, truly
thread safe, my working assumption is that only the thread that starts
contact with the server can ever make contact with the server. The
alternative is to use mutexes to guard access to the server, and this
is an incredibly bad idea when one of the threads is a real-time audio
engine, and the other is a UI which might take an unbounded amount of
time before releasing the server mutex.

Why is this a problem ? Because it means that any "event" system that
is based, explicitly or implicitly, on execution of some code within
the same thread that raises the event, or that thinks it can escape
without mutexes around event queues, will likely cause X errors at
some point.

If an automation object decides that its time to post a parameter
change, and we want the UI object to notice it, it is *NOT ENOUGH* to
either (1) put the event on a queue or (2) execute a callback to the
UI code. In the case of (1), we have to grab the mutex around the
queue, which may or may not be a good idea, depending on your timing
constraints. In the case of (2), you have to implement a way to
execute a callback in the UI thread, not the thread posting the event.

There are some workarounds to this, such as always running the
automation code within the UI thread, and/or being very careful to
hold queue-protecting mutexes for a very, very short time. But even
so, you have to be careful. If the engine itself ever generates events
that the UI needs to be notified of, you're back to square one.

I hope its obvious (to all who might need to care) why you want the UI
to execute in a different thread than the engine of an audio system.

--p


From - Wed Sep 29 20:37:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA09260
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 17:55:40 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA13186 for linux-audio-dev-list; Wed, 29 Sep 1999 17:16:34 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id RAA13183 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 17:16:28 -0400
From: est@hyperreal.org
Received: (qmail 26743 invoked by uid 162); 29 Sep 1999 20:34:29 -0000
Message-ID: <19990929203429.26742.qmail@hyperreal.org>
Subject: [linux-audio-dev] mutex madness
In-Reply-To: <199909291845.OAA12836@renoir.op.net> from Paul Barton-Davis at
 "Sep 29, 1999 03:41:16 pm"
To: Paul Barton-Davis <pbd@Op.Net>
Date: Wed, 29 Sep 1999 13:34:29 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 923e9ebaea60889f58ac043bd87cd0f7

Paul Barton-Davis discourseth:
> 
> If an automation object decides that its time to post a parameter
> change, and we want the UI object to notice it, it is *NOT ENOUGH* to
> either (1) put the event on a queue or (2) execute a callback to the
> UI code. In the case of (1), we have to grab the mutex around the
> queue, which may or may not be a good idea, depending on your timing
> constraints. In the case of (2), you have to implement a way to
> execute a callback in the UI thread, not the thread posting the event.
> 
> There are some workarounds to this, such as always running the
> automation code within the UI thread, and/or being very careful to
> hold queue-protecting mutexes for a very, very short time. But even
> so, you have to be careful.

Indeed.  pthread mutexes aren't `fair'.  If the ui gets 500 events
behind it's entirely possible it will hog the mutex as it wraps a lock
around each pop while the dsp is trying to push one event.

However, if you build a fair mutex from pthread mutexes and condition
variables, wouldn't the mutex-protected-queue approach be reliable?

Eric

From - Wed Sep 29 20:37:42 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA12827
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 18:18:01 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA13282 for linux-audio-dev-list; Wed, 29 Sep 1999 17:48:17 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA13278 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 17:48:14 -0400
Received: from localhost.localdomain (d212-151-36-200.swipnet.se [212.151.36.200]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id XAA07352; 
          Wed, 29 Sep 1999 23:43:31 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Fwd: [rtl] Beowulf and RTLinux (and NIC latency)
Date: Wed, 29 Sep 1999 23:25:21 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199909290117.VAA28372@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99092923495900.00437@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id XAA07352
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA12827
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0a8f9f6fad0132c32e6837355698e151

On Wed, 29 Sep 1999, Paul Barton-Davis wrote:
> >The point: I certainly don't see a significant hardware problem with
> >real time audio processing on clusters.
> 
> The figures cited don't measure the kind of latency that I consider
> important in any likely audio system running on Beowulf.
> 
> I would be excited about these figures if they were for the *first*
> packet after, say, 10ms of no packets at all. If they are, then
> whoo-hoo! 

Well, if you get higher latencies in such situations, there certainly is a low
level hardware problem. However, I can't see what would cause such problems,
unless there's other traffic on the same network, that gets in the way. And
there won't be on a dedicated RT Beowulf - the cards are used as very fast
serial ports, and using full duplex cards with crossover cables (no hubs or
anything) eliminates collision problems, as there is nothing to collide with...

Besides, why would you drop communication for 10 ms in a system that constantly
transfers data with a cycle time of less than 10 ms? If there really is a low
level hardware problem (which I doubt there is, except in the case of a few
flawed NIC chipsets), it could be solved by just sending dummy packets to keep
the link in a stable state.

(Just to make it clear: I'm not interested in the lowest or average latency for
single events. It's guaranteed bandwidth with bounded maximum latency that
matters here.)

> >What's a few ms (if even that much) extra per node crossing (one or
> >two in the normal case) for mix down processing and playing from the
> >sequencer? People ar e actually *using* Windoze for that kind of
> >work... (*muhahaha...!* Sorry. I sure know what it feels like. ;-)
> 
> well, it depends on whether you're doing production/mixdown, or
> real-time performance.

That's exactly the point. An RTL Beowulf would (at least with proper networking
hardware) beat any Windoze system on latency, reliability and, of course, CPU
power, which pretty much invalidates the point that Beowulfs would only be
usable for batch jobs. People edit and mix on Windoze boxes, and many seem to
just accept the more than noticable response times, and the inability of doing
any real time monitoring through the virtual mixer.

> most of my interest is in the latter, which is
> why, for example, i consider quasimodo to be an instrument rather than
> an equivalent to, say, ProTools or Logic. 

I know, and I'm not suggesting that Beowulf is a viable design solution for real
time _instruments_.

(However, I might be wrong... I was afraid the hardware related latencies would
be much bigger, and that the peak latency was hardware related. Posts from
people working with this kind of stuff indicates that this is not the case.)

> but sure, if you're mixing down 128 stereo tracks of 32bit/192KHz
> audio, a beowulf cluster or three would be mighty handy, and would
> work just fine.

Yep, and even if you're right about the 100 ms, it's still very much better
than destructive/off-line editing - one of the most annoying parts of digital
editing. IMO, off-line edit operations can *never* be fast enough. It's simply
the wrong way to do most things I use DAWs for. Who likes waiting for the
results, or even stopping playback, when trying to be creative?


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Sep 29 20:37:45 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA17101
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 18:46:47 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA13407 for linux-audio-dev-list; Wed, 29 Sep 1999 18:16:22 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA13404 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 18:16:18 -0400
Received: from localhost.localdomain (d212-151-36-200.swipnet.se [212.151.36.200]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA19898; 
          Thu, 30 Sep 1999 00:11:25 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Date: Wed, 29 Sep 1999 23:53:29 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199909290129.VAA29185@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99093000175401.00437@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id AAA19898
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA17101
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 481be1d21c1713e63f59404d3be54fde

On Wed, 29 Sep 1999, Paul Barton-Davis wrote:
> >> One application for really needed multitrack recording could be a recording
> >> of a concert or a play. I guess 16 tracks is then quite minimum number
> >> of channels.
> >
> >Indeed. And that's also an application where you *really* need high
> >reliability.
> 
> Yeah, so high that Studer or OMB will charge you an incredibly large
> amount of money to provide it.
> 
> As much of an audio evangelist for Linux as I might be, I don't think
> that 48 or 64 track recording consoles have ever been built around
> generalized microprocessors, and I suspect that because of the
> reliability issue, they likely never will be. One of the more
> expensive 24 track (analog) consoles I've seen has modular strips in
> it, and this is apparently highly sought after, since real studios
> can't afford to lose the whole console if there is failure in a key
> component. modular strips reduce the chances of this by a large
> amount- making the whole based around a single motherboard with 1 or
> more CPU's on it will likely get someone pretty pissed off when there
> is a problem.

So, use two or three machines, either 100% over capacity with distributed load
(also gives you some extra CPU headroom, just in case), or in parallel. In the
later case, the idea is to use a model similar to that used in aerospace
control systems. One scheme is to have all systems watch each other, and
disable a system that disagrees with the others.

How much reliability do you need? If there's money, there are solutions... And
Linux isn't all that bad a foundation to build on.

> The places that do this kind of thing with *digital* mixers, at least
> for now, are also the kind of places that are going to want to run
> real hardware consoles, and its going to be a while before Linux or
> any other non-custom OS is going to be capable of running that kind of
> beast with 48 or 64 channels of 48KHz+ audio.

Why? Lack of DSP power in workstation CPUs, lack of hard RT support with
protected memory, or what?

> No self-respecting or
> even semi-intelligent recording engineer is going to settle for a
> couple of physical faders and a monitor or two.

That's nothing to do with Linux, or any other similar OS. The instrument I'm
developing an embeded application for at work doesn't have a screen at all...
(You can hook one up for debugging with current version, but I'm planning to
drop that too, and kick the video board, if we can find a BIOS that can boot
without one.)

> I did see a Paris system at AES with 4 monitors and 4 control surfaces
> (48 tracks) running on a Pentium III in one of those cryo-cooled boxes
> allowing it run at 800MHz. Ensoniq rhetorically asked if this was the
> most powerful DAW ever built ... I can't imagine anyone being willing
> to use it for live recording of a professional event, and for lesser
> events, the number of channels is probably down around 16.

Hah! Well, I don't blame them... And in this case, it's the _Paris_ doing the
processing with dedicated DSPs. (That's why it's actually rather usable,
compared to most all native solutions.) The P-III 800 is only doing the disk
I/O and the GUI! What a waste...

> On the other hand, running, say, 3 RME Hammerfalls (3 x 3 ADAT = 72
> channels), with the DAC(s) in some hardware digital console, and Linux
> as the raw HDR seems pretty feasible.

Yes. However, you're still in for reliability problems here, if we're talking
about the live situations mentioned earlier. Or perhaps an uptime of at least a
few months is enough, after all?

Keep in mind that embeded systems usually have special boot/system "disk"
solutions that are quite different from what you find in the average server.
And they're shut down and rebooted (from R/O media) quite often, which means
you never come close to the average Linux uptime...

How much more reliable are dedicated DSPs really? A bug in DSP code means a
freeze or crash on that DSP (which may kill several plug-ins), as there's
usually no OS whatsoever, and certainly not one with protected memory, as that
can't even be done with most DSPs. RTLinux + protected memory would make such
things easier to control, and wouldn't take the system down. What the high
level control system code and GUI (if any) does is pretty much irrelevant - if
it segfaults, it'll just do a M$ NT/98 Explorer: Restart and hope no one
noticed that the icons went away...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Sep 29 20:37:47 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA18463
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 18:55:40 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA13495 for linux-audio-dev-list; Wed, 29 Sep 1999 18:24:53 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA13492 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 18:24:50 -0400
Received: from localhost.localdomain (d212-151-36-200.swipnet.se [212.151.36.200]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA26731; 
          Thu, 30 Sep 1999 00:14:50 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Stewart M <stewars@server.uwindsor.ca>, Paul Barton-Davis <pbd@Op.Net>
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Date: Thu, 30 Sep 1999 00:18:54 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <Pine.SGI.4.10.9909290004540.749671-100000@server.uwindsor.ca>
MIME-Version: 1.0
Message-Id: <99093000211902.00437@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id AAA26731
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA18463
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b706667c95edeb6499e9a4c1ddd08258

On Wed, 29 Sep 1999, Stewart M wrote:
> > >> One application for really needed multitrack recording could be a recording
> > >> of a concert or a play. I guess 16 tracks is then quite minimum number
> > >> of channels.
> > >
> > >Indeed. And that's also an application where you *really* need high
> > >reliability.
> > 
> > The places that do this kind of thing with *digital* mixers, at least
> > for now, are also the kind of places that are going to want to run
> > real hardware consoles, and its going to be a while before Linux or
> 
> I worked at a place that did this kind of thing with a digital mixer and
> the world class digital console was replaced by it's analog brother
> shortly after it crashed during a live broadcast.  Those things are great
> for studio work where the automation and recall features save tons of time
> and you can afford the odd reboot.  But when you are live to four networks
> with an orchestra it can make for a really bad day.

Computers control aeroplanes. There are solutions... (More on that in my
previous post.)

Oh, aerospace control systems do fail occasionally, even though there are
usually three of each, and multiple watchdog systems - but so does analog
cirquitry.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Sep 29 20:37:50 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA18886
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 18:59:03 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA13516 for linux-audio-dev-list; Wed, 29 Sep 1999 18:27:07 -0400
Received: from anime.net (anime.net [205.139.105.150]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA13513 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 18:27:03 -0400
Received: from localhost (goemon@localhost)
	by anime.net (8.9.3/8.9.3) with ESMTP id PAA13926;
	Wed, 29 Sep 1999 15:22:10 -0700
Date: Wed, 29 Sep 1999 15:22:09 -0700 (PDT)
From: Dan Hollis <goemon@sasami.anime.net>
X-Sender: goemon@anime.net
To: David Olofson <audiality@swipnet.se>
cc: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
In-Reply-To: <99093000175401.00437@localhost.localdomain>
Message-ID: <Pine.LNX.4.10.9909291520001.13878-100000@anime.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 69c9ebeb41e27275fbd53865379a98f1

On Wed, 29 Sep 1999, David Olofson wrote:
> How much more reliable are dedicated DSPs really? A bug in DSP code means a
> freeze or crash on that DSP (which may kill several plug-ins), as there's
> usually no OS whatsoever, and certainly not one with protected memory, as that
> can't even be done with most DSPs.

It is suprisingly easy to crash midi devices by sending bogus commands, or
even sending them too quickly. I get the feeling that depressingly little
testing is done on keyboards and devices before they are shipped.

So much for "dedicated hardware is more reliable".

-Dan

From - Wed Sep 29 20:37:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA23242
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 19:29:42 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA13665 for linux-audio-dev-list; Wed, 29 Sep 1999 19:02:06 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA13662 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 19:02:02 -0400
Received: from localhost.localdomain (d212-151-36-200.swipnet.se [212.151.36.200]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA13161; 
          Thu, 30 Sep 1999 00:44:30 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: "P.J.Leonard" <P.J.Leonard@bath.ac.uk>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: [l Re: Plug-in API progress?
Date: Thu, 30 Sep 1999 00:23:56 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <37F22572.6231@bath.ac.uk>
MIME-Version: 1.0
Message-Id: <99093000505903.00437@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id AAA13161
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA23242
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e9ca19337160e5b2e3fc49b2fe232a04

On Wed, 29 Sep 1999, P.J.Leonard wrote:
[...]
> > ...or you could have the engine keep track of time (which it is doing with
very > > fine accuracy all the time anyway), and start to thin the event stream
to the > > GUI elements. GUI elements could tell the engine how high event
frequencies > > they want to handle. Could easily be done per GUI element if
desired. > 
> <start of 2 cents>
> 
>  Yes, I think a design goal should be make things as simple as possible.
> But
> also as flexible as possible. I guess we should really have a wish list
> and 
> see what scheme is the best balance. 

Yes. The most important part of this effort would be to find a pattern in the
list of desired features, and implement *as few subsystems as possible* to
provide these features. I've seen too many things designed the other way
around... (Creeping Featurism.)

>  I am assuming the engine model is a network of components each with an
> artbitary number
> of input and output ports. Ports could be for signals, controllers or
> monitors.

Something like that, yes. (The design I have in mind at least.) There's
basically two data types: Data streams and events.

Data streams are just raw data, transfered as variable size buffers (although
the buffer size is normaly kept constant for audio plug-ins). Kind of like a
low level networking protocol, optimized for high bandwidth real time streaming.

What's more interesting to the UI is the event system. If I understand you
right, signals, controllers and monitors make a subset of the events I intend
to send through my event system. (It'll also handle some or all of the plug-in
<-> host communication, even during instantiation of plug-ins.)

The subclassing of events is one area where I really would like some ideas -
what do we need, and how to standardize as much as possible without making it
useless? The idea is to be able to use defined standard events (as opposed to
custom events that only a plug-in and it's GUI module can understand) for
almost everything, so that an automation system or preset librarian could
really work in real life. I don't want to force plug-in writers to do that kind
of work, as it really belongs in a central system. Extra interface layers ==
overhead, complexity, more work, more bugs, less plug-ins...

>  Engine components.
> 
>   Treated like black boxes. They export a list of input and outputs
> (ports) with names and types.

That would translate to things like "I use Standard Level Control #1, and I
call it 'Threshold'." Nothing much more will be needed, and other parts of the
system (like an automation GUI) will know what a Standard Level Control is, and
how the user would most likely want to see it on screen. More importantly,
things like importance of control "signal" quality and other factors can be
predefined, so that you don't need masses of conditional code in the engine, or
extra plug-ins to interface to the control.

[...]
>  The main engine component (hub) would provide an interface for create
> instances of components
> and connecting them together. I guess we need to register components
> with hub that then provides
> the user with a list of available components. Again this could be done
> in a generic fashion
> (just rules about what types of connections can be made with other
> ports)

This is where restrictions of buffer size, data format, sample rate etc should
be taken into account, so that the engine can group plug-ins efficiently, and
throw in converter plug-ins where necessary. (No code for this inside the
actual real time engine, that is.)

>  By defualt all engine components would broadcast events at top speed. I
> would implement
> your frequency filter with another engine component that  had a fast
> input but an output
> that broadcasts the last value at user defined rate (keeping the job of
> the main elements
> simple).

Yes, that's _exactly_ how things are to be done using my idea of an design.
Frequently used "system" plug-ins can be built into the engine, or even
hardcoded inline, but they should still act and look like normal plug-ins in
most respects. No extra APIs for "special functions", that is. And *everything*
can be automated, monitored or whatever, using the same code... (Ok, no rule
without exceptions, but at least, we can try to do most things right from the
start. We have seen enough of Redmond style design, right?)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Sep 29 20:37:40 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA12227
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 18:14:32 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA13270 for linux-audio-dev-list; Wed, 29 Sep 1999 17:45:34 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA13267 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 17:45:20 -0400
Received: from someip.ppp.op.net (d-bm2-13.ppp.op.net [209.152.194.51]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id RAA01345; Wed, 29 Sep 1999 17:40:22 -0400 (EDT)
Message-Id: <199909292140.RAA01345@renoir.op.net>
To: est@hyperreal.org
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: mutex madness 
In-reply-to: Your message of "Wed, 29 Sep 1999 13:34:29 PDT."
             <19990929203429.26742.qmail@hyperreal.org> 
Date: Wed, 29 Sep 1999 18:36:31 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: bddbb8582e3509c33cc21745c4b1468d

>Indeed.  pthread mutexes aren't `fair'.  If the ui gets 500 events
>behind it's entirely possible it will hog the mutex as it wraps a lock
>around each pop while the dsp is trying to push one event.
>
>However, if you build a fair mutex from pthread mutexes and condition
>variables, wouldn't the mutex-protected-queue approach be reliable?

well, in general, my code for handling mutex-protected queues looks
like the fairly "standard" thing:

     lock_queue ();
     while (queue_not_empty()) {
	  entry = pop_first_entry ();
	  unlock_queue ();

	  process_entry (entry);
	  lock_queue ();
     }
     unlock_queue ();

this at least leaves the queue unlocked during the time-consuming part
of things. typically, process_entry() for the UI thread involves at
least one expensive X protocol call, so in general, the DSP will get a
chance to grab the mutex.

things can more unpredictable, however, if you add one more runnable
thread to the entire OS thread list. if this thread gets to run
instead of the UI thread while the UI thread still holds the lock on
the queue, then the DSP thread is out of luck, and so are we. this is
even more likely (to the extent that it *is* likely at all) if the
input thread is has RT scheduling.

so, the above scheme will work most of the time, but still can't
guarantee that the dsp will get the lock when it needs to. even
turning the mutex into a "fair" one won't help this pathological
condition.

BTW, you could work around this by making the UI thread run
SCHED_FIFO, but this causes a lot of other problems, especially on a
UP system.

one partial workaround to this problem that i have used a little in
Quasimodo is to make use of the atomic_t typedef. this at least allows
inspection of queue lengths without taking the lock. you can use this
if you have a clear demarcation between queue readers and writers: the
writer takes the lock, and as the last operation before it releases
the lock, it bumps an atomic_t. the reader never tries to take the
lock unless the atomic_t is non-zero.

so, for example, the dsp thread in quasimodo doesn't take the lock on
its own request queue unless the atomic_t that indicates the length of
the queue is non-zero. this prevents the dsp thread from ever blocking
unnecessarily.

but fundamentally, if one thread wants to stick something in a data
structure that is not an atomic_t, and another thread might also be
manipulating the same location, we have to wrap it in a lock (don't
anyone dare mention lock-free synchronization or i'll strangle them :)
there is just no way around this. 

so we just need to focus on designs that minimize the communication
between threads. BTW, this is another reason for my appreciation of
quasimodo's asynch parameter update model: since the dsp thread never
does anything non-atomic to the data that other threads might update,
the other threads can play with it any time they want without causing
internal code errors (it might cause non-sample-accurate or even just
plain wierd sound, though). contrast this to an event model, in which
mutexes will have to exist between the event receiver and the event
consumer threads (unless they are the same thread).

:))

--p




From - Wed Sep 29 20:37:59 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA25080
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 19:42:54 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA13721 for linux-audio-dev-list; Wed, 29 Sep 1999 19:08:23 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA13717 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 19:08:19 -0400
Received: from localhost.localdomain (d212-151-36-200.swipnet.se [212.151.36.200]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA12131; 
          Thu, 30 Sep 1999 01:03:11 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: [l Re: Plug-in API progress?
Date: Thu, 30 Sep 1999 00:54:39 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199909291845.OAA12836@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99093001094004.00437@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id BAA12131
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA25080
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e1d71ce1a3997f9dc9b02394a215c715

On Wed, 29 Sep 1999, Paul Barton-Davis wrote:
> ><start of 2 cents>
> 
> 	[ ... at least 2 pounds worth of comments elided ... ]
> 
> Just a quick detail to mention, arising from something that just came
> up in Quasimodo.
> 
> If you assume that one of the targets of communication is a thread
> running some of UI, and your further allow for the possibility that
> this might be a different thread than the one in which the
> communication originates, then you have to be *very* careful about
> designing the messaging system.
> 
> As long as events which ultimately cause "messages" to be sent are
> caused by the UI, then there is no problem.
> 
> However, I am just trying to get Quasimodo in shape to handle
> automation down the line, and this changes things
> substantially. Because X is not now, and probably never will be, truly
> thread safe, my working assumption is that only the thread that starts
> contact with the server can ever make contact with the server. The
> alternative is to use mutexes to guard access to the server, and this
> is an incredibly bad idea when one of the threads is a real-time audio
> engine, and the other is a UI which might take an unbounded amount of
> time before releasing the server mutex.

Perhaps you need an extra thread somewhere around here... Either just to fight
over the mutex with the GUI thread without getting the engine directl involved,
or as the only interface between the GUI and your application. Sounds either
"not too nice" or "far from trivial" to me, though.

> Why is this a problem ? Because it means that any "event" system that
> is based, explicitly or implicitly, on execution of some code within
> the same thread that raises the event, or that thinks it can escape
> without mutexes around event queues, will likely cause X errors at
> some point.
> 
> If an automation object decides that its time to post a parameter
> change, and we want the UI object to notice it, it is *NOT ENOUGH* to
> either (1) put the event on a queue or (2) execute a callback to the
> UI code. In the case of (1), we have to grab the mutex around the
> queue, which may or may not be a good idea, depending on your timing
> constraints. In the case of (2), you have to implement a way to
> execute a callback in the UI thread, not the thread posting the event.

That would be some kind of IPC hack, like "local RPCs"... Possible, but I'm
afraid it doesn't solve much, as doing it from real time code will result in the
same timing problems as mutexes + the "RPC" overhead. I think reducing the
callback to an IPC message of some form should do... You might have to do some
select() hack or something in the GUI thread to take care of those messages.

> There are some workarounds to this, such as always running the
> automation code within the UI thread, and/or being very careful to
> hold queue-protecting mutexes for a very, very short time. But even
> so, you have to be careful. If the engine itself ever generates events
> that the UI needs to be notified of, you're back to square one.

Ok. But the events you send from a real time system to a non/soft real time
system may as well be degraded to the RT quality of the destination ASAP. That
is, queue them somewhere (using a pipe or whatever), so the higher quality RT
thread never has to block. That's the standard solution for RTLinux<->Linux
communication. It works well, and is very simple. Of course, if you want a more
efficient solution, use shared memory + semaphores, or something like that.

> I hope its obvious (to all who might need to care) why you want the UI
> to execute in a different thread than the engine of an audio system.

Well, unless the UI is a bunch of LEDs and some motorized faders, that is...
You probably want such a UI hard real time anyway, as long as it doesn't
jeopardize the stability of the engine. But that's quite different from what
we're discussing here.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Sep 29 20:37:44 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA15998
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 18:38:09 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA13345 for linux-audio-dev-list; Wed, 29 Sep 1999 18:08:23 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA13342 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 18:08:13 -0400
Received: from someip.ppp.op.net (d-bm2-13.ppp.op.net [209.152.194.51]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id SAA03259 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 18:03:27 -0400 (EDT)
Message-Id: <199909292203.SAA03259@renoir.op.net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Fwd: [rtl] Beowulf and RTLinux (and NIC latency) 
In-reply-to: Your message of "Wed, 29 Sep 1999 23:25:21 +0200."
             <99092923495900.00437@localhost.localdomain> 
Date: Wed, 29 Sep 1999 18:59:37 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5cfe96be1aae212f011925e77743f2a9

>Besides, why would you drop communication for 10 ms in a system that
>constantly transfers data with a cycle time of less than 10 ms?

10ms was just a guess.

Even so, because the nodes are going to be loosely coupled, you're not
going to be communicating all the time. It may be that the processing
net on one node is idle for a while (you turn off the TrueVerb, for
example). You'll need to be ready for the "restart cost", whatever it
is. 

I'll try to check into what I'm half-remembering about this.  I don't
know where the delay can come from - I should try to find the guy I
knew who worked on this stuff (which was an early precursor to
Beowulf).

--p

From - Wed Sep 29 20:37:58 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA24070
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 19:35:23 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA13702 for linux-audio-dev-list; Wed, 29 Sep 1999 19:06:47 -0400
Received: from anime.net (anime.net [205.139.105.150]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA13698 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 19:06:39 -0400
Received: from localhost (goemon@localhost)
	by anime.net (8.9.3/8.9.3) with ESMTP id QAA14448;
	Wed, 29 Sep 1999 16:01:56 -0700
Date: Wed, 29 Sep 1999 16:01:56 -0700 (PDT)
From: Dan Hollis <goemon@sasami.anime.net>
X-Sender: goemon@anime.net
To: Paul Barton-Davis <pbd@Op.Net>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] linux audio demonstrability: NOT!
In-Reply-To: <199909292345.TAA15580@op.net>
Message-ID: <Pine.LNX.4.10.9909291600590.14397-100000@anime.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 666c4c608aa8fa684bc5e1ac4f24aacd

> OK, alsaplayer is a nice one. grip and gcombust are both robust, and
> excellent, but they are about CD technology, essentially. The set of
> examples to show someone who is seriously interested in the future of
> computer based audio is, frankly, pathetic.

Its called chicken-and-egg scenario. Each is mutually dependent on the
other.

You cant have apps without hardware. You cant have hardware without apps.

Bitching about lacking one or the other is pointless.

-Dan

From - Wed Sep 29 20:38:01 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA28080
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 20:03:19 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA13779 for linux-audio-dev-list; Wed, 29 Sep 1999 19:26:52 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA13776 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 19:26:48 -0400
Received: from localhost.localdomain (d212-151-36-200.swipnet.se [212.151.36.200]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA18061; 
          Thu, 30 Sep 1999 01:21:58 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Fwd: [rtl] Beowulf and RTLinux (and NIC latency)
Date: Thu, 30 Sep 1999 01:16:42 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199909292203.SAA03259@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99093001282605.00437@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id BAA18061
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA28080
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d90871de683a07d17c135dd793488001

On Thu, 30 Sep 1999, Paul Barton-Davis wrote:
> >Besides, why would you drop communication for 10 ms in a system that
> >constantly transfers data with a cycle time of less than 10 ms?
> 
> 10ms was just a guess.

Yeah, and it doesn't matter what the figure is; it's the worst case that
matters, and it must be significantly less than 1 ms for really cool real time
audio stuff.

> Even so, because the nodes are going to be loosely coupled, you're not
> going to be communicating all the time. It may be that the processing
> net on one node is idle for a while (you turn off the TrueVerb, for
> example). You'll need to be ready for the "restart cost", whatever it
> is. 

Both there problems are due to system design errors, not hardware problems.

1) You don't do low latency, high bandwidth streaming over a loosely
   coupled SAN. There will be two cards and one cable for every single
   RT connection path. (Well, this is supposed to be an alternative to
   $$,$$$ SMP boxes - what did you expect?)

2) You never *ever* temporarily turn parts of a running hard real time
   system off. If you do, you'll just have to face the brutal truth;
   you may have an unbounded restart time until your system is a real
   time system again. (Solution: Initialize plug-ins first in a low
   priority thread - then plug them into the engine.)

> I'll try to check into what I'm half-remembering about this.  I don't
> know where the delay can come from - I should try to find the guy I
> knew who worked on this stuff (which was an early precursor to
> Beowulf).

If it's loosely couple networks with switches or similar solutions, I'm not
suprised that there are latency problems. I'm pretty sure the problem is the
actual reconnecting of nodes after being silent for a while.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Sep 29 20:37:49 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA18534
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 18:56:11 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA13527 for linux-audio-dev-list; Wed, 29 Sep 1999 18:28:18 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA13524 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 18:28:09 -0400
Received: from someip.ppp.op.net (d-bm2-13.ppp.op.net [209.152.194.51]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id SAA04815 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 18:23:24 -0400 (EDT)
Message-Id: <199909292223.SAA04815@renoir.op.net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Fwd: [rtl] Beowulf and RTLinux (and NIC latency) 
In-reply-to: Your message of "Wed, 29 Sep 1999 23:25:21 +0200."
             <99092923495900.00437@localhost.localdomain> 
Date: Wed, 29 Sep 1999 19:19:34 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: eed99483ff0dd72f6afbc222acfe4a78

OK, here is a reference about some of the difficulties that typical
OS's and h/w create for distributed processing on a "regular" network
(ethernet, FDDI, ATM):

  ftp://ftp.cs.washington.edu/tr/1994/07/UW-CSE-94-07-02.PS.Z

Its called "System Support for Efficient Network Communication", and
is a summary of Chandromohan Thekkath's Ph.D thesis.

The paper is a little old. It would be great if better controllers and
Linux' networking stack have eliminated most of the problems that
Chandu wrote about, but I am not sure that this is true.

--p

From - Wed Sep 29 20:37:52 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA19524
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 19:03:49 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA13554 for linux-audio-dev-list; Wed, 29 Sep 1999 18:34:52 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA13551 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 18:34:38 -0400
Received: from someip.ppp.op.net (d-bm2-13.ppp.op.net [209.152.194.51]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id SAA05348 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 18:29:54 -0400 (EDT)
Message-Id: <199909292229.SAA05348@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress? 
In-reply-to: Your message of "Thu, 30 Sep 1999 00:18:54 +0200."
             <99093000211902.00437@localhost.localdomain> 
Date: Wed, 29 Sep 1999 19:26:04 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5c8c6e21eb8a2fbbbd8762e6f0f3f12f

>Computers control aeroplanes. There are solutions... (More on that in my
>previous post.)

and aeroplanes cost ....

sure, a lot of it is for the mechanical construction, but as expensive
as those Studer consoles are, I think I'd rather pay that than the
cost implied by what I understand would be involved in an
aeroplane-like system. 

related note: a friend of mine who worked for the JPL for a while told
me a few years back that NASA had not yet sent a computer any more
powerful than a classic Mac into space. They just didn't believe they
could build one that would be reliable enough. Its a testament to what
you can do with limited hardware, and also to the range of
reliabilities that we work with. I think that this may have changed
recently, BTW, but only for the non-critical systems on the shuttle.

--p "live from Apollo 13 Studios"

From - Wed Sep 29 20:38:03 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA29453
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 20:12:06 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA13818 for linux-audio-dev-list; Wed, 29 Sep 1999 19:30:29 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA13815 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 19:30:26 -0400
Received: from localhost.localdomain (d212-151-36-200.swipnet.se [212.151.36.200]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA19063; 
          Thu, 30 Sep 1999 01:25:30 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Dan Hollis <goemon@sasami.anime.net>
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Date: Thu, 30 Sep 1999 01:29:41 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
References: <Pine.LNX.4.10.9909291520001.13878-100000@anime.net>
MIME-Version: 1.0
Message-Id: <99093001315906.00437@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id BAA19063
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA29453
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: cfbb6b946799cb8225f61a81f38daf8e

On Thu, 30 Sep 1999, Dan Hollis wrote:
> On Wed, 29 Sep 1999, David Olofson wrote:
> > How much more reliable are dedicated DSPs really? A bug in DSP code means a
> > freeze or crash on that DSP (which may kill several plug-ins), as there's
> > usually no OS whatsoever, and certainly not one with protected memory, as that
> > can't even be done with most DSPs.
> 
> It is suprisingly easy to crash midi devices by sending bogus commands, or
> even sending them too quickly. I get the feeling that depressingly little
> testing is done on keyboards and devices before they are shipped.
> 
> So much for "dedicated hardware is more reliable".

Another reason might be that it's harder to work with DSP/MCU development
systems than on workstations. As long as you have a solid OS, you can probably
build more reiliable solutions with less effort than in embeded environments
not based on workstation hardware.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Sep 29 20:38:07 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA30109
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 20:16:35 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA13844 for linux-audio-dev-list; Wed, 29 Sep 1999 19:35:05 -0400
Received: from anime.net (anime.net [205.139.105.150]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA13841 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 19:35:01 -0400
Received: from localhost (goemon@localhost)
	by anime.net (8.9.3/8.9.3) with ESMTP id QAA14941;
	Wed, 29 Sep 1999 16:30:15 -0700
Date: Wed, 29 Sep 1999 16:30:15 -0700 (PDT)
From: Dan Hollis <goemon@sasami.anime.net>
X-Sender: goemon@anime.net
To: David Olofson <audiality@swipnet.se>
cc: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
In-Reply-To: <99093001315906.00437@localhost.localdomain>
Message-ID: <Pine.LNX.4.10.9909291629350.14914-100000@anime.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e3739bbe97f95f00db19a7efdf0c5e15

On Thu, 30 Sep 1999, David Olofson wrote:
> > So much for "dedicated hardware is more reliable".
> Another reason might be that it's harder to work with DSP/MCU development
> systems than on workstations. As long as you have a solid OS, you can probably
> build more reiliable solutions with less effort than in embeded environments
> not based on workstation hardware.

And thus most of the embedded hardware arguments evaporate....

-Dan

From - Wed Sep 29 20:38:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA29731
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 20:14:08 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA13865 for linux-audio-dev-list; Wed, 29 Sep 1999 19:38:20 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA13862 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 19:38:16 -0400
Received: from localhost.localdomain (d212-151-36-200.swipnet.se [212.151.36.200]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA20219; 
          Thu, 30 Sep 1999 01:28:34 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Fwd: [rtl] Beowulf and RTLinux (and NIC latency)
Date: Thu, 30 Sep 1999 01:32:43 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199909292223.SAA04815@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99093001350207.00437@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id BAA20219
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA29731
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 395f0e1530e81e6c83e38f32a9bfddb4

On Thu, 30 Sep 1999, Paul Barton-Davis wrote:
> OK, here is a reference about some of the difficulties that typical
> OS's and h/w create for distributed processing on a "regular" network
> (ethernet, FDDI, ATM):
> 
>   ftp://ftp.cs.washington.edu/tr/1994/07/UW-CSE-94-07-02.PS.Z
> 
> Its called "System Support for Efficient Network Communication", and
> is a summary of Chandromohan Thekkath's Ph.D thesis.
> 
> The paper is a little old. It would be great if better controllers and
> Linux' networking stack have eliminated most of the problems that
> Chandu wrote about, but I am not sure that this is true.

>From what people working with NICs (RTLinux or Linux) have told me, there are
no hardware problems. And I'll use the NICs are high speed serial ports with
dedicated RTLinux drivers...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Sep 29 20:38:06 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA30040
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 20:16:10 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA13877 for linux-audio-dev-list; Wed, 29 Sep 1999 19:41:00 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA13874 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 19:40:57 -0400
Received: from localhost.localdomain (d212-151-36-200.swipnet.se [212.151.36.200]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA22488; 
          Thu, 30 Sep 1999 01:36:14 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Date: Thu, 30 Sep 1999 01:35:21 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199909292229.SAA05348@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99093001424308.00437@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id BAA22488
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA30040
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3ee0a23ef80d595e13e4f1e90553aa87

On Thu, 30 Sep 1999, Paul Barton-Davis wrote:
> >Computers control aeroplanes. There are solutions... (More on that in my
> >previous post.)
> 
> and aeroplanes cost ....
> 
> sure, a lot of it is for the mechanical construction, but as expensive
> as those Studer consoles are, I think I'd rather pay that than the
> cost implied by what I understand would be involved in an
> aeroplane-like system. 

How reliable *are* those Studer consoles really? What happens if one DSP fries
in the middle of a show? Or an ADC? And how many complete SMP Linux boxes +
audio interfaces can you buy instead of one Studer console?

> related note: a friend of mine who worked for the JPL for a while told
> me a few years back that NASA had not yet sent a computer any more
> powerful than a classic Mac into space. They just didn't believe they
> could build one that would be reliable enough.

As a programmer, I don't blame them... ;-)

> Its a testament to what
> you can do with limited hardware, and also to the range of
> reliabilities that we work with. I think that this may have changed
> recently, BTW, but only for the non-critical systems on the shuttle.

I think there are more fault tolerant systems and less "bug free" systems in the
modern designs... And I think that's the way to go, and even more so in
environments where power consumption and physical size isn't all too critical.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Sep 29 20:37:54 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA22389
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 19:24:03 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA13613 for linux-audio-dev-list; Wed, 29 Sep 1999 18:54:45 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA13606 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 18:54:26 -0400
Received: from op.net (d-bm2-13.ppp.op.net [209.152.194.51]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id SAA06888 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 18:49:41 -0400 (EDT)
Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id TAA15580; Wed, 29 Sep 1999 19:45:50 -0400
Date: Wed, 29 Sep 1999 19:45:50 -0400
Message-Id: <199909292345.TAA15580@op.net>
From: Paul Barton-Davis <pbd@Op.Net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] linux audio demonstrability: NOT!
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: ed1624ac899e3ef12d92bed4d8638890

>> On the other hand, running, say, 3 RME Hammerfalls (3 x 3 ADAT = 72
>> channels), with the DAC(s) in some hardware digital console, and Linux
>> as the raw HDR seems pretty feasible.

>Yes. However, you're still in for reliability problems here, if we're
>talking about the live situations mentioned earlier. Or perhaps an
>uptime of at least a few months is enough, after all?

\begin{rant}

Yesterday, one of the Creamware US guys wrote me for some advice about
Linux audio stuff. In writing a reply, I got the feeling that David's
comment above highlights an almost laughable situation. Here we are
worrying about reliability problems on digital audio cards, and
latency questions etc.

Can you suggest an even vaguely exciting and believable demo of
anything to do with audio under Linux ? Something that would get a guy
from a company like Steinberg or Creamware or Digidesign excited ?

Yes, we (and particularly *I*) can talk all day about plugin API
design, but the simple fact right now is that the emperor has no
clothes! I have a meeting with the east coast Creamware rep next week,
and although its not the purpose of our meeting, I may get to do
a little Linux demo for him. What would I show him ? Some
half-finished, buggy sequencer projects ? A TB303 emulator like
freebirth, with cool sounds and completely incomprehensible graphics ?
A superb, extensible soundfile editor with guile + C available for
plugins, but that crashes when I use it with a free version of Motif ?
A partially complete analog synth/rack application that crashes fairly
regularly ? 

OK, alsaplayer is a nice one. grip and gcombust are both robust, and
excellent, but they are about CD technology, essentially. The set of
examples to show someone who is seriously interested in the future of
computer based audio is, frankly, pathetic.

Its one thing to know that we have the infrastructure for some amazing
stuff. But ALSA is not finished yet (Jaroslav is now ripping up the
PCM interface), there are still no MIDI+audio sequencers worth paying
attention to, let alone money for, and most of the soundfile editors
don't do some of what even the most basic Windows programs do.  Most
of us are still not even using GNOME or KDE, and if we want to, we're
not sure which one to use. People are still writing applications for
the OSS sequencer, the biggest piece of crap I ever saw that had the
name "sequencer" on it. There are still no pro-audio cards properly
supported. You can't do 96KHz recording on anything yet, and its not
even clear if 24bit will work on those cards that can do it.  To make
things work properly, you need root priviledges to use SCHED_FIFO.

I mean, come on ! Who am I fooling ? Who are we fooling ?

\end{rant}

We now return to our regularly published schedule ...




From - Wed Sep 29 20:37:53 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA22200
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 19:22:47 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA13610 for linux-audio-dev-list; Wed, 29 Sep 1999 18:54:41 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA13607 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 18:54:29 -0400
Received: from someip.ppp.op.net (d-bm2-13.ppp.op.net [209.152.194.51]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id SAA06897 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 18:49:44 -0400 (EDT)
Message-Id: <199909292249.SAA06897@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress? 
In-reply-to: Your message of "Wed, 29 Sep 1999 23:53:29 +0200."
             <99093000175401.00437@localhost.localdomain> 
Date: Wed, 29 Sep 1999 19:45:54 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d643664f35a9342c0bc90ec267be3d62

>> real hardware consoles, and its going to be a while before Linux or
>> any other non-custom OS is going to be capable of running that kind of
>> beast with 48 or 64 channels of 48KHz+ audio.
>
>Why? Lack of DSP power in workstation CPUs, lack of hard RT support with
>protected memory, or what?

Mostly too much multitasking for a CPU-like system. Digital mixers
don't use 1 or 2 or 4 or 16 processors: there are hundreds of little
doo-hickeys in there handling switch inputs, doing displays,
etc. along with the DSP's that actually chomp the data. Dealing with
all that stuff *correctly* on, say, 1-4 CPU's is going to cause too
much interrupt overhead/task switching to guarantee good audio
streaming.

>Hah! Well, I don't blame them... And in this case, it's the _Paris_ doing the
>processing with dedicated DSPs. (That's why it's actually rather usable,
>compared to most all native solutions.) The P-III 800 is only doing the disk
>I/O and the GUI! What a waste...

Heh. Remember: Windows on *4* monitors ... thats why the system was
cryo-cooled :)

--p


From - Wed Sep 29 22:37:42 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA01304
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 20:39:23 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA13928 for linux-audio-dev-list; Wed, 29 Sep 1999 20:04:58 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA13925 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 20:04:55 -0400
Received: from localhost.localdomain (d212-151-36-200.swipnet.se [212.151.36.200]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA06756; 
          Thu, 30 Sep 1999 02:00:12 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] linux audio demonstrability: NOT!
Date: Thu, 30 Sep 1999 01:47:07 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199909292345.TAA15580@op.net>
MIME-Version: 1.0
Message-Id: <99093002064009.00437@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id CAA06756
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA01304
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3a04d922067c596a332fc7e68c782265

On Thu, 30 Sep 1999, Paul Barton-Davis wrote:
[...]
> Can you suggest an even vaguely exciting and believable demo of
> anything to do with audio under Linux ? Something that would get a guy
> from a company like Steinberg or Creamware or Digidesign excited ?
> 
> Yes, we (and particularly *I*) can talk all day about plugin API
> design, but the simple fact right now is that the emperor has no
> clothes!

...but he sure has a healthy, muscular body these days... :-)

[...lots of examples of half-finished projects and unstable applications...]

> I mean, come on ! Who am I fooling ? Who are we fooling ?

We aren't really fooling anyone, as long as we just say that we have one of the
best foundations around for low latency audio and similar stuff.

But we've sure got a h*ll of a lot of work left to do. That's why I think it's
*very* important to join forces, and try to turn Linux Audio into a real
_community_, rather than a bunch of little projects and applications that
can't even work together in any sensible way. There's still no underlying
multimedia infrastructure, and not even a usable plug-in API! And the most
important point with Open Source is partly failing: Code reuse. How many
plug-ins (or built-in modules) that do the exact same thing, exist out
there...? Ok, some duplication/competition can be good for quality, but most of
these projects aren't even in a state where they can compete in any way.

So, lets get on with this design work, and make damn sure it results in
something that most of us will use and support.

Working in this direction will most likely result in some projects dying or
disappearing into other projects... But how many Linux kernel branches are
there? And how many wants to fork Linux for valid reasons?


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Sep 29 22:37:44 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA02411
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 20:46:03 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA13969 for linux-audio-dev-list; Wed, 29 Sep 1999 20:13:07 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA13966 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 20:13:04 -0400
Received: from localhost.localdomain (d212-151-36-200.swipnet.se [212.151.36.200]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA08865; 
          Thu, 30 Sep 1999 02:08:21 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
Date: Thu, 30 Sep 1999 02:07:43 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199909292249.SAA06897@renoir.op.net>
MIME-Version: 1.0
Message-Id: <9909300214500A.00437@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id CAA08865
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA02411
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 66d0ce48bebf9e765477aaf02ff2d635

On Thu, 30 Sep 1999, Paul Barton-Davis wrote:
> >> real hardware consoles, and its going to be a while before Linux or
> >> any other non-custom OS is going to be capable of running that kind of
> >> beast with 48 or 64 channels of 48KHz+ audio.
> >
> >Why? Lack of DSP power in workstation CPUs, lack of hard RT support with
> >protected memory, or what?
> 
> Mostly too much multitasking for a CPU-like system. Digital mixers
> don't use 1 or 2 or 4 or 16 processors: there are hundreds of little
> doo-hickeys in there handling switch inputs, doing displays,
> etc. along with the DSP's that actually chomp the data. Dealing with
> all that stuff *correctly* on, say, 1-4 CPU's is going to cause too
> much interrupt overhead/task switching to guarantee good audio
> streaming.

Latency... That's why I want to run my engine on RTLinux. And, different jobs
should be split over separate machines, or at least locked to specific CPUs, not
distributed over all CPUs. True, now we're not talking about a normal
multiuser, multitasking desktop/server OS, but it's still the same (main
stream == cost efficient) hardware. And most of these "tricks" can already be
done with RTLinux.

> >Hah! Well, I don't blame them... And in this case, it's the _Paris_ doing the
> >processing with dedicated DSPs. (That's why it's actually rather usable,
> >compared to most all native solutions.) The P-III 800 is only doing the disk
> >I/O and the GUI! What a waste...
> 
> Heh. Remember: Windows on *4* monitors ... thats why the system was
> cryo-cooled :)

*hehe* I see...

But what about one box for the audio work, and one for the GUI? Oh, right,
Windoze... :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Oct  1 01:08:40 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA29128
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 18:51:46 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA03494 for linux-audio-dev-list; Thu, 30 Sep 1999 18:23:44 -0400
Received: from heroine.tampa.fl.us (alpha-iota97.resnet.usf.edu [131.247.220.97]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id SAA03491 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 18:23:42 -0400
Received: (qmail 8108 invoked from network); 30 Sep 1999 00:09:18 -0000
Received: from localhost (HELO earthling.net) (root@127.0.0.1)
  by localhost with SMTP; 30 Sep 1999 00:09:18 -0000
Message-ID: <37F2AA2E.1C205B23@earthling.net>
Date: Wed, 29 Sep 1999 20:09:18 -0400
From: Adam Williams <broadcast@earthling.net>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] linux audio demonstrability
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0568e2df25f7cf7c5c3806578c1fe5e4

You can't expect digital audio software companies to delight in seeing
intense competition on Linux.  Would Adobe have discontinued their SGI
port of Photoshop if they didn't see The Gimp running on SGI?

What you're thinking is that by showing off a razzle dazzle competitor
you'll convince Steinberg that the fundamental system services and
programming frameworks exist to write clean software on Linux.  What the
suits are thinking is that the only people using Linux are computer
scientists who want to learn fundamental system services and programming
frameworks, not musicians.

I've often asked the same question after every trade show.  Why does
no-one demonstrate razzle dazzle multimedia software at Linux trade
shows but instead demonstrates an xterm runnine pine or Netscape
displaying a spreadsheet year after year.  You can ask why Linux OEMs
wouldn't be caught dead promoting their products as anything but a back
room number crunchers.  Your requests for razzle dazzle demonstrations
will go unanswered and promptly deleted from Slashdot's submission box.

The point is, Linux hackers don't want razzle dazzle comprehensive
programs.  They want to learn about computer science.  You're better off
showing the audio software suits market demographics and the fact that
no competition exists on Linux, instead of how great the ioctl interface
of some basic system services are.
-- 
                               Heroine Virtual
                        freeyellow.com/members4/heroine
                      Render the impossible into reality

From - Wed Sep 29 22:37:47 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA02653
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 20:47:43 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA14002 for linux-audio-dev-list; Wed, 29 Sep 1999 20:19:38 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA13999 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 20:19:35 -0400
Received: from someip.ppp.op.net (d-bm3-02.ppp.op.net [209.152.194.66]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id UAA12844 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 20:14:53 -0400 (EDT)
Message-Id: <199909300014.UAA12844@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] linux audio demonstrability: NOT! 
In-reply-to: Your message of "Wed, 29 Sep 1999 16:01:56 PDT."
             <Pine.LNX.4.10.9909291600590.14397-100000@anime.net> 
Date: Wed, 29 Sep 1999 21:11:03 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e1793a6f63819a3e4a44d915a4c34524

>You cant have apps without hardware. You cant have hardware without apps.

Cubase VST, Cakewalk, Cool Edit Pro ... the list goes on ... all
these apps work without any special hardware. My 15yr old brother has
Cubase running with a SoundBlaster card. We don't need cool hardware
to write cool applications, though sure, cooler hardware can enable
even cooler applications. 

There just aren't enough of us scratching one big itch in the right
way.

>Bitching about lacking one or the other is pointless.

Agreed. Just a bad day.

--p

From - Thu Sep 30 01:28:12 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA04567
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 01:18:27 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA14200 for linux-audio-dev-list; Wed, 29 Sep 1999 22:12:06 -0400
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id WAA14197 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 22:12:02 -0400
Message-Id: <199909300212.WAA14197@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: mutex madness
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Wed, 29 Sep 1999 22:06:35 -0400 (EDT)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 96d7f30dd7dce43360a04eb664ec1c7d

I haven't been able to keep up with the plug-in architecture
discussion, so maybe this has already been brought up.  What about
sending events via lock-free queues?

One hassle is that they're single-reader/single-writer, which if
people have been talking about many-to-many communication will be
annoying (we're using them now for three-to-three -- only
quadratically annoying).  But one-to-many is what I'm imagining.

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Wed Sep 29 23:27:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA24593
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 23:14:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA14229 for linux-audio-dev-list; Wed, 29 Sep 1999 22:29:16 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA14226 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 22:29:08 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id WAA25326
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 22:23:19 -0400 (EDT)
Received: from localhost by ux02 (8.9.1b+Sun) id WAA08049; Wed, 29 Sep 1999 22:23:15 -0400 (EDT)
Date: Wed, 29 Sep 1999 22:23:04 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] mutex madness
In-Reply-To: <19990929203429.26742.qmail@hyperreal.org>
Message-ID: <Pine.GSO.4.10.9909292217320.7955-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 6c0fd3edc195f7248db5700510e0b9b8

On Wed, 29 Sep 1999 est@hyperreal.org wrote:

> Indeed.  pthread mutexes aren't `fair'.  If the ui gets 500 events
> behind it's entirely possible it will hog the mutex as it wraps a lock
> around each pop while the dsp is trying to push one event.

I haven't personally tried it, but the description looked interesting when
I saw it on Freshmeat:  GNU Pth, a cooperative (non-preemptive) threading
package for Posix.  

Since when you yield is your own choice in cooperative threading, could
that possibly be used to avoid the problem?  Since the original question
was about keeping a GUI thread at lower priority than a DSP engine thread,
it might be necessary to make a version of the GUI toolkit that
explicitely yields extremely frequently, but the ones in question are open
source, so we can do that, right?

Just musing,
Div.

From - Wed Sep 29 23:27:55 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA25068
	for <slinkp@ulster.net>; Wed, 29 Sep 1999 23:17:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA14250 for linux-audio-dev-list; Wed, 29 Sep 1999 22:41:12 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA14247 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 22:41:09 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id WAA26272
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 22:34:32 -0400 (EDT)
Received: from localhost by ux02 (8.9.1b+Sun) id WAA08132; Wed, 29 Sep 1999 22:34:28 -0400 (EDT)
Date: Wed, 29 Sep 1999 22:34:26 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
In-Reply-To: <Pine.LNX.4.10.9909291520001.13878-100000@anime.net>
Message-ID: <Pine.GSO.4.10.9909292228460.7955-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 38b66e21490c87b9c681149c84159ce1

On Wed, 29 Sep 1999, Dan Hollis wrote:

> It is suprisingly easy to crash midi devices by sending bogus commands, or
> even sending them too quickly. I get the feeling that depressingly little
> testing is done on keyboards and devices before they are shipped.

Sending bogus commands I can agree with, but isn't the MIDI standard
rather specific about the data rate?  It _is_ a wire-level serial protocol
after all, and it even uses its own custom transfer rate, lest you confuse
it with more common wire-level serial protocols like RS-232.  I'd be
appalled if a professional MIDI instrument couldn't handle that rate.

Div.

P.S.  Dan, I haven't forgotten about the Alpha benchmark tests I promised,
I just haven't had access to a machine at work that wasn't bogged down
running search engine tests.  (Not too fair to run both at once, right?)

From - Thu Sep 30 01:58:13 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA06625
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 01:47:01 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA14282 for linux-audio-dev-list; Wed, 29 Sep 1999 22:57:39 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA14279 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 22:57:36 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id WAA27459;
	Wed, 29 Sep 1999 22:50:56 -0400 (EDT)
Received: from localhost by ux02 (8.9.1b+Sun) id WAA08373; Wed, 29 Sep 1999 22:50:53 -0400 (EDT)
Date: Wed, 29 Sep 1999 22:50:51 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: Dan Hollis <goemon@sasami.anime.net>
cc: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] linux audio demonstrability: NOT!
In-Reply-To: <Pine.LNX.4.10.9909291600590.14397-100000@anime.net>
Message-ID: <Pine.GSO.4.10.9909292239520.7955-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 6aeda6248059956ed18029dbe66486fe

On Wed, 29 Sep 1999, Dan Hollis wrote:

> You cant have apps without hardware. You cant have hardware without apps.
> Bitching about lacking one or the other is pointless.

At least we can comparitively easily do something about the software side.
Not too many people can sit down and build a pro-audio card from scratch,
although I remember reading about one project on DLP's page that's trying
to do just that.  You can always write software that expects better
hardware to come along and catch up with it in a year.  Why else would I
be silly enough to try writing a sequencer in Java?  

Similarly, I think it's great that the ALSA and other low-level APIs don't
place limits on audio sample rates and bit depths or number of I/O
channels just to make them match today's sound cards.  The same APIs, and
thus the higher-level software we write that uses them, should be able to
work just as nicely when 16 channel, 96 bit, 48 kHz cards are as common,
well-supported, and inexpensive as Sound Blasters are today.

Does that make us eggs or chickens?
Div.

From - Thu Sep 30 00:18:14 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA30365
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 00:03:33 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA14345 for linux-audio-dev-list; Wed, 29 Sep 1999 23:19:28 -0400
Received: from anime.net (anime.net [205.139.105.150]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA14342 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Sep 1999 23:19:24 -0400
Received: from localhost (goemon@localhost)
	by anime.net (8.9.3/8.9.3) with ESMTP id UAA17602;
	Wed, 29 Sep 1999 20:14:40 -0700
Date: Wed, 29 Sep 1999 20:14:40 -0700 (PDT)
From: Dan Hollis <goemon@sasami.anime.net>
X-Sender: goemon@anime.net
To: David Slomin <dgslomin@CS.Princeton.EDU>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
In-Reply-To: <Pine.GSO.4.10.9909292228460.7955-100000@ux02.CS.Princeton.EDU>
Message-ID: <Pine.LNX.4.10.9909292013230.17575-100000@anime.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 6e4793a1bd2a4c5ce355f85b75ba7a2a

On Wed, 29 Sep 1999, David Slomin wrote:
> I'd be appalled if a professional MIDI instrument couldn't handle that
> rate.

Be prepared to be apalled. Ive crashed midi devices from many vendors by
sending perfectly legal commands at high rates.

-Dan

From - Thu Sep 30 03:23:28 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id DAA11101
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 03:11:40 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id CAA01467 for linux-audio-dev-list; Thu, 30 Sep 1999 02:33:04 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA01464 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 02:33:01 -0400
Received: from ulster.net (port106.ts2.ulster.net [208.242.164.106])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id CAA09119
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 02:28:18 -0400
Message-ID: <37F304B2.31EA598C@ulster.net>
Date: Thu, 30 Sep 1999 02:35:30 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] linux audio demonstrability: NOT!
References: <Pine.GSO.4.10.9909292239520.7955-100000@ux02.CS.Princeton.EDU>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: a68858312f970116176cb30a57ab086d

David Slomin wrote:
> (snip) when 16 channel, 96 bit, 48 kHz cards are as common,
> well-supported, and inexpensive as Sound Blasters are today.

Let's hope they aren't also as _crappy_ as Sound Blasters are today.

The digital side of things may continue to evolve at an astonishing
rate, but that doesn't seem to be the case with the analog stuff. I have
a hard time imagining a future in which I'd want the 16 channels of
jacks, filter caps, op-amps, etc. that $100 would buy you...

but we can dream, of course!

-- 

----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Thu Sep 30 14:34:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id EAA14880
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 04:29:32 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id DAA01665 for linux-audio-dev-list; Thu, 30 Sep 1999 03:57:31 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA01662 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 03:57:28 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46512AbPI3Hw1>; Thu, 30 Sep 1999 10:52:27 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] 3D audio?
Message-Id: <19990930075235Z46512-608+249@nic.funet.fi>
Date:   Thu, 30 Sep 1999 10:52:27 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 169dd8a0002c22da4f5fd12e5a16b8de

I have made some experiments with 3D audio with headphones. I have
a GUI where I move the source around while the effect is heard in
realtime.

Is somebody else working on 3D audio at this practical level?

By the way, would somebody please shortly describe how 4 speaker
system is used: one stream, four channels interleaved? I plan to
experiment with that kind of 3D audio too.

Yours,

Juhana

From - Thu Sep 30 14:34:03 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id EAA16285
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 04:58:57 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id EAA01913 for linux-audio-dev-list; Thu, 30 Sep 1999 04:30:40 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA01909 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 04:30:38 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46230AbPI3IZf>; Thu, 30 Sep 1999 11:25:35 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <199909292345.TAA15580@op.net> (message from Paul Barton-Davis on
	Wed, 29 Sep 1999 19:45:50 -0400)
Subject: Re: [linux-audio-dev] linux audio demonstrability: NOT!
Message-Id: <19990930082545Z46230-604+222@nic.funet.fi>
Date:   Thu, 30 Sep 1999 11:25:35 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 06b4df835de99c34be47aaabba30ba1d

>From:   Paul Barton-Davis <pbd@Op.Net>
>
>Something that would get a guy
>from a company like Steinberg or Creamware or Digidesign excited ?

Personally I care less what they are doing. What I want is that proaudio
card manufacturers would provide info for making Linux drivers.

If those people at Creamware etc. cannot see the potentials of Linux,
it is their loss. If they expect *we* should first come up with cool
programs without any salary, with plain volunteer work, they are grazy.
They should be satisfied about what exists and understand our position
as software authors.

>I have a meeting with the east coast Creamware rep next week,
>and although its not the purpose of our meeting, I may get to do
>a little Linux demo for him. What would I show him?

Show a half finished realtime audio application and non-realtime editor
whatever. Show again that latency test. Bright fellow there then sure
understand what those mean for them.

>stuff. But ALSA is not finished yet (Jaroslav is now ripping up the
>PCM interface),

I'm still using 3 years old Linux version without full-duplex etc.
I think I change when Alsa is a part of the kernel.

Yours,

Juhana

From - Thu Sep 30 14:34:08 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id FAA18980
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 05:54:54 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA01985 for linux-audio-dev-list; Thu, 30 Sep 1999 05:11:48 -0400
Received: from maelzel.ircam.fr (maelzel.ircam.fr [129.102.1.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA01982 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 05:11:43 -0400
Received: from luc.ircam.fr (luc.ircam.fr [129.102.1.64])
Received: from ircam.fr (linotte.ircam.fr [129.102.1.213])
          by luc.ircam.fr (8.9.1/jtpda-5.3.1/ircam) with ESMTP id LAA17804
          ; Thu, 30 Sep 1999 11:07:05 +0200 (MET DST)
Message-ID: <37F32839.2FBEDABF@ircam.fr>
Date: Thu, 30 Sep 1999 11:07:05 +0200
From: Francois Dechelle <Francois.Dechelle@ircam.fr>
X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686)
MIME-Version: 1.0
To: Juhana Sadeharju  <kouhia@nic.funet.fi>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] 3D audio?
References: <19990930075235Z46512-608+249@nic.funet.fi>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by maelzel.ircam.fr id LAA26471
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id FAA18980
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: fbbaf5af436d2f3b03f8c2daeadf9413

Juhana Sadeharju wrote:
> 
> I have made some experiments with 3D audio with headphones. I have
> a GUI where I move the source around while the effect is heard in
> realtime.
> 
> Is somebody else working on 3D audio at this practical level?
> 
> By the way, would somebody please shortly describe how 4 speaker
> system is used: one stream, four channels interleaved? I plan to
> experiment with that kind of 3D audio too.
> 
> Yours,
> 
> Juhana

Juhana,

There is the Spatialisateur (a library of jMax patches), developped
at Ircam, that does 3D audio and can be configured for headphones
or speakers (any number). It is widely used in Ircam productions.
However, it is not free (it is an  application developped with 
jMax, not a part of jMax) and it is distributed by the Ircam forum:
http://www.ircam.fr/produits/logiciels/log-forum/spat-e.html

About the encoding of the audio stream, I don't know much: it looks 
like there are several standards (Ambisonics is one of them)
and there is usually a stage that translates the output of
the 3D audio processor to the diffusion system format (this
is part of the Spatialisateur).

Franois

From - Thu Sep 30 14:34:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA19639
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 06:05:55 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA02026 for linux-audio-dev-list; Thu, 30 Sep 1999 05:47:21 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA02023 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 05:47:19 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46374AbPI3Jm3>; Thu, 30 Sep 1999 12:42:29 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <37F32839.2FBEDABF@ircam.fr> (message from Francois Dechelle on
	Thu, 30 Sep 1999 11:07:05 +0200)
Subject: Re: [linux-audio-dev] 3D audio?
Message-Id: <19990930094229Z46374-608+250@nic.funet.fi>
Date:   Thu, 30 Sep 1999 12:42:29 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 45f8d9cf94c4c306aea164bb40cf70e8

>From:   Francois Dechelle <Francois.Dechelle@ircam.fr>
>
>There is the Spatialisateur (a library of jMax patches), developped
[ ... ]
>However, it is not free (it is an  application developped with 

I'm in believ it uses Jot's patented FDN reverb etc. system.
I have IRCAM reports on them.

I found Space program which computes early echoes from given geometry
but I yet don't know details of it.

Juhana

From - Thu Sep 30 14:34:11 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA21954
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 06:46:28 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA02088 for linux-audio-dev-list; Thu, 30 Sep 1999 06:10:54 -0400
Received: from maelzel.ircam.fr (maelzel.ircam.fr [129.102.1.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA02085 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 06:10:51 -0400
Received: from luc.ircam.fr (luc.ircam.fr [129.102.1.64])
Received: from ircam.fr (linotte.ircam.fr [129.102.1.213])
          by luc.ircam.fr (8.9.1/jtpda-5.3.1/ircam) with ESMTP id MAA18169
          ; Thu, 30 Sep 1999 12:06:12 +0200 (MET DST)
Message-ID: <37F33614.22F7C2EB@ircam.fr>
Date: Thu, 30 Sep 1999 12:06:12 +0200
From: Francois Dechelle <Francois.Dechelle@ircam.fr>
X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686)
MIME-Version: 1.0
To: Juhana Sadeharju <kouhia@nic.funet.fi>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] 3D audio?
References: <19990930094229Z46374-608+250@nic.funet.fi>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by maelzel.ircam.fr id MAA07947
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id GAA21954
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e349fb19f738074e122a4b591ce61ce6

Juhana Sadeharju wrote:
> 
> >From:   Francois Dechelle <Francois.Dechelle@ircam.fr>
> >
> >There is the Spatialisateur (a library of jMax patches), developped
> [ ... ]
> >However, it is not free (it is an  application developped with
> 
> I'm in believ it uses Jot's patented FDN reverb etc. system.
> I have IRCAM reports on them.
> 
> I found Space program which computes early echoes from given geometry
> but I yet don't know details of it.
> 
> Juhana


Spatialisateur does use Jot's patent. It was developped by Jot...

There may be some information on 3D audio in :
http://www.ircam.fr/equipes/salles/

Franois

From - Thu Sep 30 14:34:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA06439
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 09:28:41 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA02265 for linux-audio-dev-list; Thu, 30 Sep 1999 08:46:58 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA02262 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 08:46:56 -0400
Received: from someip.ppp.op.net (d-bm2-1b.ppp.op.net [209.152.194.59]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id IAA19779 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 08:42:19 -0400 (EDT)
Message-Id: <199909301242.IAA19779@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Plug-in API progress? 
In-reply-to: Your message of "Wed, 29 Sep 1999 20:14:40 PDT."
             <Pine.LNX.4.10.9909292013230.17575-100000@anime.net> 
Date: Thu, 30 Sep 1999 09:38:37 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 07bf43d20f8d19299871b0ea0bd20613

>> I'd be appalled if a professional MIDI instrument couldn't handle that
>> rate.
>
>Be prepared to be apalled. Ive crashed midi devices from many vendors by
>sending perfectly legal commands at high rates.

Not to mention those that crash on startup if there is MIDI data
arriving during their boot sequence, or those that get totally locked
up if MIDI clock messages arrive during their initialization
(Oberheim Matrix 6 and Kawai K5000S respectively).

From - Thu Sep 30 14:34:47 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA09287
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 09:45:28 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA02290 for linux-audio-dev-list; Thu, 30 Sep 1999 09:02:16 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA02287 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 09:02:14 -0400
Received: from someip.ppp.op.net (d-bm2-1b.ppp.op.net [209.152.194.59]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id IAA20987 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 08:57:36 -0400 (EDT)
Message-Id: <199909301257.IAA20987@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] linux audio demonstrability: NOT! 
In-reply-to: Your message of "Thu, 30 Sep 1999 11:25:35 +0300."
             <19990930082545Z46230-604+222@nic.funet.fi> 
Date: Thu, 30 Sep 1999 09:53:55 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e058d7290f9c9f5457ef2594ddff202d

>>Something that would get a guy
>>from a company like Steinberg or Creamware or Digidesign excited ?
>
>Personally I care less what they are doing. What I want is that proaudio
>card manufacturers would provide info for making Linux drivers.
>
>If those people at Creamware etc. cannot see the potentials of Linux,
>it is their loss. If they expect *we* should first come up with cool
>programs without any salary, with plain volunteer work, they are grazy.

Juhana - although I understand these sentiments, I see a contradiction
in your position. You seem to be suggesting that its unreasonable to
expect a bunch of unpaid volunteers to write cool audio
applications. But you also seem to suggest that you don't care if
Creamware or Steinberg or Digidesign or whoever choose not to write
cool audio applications for Linux.

So, who *is* going to write them ? 

--p

From - Thu Sep 30 14:34:51 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA10079
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 09:50:07 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA02367 for linux-audio-dev-list; Thu, 30 Sep 1999 09:26:52 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA02364 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 09:26:50 -0400
Received: from someip.ppp.op.net (d-bm2-1b.ppp.op.net [209.152.194.59]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id JAA21839 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 09:06:24 -0400 (EDT)
Message-Id: <199909301306.JAA21839@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] mutex madness 
In-reply-to: Your message of "Wed, 29 Sep 1999 22:23:04 EDT."
             <Pine.GSO.4.10.9909292217320.7955-100000@ux02.CS.Princeton.EDU> 
Date: Thu, 30 Sep 1999 10:02:42 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ff3aa5b298cd2e23db4ccfd33ea24dee

>that possibly be used to avoid the problem?  Since the original question
>was about keeping a GUI thread at lower priority than a DSP engine thread,
>it might be necessary to make a version of the GUI toolkit that
>explicitely yields extremely frequently, but the ones in question are open
>source, so we can do that, right?

no.

Linux GUI toolkits all talk to X. They could block indefinitely during
communication with the server, and there is nothing that any thread
package could do about it.

Also, when I think about keeping a GUI thread at a lower priority than
the DSP engine thread, I am thinking about kernel threads with system
scope scheduling, not user level threads with process scope
scheduling. To manage the relative priority of a GUI and a DSP thread
from user space implies switching the GUI and DSP user threads on and
off the same kernel thread(s). If you're using an SMP system, this is
a bad idea.

--p

From - Thu Sep 30 14:34:46 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA08006
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 09:37:44 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA02332 for linux-audio-dev-list; Thu, 30 Sep 1999 09:12:42 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA02329 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 09:12:40 -0400
Received: from someip.ppp.op.net (d-bm2-1b.ppp.op.net [209.152.194.59]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id JAA21970 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 09:08:01 -0400 (EDT)
Message-Id: <199909301308.JAA21970@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: mutex madness 
In-reply-to: Your message of "Wed, 29 Sep 1999 22:06:35 EDT."
             <199909300212.WAA14197@ginette.musique.umontreal.ca> 
Date: Thu, 30 Sep 1999 10:04:20 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4194fac2df81b35e7614d21fb31df934

In message <199909300212.WAA14197@ginette.musique.umontreal.ca>you write:
>I haven't been able to keep up with the plug-in architecture
>discussion, so maybe this has already been brought up.  What about
>sending events via lock-free queues?

is this related to herlihy's wait free synchronization, or something
else ? i've been out of that threads/locks/OS loop for quite a few
years. is there something *excellent* that we should know ?

--p

From - Thu Sep 30 14:34:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA07858
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 09:36:51 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA02351 for linux-audio-dev-list; Thu, 30 Sep 1999 09:17:13 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA02348 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 09:17:11 -0400
Received: from someip.ppp.op.net (d-bm2-1b.ppp.op.net [209.152.194.59]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id JAA22465 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 09:12:33 -0400 (EDT)
Message-Id: <199909301312.JAA22465@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] 3D audio? 
In-reply-to: Your message of "Thu, 30 Sep 1999 10:52:27 +0300."
             <19990930075235Z46512-608+249@nic.funet.fi> 
Date: Thu, 30 Sep 1999 10:08:52 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 068d287477b13bf827944c9a1a77c94b

In message <19990930075235Z46512-608+249@nic.funet.fi>you write:
>I have made some experiments with 3D audio with headphones. I have
>a GUI where I move the source around while the effect is heard in
>realtime.

Be sure to check out the Nuendo interface for this. I imagine that
Steinberg has a .pdf file of the neundo brochure online. You can add
speakers at will, drag them around, then position the sound. It also
switches between an azimuth based view and a birds-eye view. Nuendo
makes a lot of claims about its ability to handle surround sound - it
would be worth finding out as much as possible about what they do.

>By the way, would somebody please shortly describe how 4 speaker
>system is used: one stream, four channels interleaved? I plan to
>experiment with that kind of 3D audio too.

Surround seems to have been a *hot* topic at AES this year. I take it
that you know about the various standards: 5.1, 7.1 etc ? I don't, but
I know they exist. Presumably there is some documentation on them
online somewhere. They cover surround sound with various specified
speaker configurations; 5.1 for example is 4 speakers plus a subwoofer.
Apparently, the home audio ("theater") industry sees a whole new way
to make money here, convincing us all that stereo is inadequate :(

--p

From - Thu Sep 30 14:34:58 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA16572
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 10:30:13 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA02414 for linux-audio-dev-list; Thu, 30 Sep 1999 09:47:37 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA02411 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 09:47:34 -0400
Received: from bright.net (find-cas1-cs-18.dial.bright.net [209.143.26.121])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id JAA13828;
	Thu, 30 Sep 1999 09:42:49 -0400 (EDT)
Message-ID: <37F37087.E0F10B3D@bright.net>
Date: Thu, 30 Sep 1999 10:15:35 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Barton-Davis <pbd@Op.Net>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] linux audio demonstrability: NOT!
References: <199909301257.IAA20987@renoir.op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d402dd0192b56d6d3ba45c52340eec33

Paul Barton-Davis wrote:

> Juhana - although I understand these sentiments, I see a contradiction
> in your position. You seem to be suggesting that its unreasonable to
> expect a bunch of unpaid volunteers to write cool audio
> applications. But you also seem to suggest that you don't care if
> Creamware or Steinberg or Digidesign or whoever choose not to write
> cool audio applications for Linux.
> 
> So, who *is* going to write them ?

It seems to me that you guys are already writing those programs.

I hope to see the time when people will look at the come-lately
commercial Linux soundapps and say, "Why pay that kind of money for
Steinware's Cakebase when I can get Quasiwalk for free ?". 

<counter-rant>
Regarding Linux audio applications in general: Of course there are very
few that demonstrate the maturity of a Cakewalk or Cubase. CW has been
in continuous development for what, 15 years ?! Even older apps such as
Snd or the NoTAM things were not originally running under Linux, and I
don't expect them to show a perfect fit, not yet anyway. So much of the
support software (GUI toolkits, libraries and APIs, et cetera) is in
similar condition: I don't expect LessTif to be perfect yet, but dang, I
gotta love that open-source when Bill S can fix a problem with LessTif
that hung me up in Snd. Can't do that with Cool Edit and Windoze, and we
all know it.

My point is: Don't be discouraged ! We're getting there ! It took MS-DOS
MIDI software a *long* time before evolving into its present forms (for
those who are relatively new to it all, Cakewalk and Digital
Orchestrator Plus both began as DOS apps). And there were dozens of
smaller (and some not-so-small) utility apps that never made the jump
and have disappeared completely (the Bacchus editors, the great software
from Cool Shoes, lots of other freeware projects). When I started the
Linux Soundapps page it held about 40 applications: it currently lists
more than ten times that number (not all apps, to be sure, but most of
the page is indeed applications listings).

As wisdom has it, "Perseverance furthers" and "An inch of meditation, an
inch of Buddha". We *are* persevering, inch by inch, and perhaps in the
end we will wind up with the most superbly outfit platform for audio.
And we will have made it that way, not the Steinburgers or Cakewanks.
And it will be open-source and freely available, a path not bloody
likely to be chosen by those people.
</counter-rant>

But we do want those cards, don't we ?  ;)

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Thu Sep 30 14:35:03 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA13800
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 13:40:03 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA02800 for linux-audio-dev-list; Thu, 30 Sep 1999 13:10:15 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA02797 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 13:10:12 -0400
From: est@hyperreal.org
Received: (qmail 2982 invoked by uid 162); 30 Sep 1999 17:05:44 -0000
Message-ID: <19990930170544.2981.qmail@hyperreal.org>
Subject: [linux-audio-dev] lock-free queues
In-Reply-To: <199909301308.JAA21970@renoir.op.net> from Paul Barton-Davis at
 "Sep 30, 1999 10:04:20 am"
To: Paul Barton-Davis <pbd@Op.Net>
Date: Thu, 30 Sep 1999 10:05:44 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: ccafbffb318f0c08da02b2699d844893

Paul Barton-Davis discourseth:
> In message <199909300212.WAA14197@ginette.musique.umontreal.ca>you write:
> >I haven't been able to keep up with the plug-in architecture
> >discussion, so maybe this has already been brought up.  What about
> >sending events via lock-free queues?
> [...]
> is there something *excellent* that we should know ?

www.cs.rpi.edu/~valoisj/papers/queues.html
and
www.cs.rpi.edu/~valoisj/papers/thesis.html

are interesting.  They require atomic operations that aren't portably
available.  In fact, I don't even know to what extent x86 supports
them..though I'd like to.

Eric

From - Thu Sep 30 14:35:06 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA19173
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 14:15:46 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA02869 for linux-audio-dev-list; Thu, 30 Sep 1999 13:49:59 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA02866 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 13:49:56 -0400
From: est@hyperreal.org
Received: (qmail 26155 invoked by uid 162); 30 Sep 1999 17:45:22 -0000
Message-ID: <19990930174522.26154.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] lock-free queues
In-Reply-To: <19990930170544.2981.qmail@hyperreal.org> from "est@hyperreal.org"
 at "Sep 30, 1999 10:05:44 am"
To: est@hyperreal.org
Date: Thu, 30 Sep 1999 10:45:22 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: dd9612856ff14f3a8b23b5d41e9edce3

est@hyperreal.org discourseth:
> 
> www.cs.rpi.edu/~valoisj/papers/queues.html
> and
> www.cs.rpi.edu/~valoisj/papers/thesis.html
> 
> are interesting.  They require atomic operations that aren't portably
> available.  In fact, I don't even know to what extent x86 supports
> them..though I'd like to.

Hrm..well, i486 has the compare&swap instruction.

Eric

From - Fri Oct  1 01:08:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA28246
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 15:18:03 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA03026 for linux-audio-dev-list; Thu, 30 Sep 1999 14:55:41 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id OAA03023 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 14:55:36 -0400
From: est@hyperreal.org
Received: (qmail 21973 invoked by uid 162); 30 Sep 1999 18:51:08 -0000
Message-ID: <19990930185108.21972.qmail@hyperreal.org>
Subject: [linux-audio-dev] x86 atomic operations
In-Reply-To: <199909301808.OAA25017@renoir.op.net> from Paul Barton-Davis at
 "Sep 30, 1999 03:05:13 pm"
To: Paul Barton-Davis <pbd@Op.Net>
Date: Thu, 30 Sep 1999 11:51:08 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 65df99943a48075cc4cf2134e7c90baa

Paul Barton-Davis discourseth:
> 
> yes, they use compare-and-swap, which doesn't exist on the x86 (well,
> it didn't up to the 486 - did Intel come to their senses and add it ?)

Well, here's the 486+ implementation in LinuxThreads:

PT_EI int
__compare_and_swap (long int *p, long int oldval, long int newval)
{
  char ret;
  long int readval;

  __asm__ __volatile__ ("lock; cmpxchgl %3, %1; sete %0"
                        : "=q" (ret), "=m" (*p), "=a" (readval)
                        : "r" (newval), "m" (*p), "a" (oldval)
                        : "memory");
  return ret;
}

I *think* the lock operation makes everything up to the next write
atomic.  I'd love it if someone could confirm this.  Maybe I just need
to look at an intel manual online.

Eric

From - Thu Sep 30 14:51:52 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA23033
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 14:42:06 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA02959 for linux-audio-dev-list; Thu, 30 Sep 1999 14:13:33 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA02956 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 14:13:31 -0400
Received: from someip.ppp.op.net (d-bm2-17.ppp.op.net [209.152.194.55]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id OAA25017 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 14:08:52 -0400 (EDT)
Message-Id: <199909301808.OAA25017@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: lock-free queues 
In-reply-to: Your message of "Thu, 30 Sep 1999 10:05:44 PDT."
             <19990930170544.2981.qmail@hyperreal.org> 
Date: Thu, 30 Sep 1999 15:05:13 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 88f1b2b806717f4471f155a50f2b2592

>www.cs.rpi.edu/~valoisj/papers/queues.html
>and
>www.cs.rpi.edu/~valoisj/papers/thesis.html
>
>are interesting.  They require atomic operations that aren't portably
>available.  In fact, I don't even know to what extent x86 supports
>them..though I'd like to.

yes, they use compare-and-swap, which doesn't exist on the x86 (well,
it didn't up to the 486 - did Intel come to their senses and add it ?)

--p


From - Fri Oct  1 01:08:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA12245
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 16:58:17 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA03269 for linux-audio-dev-list; Thu, 30 Sep 1999 16:19:11 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id QAA03266 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 16:19:00 -0400
From: est@hyperreal.org
Received: (qmail 2496 invoked by uid 162); 30 Sep 1999 20:14:33 -0000
Message-ID: <19990930201433.2495.qmail@hyperreal.org>
Subject: [linux-audio-dev] shared memory synchronization
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Thu, 30 Sep 1999 13:14:33 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: b7134cf6183ac53744cd9a17a1622e23

Some of the recent discussions, especially the anomalous behavior
observed by Juhana, have got me thinking about three issues involving
the use of shared memory between threads and among processors.

1) Correct volatile declarations are important.  It would be nice if C
guaranteed that these aren't needed if you have function calls between
uses of a pointer, but that doesn't seem to be the case.  BTW, on the
other end of the aliasing spectrum, c9x has a `restrict' type
qualifier that allows the programmer to provide guarantees against
aliasing.

2) Multiprocessor cache synchronization.  POSIX guarantees that
certain operations (e.g., pthread_mutex_lock()) will cause this to
occur.  Do they under linux?  Does the lock/cmpxchgl operation used
by linuxthreads, for example, cause this to happen?  This is very
important to me as I'm working on SMP-friendly approaches to garbage
collection and problems here will cause more than imperceptible audio
glitches.

3) What can you atomically read/write without synchronization?  The
appended autoconf macro provides a non-guaranteed-but-probably-OK way
of double-checking assumptions in this area.

Eric

dnl AC_CHECK_ATOMICITY(TYPE)
AC_DEFUN(AC_CHECK_ATOMICITY,
[changequote(<<, >>)dnl
dnl The name to #define.
define(<<AC_TYPE_NAME>>, translit(atomic_$1, [a-z *], [A-Z_P]))dnl
dnl The cache variable name.
define(<<AC_CV_NAME>>, translit(ac_cv_atomic_$1, [ *], [_p]))dnl
changequote([, ])dnl
AC_MSG_CHECKING(atomicity of $1)
AC_CACHE_VAL(AC_CV_NAME,
[AC_TRY_RUN([#include <stdio.h>
#include <signal.h>

main()
{
  FILE *f=fopen("conftestval", "w");
  if (!f) exit(1);
  fprintf(f, "%s\n", (sizeof($1) > sizeof(sig_atomic_t)) ? "no" : "yes");
  exit(0);
}], AC_CV_NAME=`cat conftestval`, AC_CV_NAME=0, ifelse([$2], , , AC_CV_NAME=$2)\)])dnl
AC_MSG_RESULT($AC_CV_NAME)
AC_DEFINE_UNQUOTED(AC_TYPE_NAME, $AC_CV_NAME)
undefine([AC_TYPE_NAME])dnl
undefine([AC_CV_NAME])dnl
])

From - Fri Oct  1 01:08:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA18121
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 17:37:31 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA03338 for linux-audio-dev-list; Thu, 30 Sep 1999 17:04:44 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA03334 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 17:04:24 -0400
Received: from localhost.localdomain (d212-151-86-13.swipnet.se [212.151.86.13]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id WAA01145; 
          Thu, 30 Sep 1999 22:59:16 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: eli+@cs.cmu.edu, Eli Brandt <eli@v.gp.cs.cmu.edu>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: mutex madness
Date: Thu, 30 Sep 1999 23:01:13 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199909300212.WAA14197@ginette.musique.umontreal.ca>
MIME-Version: 1.0
Message-Id: <99093023054602.00439@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id WAA01145
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id RAA18121
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e115259bd61d404cc96c15b4d3e477e7

On Thu, 30 Sep 1999, Eli Brandt wrote:
> I haven't been able to keep up with the plug-in architecture
> discussion, so maybe this has already been brought up.  What about
> sending events via lock-free queues?

I suggested that, using the standard RTLinux <-> Linux IPC solutions as an
example.

> One hassle is that they're single-reader/single-writer, which if
> people have been talking about many-to-many communication will be
> annoying (we're using them now for three-to-three -- only
> quadratically annoying).  But one-to-many is what I'm imagining.

In an engine running callback plug-ins and a single thread for each sub net,
there's no need for explicit synchronisation at all. Synchronisation is only a
problem between sub nets and between the engine and client applications.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Oct  1 01:08:43 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA05966
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 19:56:25 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA03613 for linux-audio-dev-list; Thu, 30 Sep 1999 19:28:51 -0400
Received: from mail.billgribble.com (grib.customer.jump.net [216.30.103.2]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA03610 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 19:28:48 -0400
Received: by mail.billgribble.com (Postfix, from userid 1000)
	id 6DF288DDA; Thu, 30 Sep 1999 18:24:09 -0500 (CDT)
To: est@hyperreal.org
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] shared memory synchronization
References: <19990930201433.2495.qmail@hyperreal.org>
From: Bill Gribble <grib@cs.utexas.edu>
Date: 30 Sep 1999 18:24:09 -0500
In-Reply-To: est@hyperreal.org's message of "Thu, 30 Sep 1999 13:14:33 -0700 (PDT)"
Message-ID: <87ogek6l0m.fsf@flophouse.localnet>
Lines: 26
User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f665c3961afb8cdc1625da04ef0d75b9

est@hyperreal.org writes:
> 1) Correct volatile declarations are important.  It would be nice if C
> guaranteed that these aren't needed if you have function calls between
> uses of a pointer, but that doesn't seem to be the case.  BTW, on the
> other end of the aliasing spectrum, c9x has a `restrict' type
> qualifier that allows the programmer to provide guarantees against
> aliasing.
> 
> 2) Multiprocessor cache synchronization.  POSIX guarantees that
> certain operations (e.g., pthread_mutex_lock()) will cause this to
> occur.  Do they under linux?  Does the lock/cmpxchgl operation used
> by linuxthreads, for example, cause this to happen?  This is very
> important to me as I'm working on SMP-friendly approaches to garbage
> collection and problems here will cause more than imperceptible audio
> glitches.

My understanding is that these two are an either/or proposition
in most cases.  If you faithfully use mutex synchronization of 
shared variables, volatile is always superfluous (and can be a major
performance hit).  

If someone knows better, please let me know... i have tens of KLOC
of multithreaded real-time vision code that depends on my understanding
being correct :)

Bill Gribble

From - Fri Oct  1 01:08:42 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA05514
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 19:53:07 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA03629 for linux-audio-dev-list; Thu, 30 Sep 1999 19:31:20 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id TAA03626 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 19:31:18 -0400
From: est@hyperreal.org
Received: (qmail 6924 invoked by uid 162); 30 Sep 1999 23:26:48 -0000
Message-ID: <19990930232648.6923.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] Re: mutex madness
In-Reply-To: <199909292140.RAA01345@renoir.op.net> from Paul Barton-Davis at
 "Sep 29, 1999 06:36:31 pm"
To: Paul Barton-Davis <pbd@Op.Net>
Date: Thu, 30 Sep 1999 16:26:48 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: aae7b6bd2101f888815b482a247229fd

Paul Barton-Davis discourseth:
> 
> things can more unpredictable, however, if you add one more runnable
> thread to the entire OS thread list. if this thread gets to run
> instead of the UI thread while the UI thread still holds the lock on
> the queue, then the DSP thread is out of luck, and so are we. this is
> even more likely (to the extent that it *is* likely at all) if the
> input thread is has RT scheduling.
> 
> so, the above scheme will work most of the time, but still can't
> guarantee that the dsp will get the lock when it needs to. even
> turning the mutex into a "fair" one won't help this pathological
> condition.
> 
> BTW, you could work around this by making the UI thread run
> SCHED_FIFO, but this causes a lot of other problems, especially on a
> UP system.

Assuming the dsp is given a higher static priority than the gui, what
are these problems?

Maybe a queue that makes the lock/operate/unlock atomic would be
useful..say, a pipe!  A million write()/read()s of 1 byte through a
pipe takes less than 2.5 seconds on my system..not bad.

> [...]
> so we just need to focus on designs that minimize the communication
> between threads. BTW, this is another reason for my appreciation of
> quasimodo's asynch parameter update model:

Yeah..simple is nice.  Is modification of the dsp done in real-time in
q, or is is just `interactive'?

Eric

From - Fri Oct  1 01:08:47 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA08240
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 20:11:24 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA03664 for linux-audio-dev-list; Thu, 30 Sep 1999 19:49:07 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id TAA03661 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 19:49:05 -0400
From: est@hyperreal.org
Received: (qmail 19861 invoked by uid 162); 30 Sep 1999 23:42:52 -0000
Message-ID: <19990930234252.19857.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] shared memory synchronization
In-Reply-To: <87ogek6l0m.fsf@flophouse.localnet> from Bill Gribble at "Sep 30,
 1999 06:24:09 pm"
To: Bill Gribble <grib@cs.utexas.edu>
Date: Thu, 30 Sep 1999 16:42:51 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3e5865c9084c7345da1f18d704d8262e

Bill Gribble discourseth:
> est@hyperreal.org writes:
> > 1) Correct volatile declarations are important.  It would be nice if C
> > guaranteed that these aren't needed if you have function calls between
> > uses of a pointer, but that doesn't seem to be the case.  BTW, on the
> > other end of the aliasing spectrum, c9x has a `restrict' type
> > qualifier that allows the programmer to provide guarantees against
> > aliasing.
> > 
> > 2) Multiprocessor cache synchronization.  POSIX guarantees that
> > certain operations (e.g., pthread_mutex_lock()) will cause this to
> > occur.  Do they under linux?  Does the lock/cmpxchgl operation used
> > by linuxthreads, for example, cause this to happen?  This is very
> > important to me as I'm working on SMP-friendly approaches to garbage
> > collection and problems here will cause more than imperceptible audio
> > glitches.
> 
> My understanding is that these two are an either/or proposition
> in most cases.  If you faithfully use mutex synchronization of 
> shared variables, volatile is always superfluous (and can be a major
> performance hit).  

Hmm..I can't see how that would be the case.  volatile stops the
compiler from optimizing away dereferences (e.g., via
loop-invariant-code-motion).  It could be that your mutex ops are
out-of-line and thus have the same effect, but I can't see that there
are any guarantees that that will always be the case.

> If someone knows better, please let me know... i have tens of KLOC
> of multithreaded real-time vision code that depends on my understanding
> being correct :)

Maybe you could display a code fragment illustrating this?

Eric

From - Fri Oct  1 03:58:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id DAA24644
	for <slinkp@ulster.net>; Fri, 1 Oct 1999 03:44:38 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id DAA08118 for linux-audio-dev-list; Fri, 1 Oct 1999 03:21:27 -0400
Received: from bashir.belgium.eu.net (bashir.Belgium.EU.net [193.74.208.147]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA08115 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 03:21:22 -0400
Received: from (adial098.liege.eunet.be [195.207.174.98])
	by bashir.belgium.eu.net  with SMTP id JAA29265 
	for <linux-audio-dev@ginette.musique.umontreal.ca>;
	Fri, 1 Oct 1999 09:16:36 +0200 (MET DST)
Subject: Re: [linux-audio-dev] linux audio demonstrability
From: Benjamin GOLINVAUX <golinvaux@benjamin.net>
Reply-To: Benjamin GOLINVAUX <golinvaux@benjamin.net>
In-Reply-To: <37F2AA2E.1C205B23@earthling.net>
Message-ID: <000355c779328d2d_mailit@relay.eunet.be>
References: <37F2AA2E.1C205B23@earthling.net>
Date: Fri, 01 Oct 1999 01:09:10 +0000
X-Mailer: BeatWare Mail-It 2.0.3
X-BeOS-Platform: Intel or clone
X-Priority: 3 (Normal)
To: linux-audio-dev@ginette.musique.umontreal.ca
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0f213b083f3a85bb7eec413f2b0055b5

>The point is, Linux hackers don't want razzle dazzle comprehensive
>programs.  They want to learn about computer science.  You're better off
>showing the audio software suits market demographics and the fact that
>no competition exists on Linux, instead of how great the ioctl interface
>of some basic system services are.

It will take us at least a good night to collect arguments explaining why 
Linux will be a serious OS for audio, as it is a serious OS for number 
crunching, for internet servers, slowly becoming a serious OS for 3D,......

There are not only hackers who use linux... I'm not a hacker... I never gave 
Linux any interest until I realized it could maybe turn a cheap P133 into a 
guitar fx box and multi-track recorder.

Some musically-inclined friends of mine would die to just record some tracks 
"in sync" with basic effects, on a safe OS (and possibly process the files 
later under Windows)

It it works, they'll use it... BeOS worked for audio, and Steinberg and 
others decided to allocate resources for it... That's that simple (altough it 
took Be a lot of marketing energy... They have no drivers and no apps... 
Linux has some).

Wait till someone releases a single CD with a ___basic___ linux distro with 
easy setup (its getting close nowadays) with a bunch of some decent audio 
tools... I mean Windows is ok for offline process but, for Bill's sake, don't 
use a Windows box during live recording (or worse, performance)...



Benjamin (who's ___not___ a linux hacker).



From - Fri Oct  1 01:08:55 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA31114
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 22:37:51 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA03939 for linux-audio-dev-list; Thu, 30 Sep 1999 22:20:27 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA03936 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 22:20:24 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id WAA11050
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 22:14:59 -0400 (EDT)
Received: from localhost by ux02 (8.9.1b+Sun) id WAA21291; Thu, 30 Sep 1999 22:14:57 -0400 (EDT)
Date: Thu, 30 Sep 1999 22:14:57 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] mutex madness 
In-Reply-To: <199909301306.JAA21839@renoir.op.net>
Message-ID: <Pine.GSO.4.10.9909302211060.21241-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3ef09bb3f2f483d6716755c336b7e906

On Thu, 30 Sep 1999, Paul Barton-Davis wrote:

> Also, when I think about keeping a GUI thread at a lower priority than
> the DSP engine thread, I am thinking about kernel threads with system
> scope scheduling, not user level threads with process scope
> scheduling. To manage the relative priority of a GUI and a DSP thread
> from user space implies switching the GUI and DSP user threads on and
> off the same kernel thread(s). If you're using an SMP system, this is
> a bad idea.

More proof why I should leave such low-level realtime stuff to the
experts.  :-)  Thanks.

Here's a derivative question... is there such a thing as a realtime OS
that is usable by application developers who don't want to have to think
at such a low level?  Conversations about the "evils" of using conditional
code, for example, make me as an application-level developer lose
interest.

Div.

From - Fri Oct  1 01:08:52 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA24610
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 21:55:22 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA03832 for linux-audio-dev-list; Thu, 30 Sep 1999 21:37:28 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA03829 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 21:37:26 -0400
Received: from someip.ppp.op.net (d-bm3-16.ppp.op.net [209.152.194.86]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id VAA06758 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 21:32:45 -0400 (EDT)
Message-Id: <199910010132.VAA06758@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: mutex madness 
In-reply-to: Your message of "Thu, 30 Sep 1999 16:26:48 PDT."
             <19990930232648.6923.qmail@hyperreal.org> 
Date: Thu, 30 Sep 1999 22:29:09 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 348869fa281ddb51f7add1e51a6e14db

>> BTW, you could work around this by making the UI thread run
>> SCHED_FIFO, but this causes a lot of other problems, especially on a
>> UP system.
>
>Assuming the dsp is given a higher static priority than the gui, what
>are these problems?

There are no problems. I was forgetting that even SCHED_FIFO comes
with priority levels, and imagining it to be a monolithic scheduling
class. 

>Maybe a queue that makes the lock/operate/unlock atomic would be
>useful..say, a pipe!  A million write()/read()s of 1 byte through a
>pipe takes less than 2.5 seconds on my system..not bad.

yes, i am currently working on extended Karl Nelson's libsigc++ system
for asynchronous inter-thread callbacks, and a pipe is a key element
of this.

>> [...]
>> so we just need to focus on designs that minimize the communication
>> between threads. BTW, this is another reason for my appreciation of
>> quasimodo's asynch parameter update model:
>
>Yeah..simple is nice.  Is modification of the dsp done in real-time in
>q, or is is just `interactive'?

well, i am not sure what you mean by "interactive", but i think i
would call it real time. here is a typical pseudo-call stack:

      poll(2)
      <various GTK event handling calls>            
      Gtk_Controller::motion_event ()
      Parameter::set ();
      Module::parameter_edit ();
           <build run time edit list>
           foreach_active_process (&DspProcess::run_time_edit, rte_list);

None of the above calls involve cross-thread communication, and the
end result is a single memory location (either a char * or a float)
gets modified. I *think* that its typically about 250 instructions or
less from when we return from getting the event from the X server to
when the memory location gets modified.

--p

From - Fri Oct  1 01:08:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA03906
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 23:13:58 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA04013 for linux-audio-dev-list; Thu, 30 Sep 1999 22:57:36 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id WAA04010 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 22:57:34 -0400
From: est@hyperreal.org
Received: (qmail 6468 invoked by uid 162); 1 Oct 1999 02:52:53 -0000
Message-ID: <19991001025253.6467.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] Re: mutex madness
In-Reply-To: <199910010132.VAA06758@renoir.op.net> from Paul Barton-Davis at
 "Sep 30, 1999 10:29:09 pm"
To: Paul Barton-Davis <pbd@Op.Net>
Date: Thu, 30 Sep 1999 19:52:53 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 495a0f05a72edf669375da3590aac827

Paul Barton-Davis discourseth:
> 
> >Maybe a queue that makes the lock/operate/unlock atomic would be
> >useful..say, a pipe!  A million write()/read()s of 1 byte through a
> >pipe takes less than 2.5 seconds on my system..not bad.
> 
> yes, i am currently working on extended Karl Nelson's libsigc++ system
> for asynchronous inter-thread callbacks, and a pipe is a key element
> of this.

This sounds quite useful.

> >Yeah..simple is nice.  Is modification of the dsp done in real-time in
> >q, or is is just `interactive'?
> 
> well, i am not sure what you mean by "interactive", but i think i
> would call it real time. here is a typical pseudo-call stack:

ack..I didn't phrase myself right.  I meant like re-patching..adding
an operator..etc.  Modifying params sounded good and real-time :)

Eric

From - Fri Oct  1 01:08:57 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA04341
	for <slinkp@ulster.net>; Thu, 30 Sep 1999 23:17:38 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA04025 for linux-audio-dev-list; Thu, 30 Sep 1999 23:00:03 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id XAA04022 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Sep 1999 23:00:01 -0400
From: est@hyperreal.org
Received: (qmail 9207 invoked by uid 162); 1 Oct 1999 02:55:25 -0000
Message-ID: <19991001025525.9206.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] mutex madness
In-Reply-To: <Pine.GSO.4.10.9909302211060.21241-100000@ux02.CS.Princeton.EDU>
 from David Slomin at "Sep 30, 1999 10:14:57 pm"
To: David Slomin <dgslomin@CS.Princeton.EDU>
Date: Thu, 30 Sep 1999 19:55:25 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 6e148c07f3744622239fae9e524b9652

David Slomin discourseth:
> 
> Here's a derivative question... is there such a thing as a realtime OS
> that is usable by application developers who don't want to have to think
> at such a low level?

Yes..Linux. :)

> Conversations about the "evils" of using conditional
> code, for example, make me as an application-level developer lose
> interest.

That wasn't OS-specific..purely a matter of instruction counts.

Eric

From - Fri Oct  1 13:22:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id FAA29561
	for <slinkp@ulster.net>; Fri, 1 Oct 1999 05:20:34 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id EAA08405 for linux-audio-dev-list; Fri, 1 Oct 1999 04:54:19 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA08402 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 04:54:10 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m11Wxxx-000dxuC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Fri, 1 Oct 1999 10:22:57 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Fri,  1 Oct 1999 10:22:56 +0200 (CEST)
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Plugin madness
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14324.26082.700605.264811@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id FAA29561
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 0eab30a5605c2d9030c148eeecb50d5a



As it seems it is getting calm around plugins again, everyone agrees
that they disagree ... and again an ambitious project for linux audio
died.

No !

Ok, lets summarize. What do we actually need (or better what do
plugin writers need). We need to agree on a common level, which will
satisfy the needs for writing plugins.

Its really damn easy. No matter which audio engine, sound editor, 
soft synth or whatever is built around. A plugin is not more
that a simple routine which modifies some signals, together with some
properties plugins share under each other, and parameters, or
k-rate signal or events or whatever you call them.


Parameters
==========

The point on which people seem to disagree are these "parameters".
Lets look at it from the plugin programmers point of view.
He just wants to have some variable (lets say of type "double"),
where he stores e.g his filter frequency.

The problem is, that this variable has to be communicated to the
application, so that the application can handle it, change it.


Ways to do it:

1) VST plugin like
The plugin programmer declares the variables he wants and communicates 
them via some setparameter(), getparameter() calls.

--> not very efficient, as there is a function call for each parameter 
change.

2) Quasimodo like
  - the parameters are communicated as pointers, the application
    can store them and acess the parameters directly.

--> better, more flexible.


3) Events system

 <To be filled out by David>, I still dont know how his will be handled. 

Sample accuracy:
=================


1) Fixed buffer size, parameter are set with "sample offset" values.
   The VST way
   bad --> sample accuracy is only achievable by doing it in the process
   function 


2) Buffersize is passed as a process argument:

 --> better of both worlds.
 some applications want to have fixed buffers, and change paramters 
 directly between process() calls

 other applications may implement an events system and call the process
 function with different buffer sizes (up to single sample processing).
 (NOTE: at this place I *can* imagine an events system, we may even
 add an 

 Application Library 
 ===================

 where the whole events system is implemented, and probably other 
 solutions, multithreading and the like.

 Ok, enough for now, I know we havnt touched the GUI topic, but first
 let us agree upon the Plugin API.
 Lets "Divide and Conquer"

 Guenter

From - Fri Oct  1 13:22:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA32456
	for <slinkp@ulster.net>; Fri, 1 Oct 1999 10:41:47 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA08895 for linux-audio-dev-list; Fri, 1 Oct 1999 10:07:41 -0400
Received: from ax-nicb.axnet.it (ax-nicb.axnet.it [194.184.60.149]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA08892 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 10:07:31 -0400
Received: (from nicb@localhost)
	by ax-nicb.axnet.it (8.8.7/8.8.7) id OAA23243;
	Fri, 1 Oct 1999 14:51:18 +0200
Date: Fri, 1 Oct 1999 14:51:18 +0200 (CEST)
From: Nicola Bernardini <nicb@axnet.it>
To: Paul Barton-Davis <pbd@Op.Net>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] linux audio demonstrability: NOT!
In-Reply-To: <199909292345.TAA15580@op.net>
Message-ID: <Pine.LNX.4.10.9910011419150.17393-100000@ax-nicb.axnet.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0ec4bb4fdb1afcf76642390ec6119388

Sorry I entered this thread just on its end. The lad list has just
too much traffic these days for me to follow suit :))

Paul, I feel the problem should handled in a different way.
I use *exclusively* Linux in producing my music and for a very good
reason: I use a mix of texts (such as, for example, csound orc/scos, etc.)
together with perl/python/awk/prolog/sql/shell scripts
and I need software that handles ASCII texts and not proprietary
files, because I use a lot of algorithmic stuff in between applications,
and this way I realize cheap and easy inter-app communication.
Furthermore, yes, apps may crash, but 1) they don't lock my machine :)
2) they are just barely good enough, but if I need something real badly
I can add to them. No commercial application can do that for me, and
I cannot use them (it's not bigotry). Yes, perhaps there are very few
of us down here, but Linux commercials care for us too :))).

So, I don't expect software vendors to port stuff to linux, as I don't
expect commercial music impresarios to understand contemporary music.
On the other hand, if/when we'll have stabler apps in the audio/music
field, I know they are going to be much better than *any* closed software
developer team is able to develop in time.

Now, hardware vendors, that's another story. I am *POSITIVE* that we
don't have good drivers because we don't have adequate documentation.
But, as somebody said on this list some time ago, these guys will have
to understand sooner or later: audio cards have the shelf life of a banana,
so when they'll see that they can sell more cards, they'll provide
more info. Open source software seemed impossible some years ago, and
now it's a solid reality: onto open hardware now. I have heard a paper
on the Emu chip that is inside the SoundBlaster Live! and its potentials
are far more than what the current win drivers do with it (let alone
the linux ones, of course). It's their choice to limit the usage of the
card - what do you want to do about it?

The Creamware people were interested about linux a long time ago.
But they did'nt do much - writing for linux is probably tougher.
And now they're asking you. I have the feeling that they got the
right guy, and if you need the entire list to write mails supporting
you, I know that everybody will do it... *But* they have to understand
that open source is the way to go...

ciao

Nicola
------------------------------------------------------------------------
Nicola Bernardini
E-mail: nicb@axnet.it
 
Re graphics: A picture is worth 10K words -- but only those to describe
the picture.  Hardly any sets of 10K words can be adequately described
with pictures.

From - Fri Oct  1 13:22:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA31748
	for <slinkp@ulster.net>; Fri, 1 Oct 1999 10:37:22 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA08861 for linux-audio-dev-list; Fri, 1 Oct 1999 10:00:07 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA08851 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 10:00:04 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46164AbPJANy5>; Fri, 1 Oct 1999 16:54:57 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <199909301257.IAA20987@renoir.op.net> (message from Paul
	Barton-Davis on Thu, 30 Sep 1999 09:53:55 -0400)
Subject: Re: [linux-audio-dev] linux audio demonstrability: NOT!
Message-Id: <19991001135505Z46164-604+254@nic.funet.fi>
Date:   Fri, 1 Oct 1999 16:54:57 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 851032e4ae1186797f1551586309e3c2

>From:   Paul Barton-Davis <pbd@Op.Net>
>
>But you also seem to suggest that you don't care if
>Creamware or Steinberg or Digidesign or whoever choose not to write
>cool audio applications for Linux.
>
>So, who *is* going to write them ? 

I only meaned that I won't buy commercial programs. I seriously hope those
companies realize that Linux is a good system. I myself simply like free
software and want to be without if I would have to buy.

Juhana

From - Fri Oct  1 13:22:43 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA04249
	for <slinkp@ulster.net>; Fri, 1 Oct 1999 11:06:57 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA08944 for linux-audio-dev-list; Fri, 1 Oct 1999 10:29:44 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA08941 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 10:29:42 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46221AbPJAOYg>; Fri, 1 Oct 1999 17:24:36 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <199909301312.JAA22465@renoir.op.net> (message from Paul
	Barton-Davis on Thu, 30 Sep 1999 10:08:52 -0400)
Subject: Re: [linux-audio-dev] 3D audio?
Message-Id: <19991001142444Z46221-606+261@nic.funet.fi>
Date:   Fri, 1 Oct 1999 17:24:36 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 43bc18541cb0d22b1843d7e2e50323ed

>From:   Paul Barton-Davis <pbd@Op.Net>
>
>Be sure to check out the Nuendo interface for this. I imagine that
>Steinberg has a .pdf file of the neundo brochure online. You can add

http://www.steinberg.de/nuendo/

>speaker configurations; 5.1 for example is 4 speakers plus a subwoofer.

5 speakers (left, right, center, back left, back right) plus subwoofer
having 0.1 of the frequency range of other speakers.

>Apparently, the home audio ("theater") industry sees a whole new way
>to make money here, convincing us all that stereo is inadequate :(

I wait for true 3D audio with speakers all around (20 speakers plus subwoofer
at minimum). And all this as cheaply as 5.1 surround amplifier today. :-)

Yours,

Juhana

From - Fri Oct  1 13:22:46 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA08453
	for <slinkp@ulster.net>; Fri, 1 Oct 1999 11:36:19 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA09006 for linux-audio-dev-list; Fri, 1 Oct 1999 10:59:51 -0400
Received: from maelzel.ircam.fr (maelzel.ircam.fr [129.102.1.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA09003 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 10:59:47 -0400
Received: from luc.ircam.fr (luc.ircam.fr [129.102.1.64])
Received: from ircam.fr (linotte.ircam.fr [129.102.1.213])
          by luc.ircam.fr (8.9.1/jtpda-5.3.1/ircam) with ESMTP id QAA31507
          for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 16:54:58 +0200 (MET DST)
Message-ID: <37F4CB41.689C211B@ircam.fr>
Date: Fri, 01 Oct 1999 16:54:57 +0200
From: Francois Dechelle <Francois.Dechelle@ircam.fr>
X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686)
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Floating-point exceptions
References: <37F2AA2E.1C205B23@earthling.net>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by maelzel.ircam.fr id QAA10046
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id LAA08453
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 5f4f135ebc0856431aadfb74d936c674

Hi,

DSP algorithms (filters for example) do a lot of floating-point underflows.
In theory, masking the corresponding trap bits in the pentium FPU control
register should do it, and silently flush the underflows to zero.

First point, on Linux, there is not yet any way to enable and disable
selected traps: you must do that with asm() statements. OK, it is not
elegant, but with a few macros... 

BUT, second point: it does not seem to work. I made an example (a 
recursive filter), that you can force to do underflows or not by 
selecting the initial value. The result is that with underflows 
the execution time is 13 times the execution time without
underflows. I let you imagine the performance impact for real-time
processing.

Do you have any ideas ? It looks like disabling the traps in
the FPU does not really disable them, but how to make sure ?

Franois

From - Fri Oct  1 13:22:47 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA09618
	for <slinkp@ulster.net>; Fri, 1 Oct 1999 11:42:57 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA09041 for linux-audio-dev-list; Fri, 1 Oct 1999 11:06:17 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA09038 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 11:06:15 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46887AbPJAPBT>; Fri, 1 Oct 1999 18:01:19 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <19990930201433.2495.qmail@hyperreal.org> (est@hyperreal.org)
Subject: Re: [linux-audio-dev] shared memory synchronization
Message-Id: <19991001150122Z46887-608+286@nic.funet.fi>
Date:   Fri, 1 Oct 1999 18:01:19 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: bb88577e86a9e1529114da0e6d5d8b82

>From:   est@hyperreal.org
>
>Some of the recent discussions, especially the anomalous behavior
>observed by Juhana, have got me thinking about three issues involving
>the use of shared memory between threads and among processors.

I have recently suspected that the corresponding page just was swapped
out. I don't exactly recall when I upgraded memory from 16 to 32 Mbytes
but when I had 16 Mbytes, the system swapped easily. Perhaps locking
of allocated pages would help...? I could test this with XWave2.

Yours,

Juhana

From - Fri Oct  1 13:22:48 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA20973
	for <slinkp@ulster.net>; Fri, 1 Oct 1999 12:57:07 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA09200 for linux-audio-dev-list; Fri, 1 Oct 1999 12:27:08 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id MAA09196 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 12:27:03 -0400
From: est@hyperreal.org
Received: (qmail 17066 invoked by uid 162); 1 Oct 1999 16:22:32 -0000
Message-ID: <19991001162232.17065.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] shared memory synchronization
In-Reply-To: <19991001150122Z46887-608+286@nic.funet.fi> from Juhana Sadeharju
 at "Oct 1, 1999 06:01:19 pm"
To: Juhana Sadeharju <kouhia@nic.funet.fi>
Date: Fri, 1 Oct 1999 09:22:32 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 6e002bfb2c901e48987512a143211f55

Juhana Sadeharju discourseth:
> >From:   est@hyperreal.org
> >
> >Some of the recent discussions, especially the anomalous behavior
> >observed by Juhana, have got me thinking about three issues involving
> >the use of shared memory between threads and among processors.
> 
> I have recently suspected that the corresponding page just was swapped
> out.

Wouldn't the access cause a page fault (and swap-in) if that were the case?

> I don't exactly recall when I upgraded memory from 16 to 32 Mbytes
> but when I had 16 Mbytes, the system swapped easily. Perhaps locking
> of allocated pages would help...? I could test this with XWave2.

A small test program that illustrates the behavior would be ideal.

Eric

From - Fri Oct  1 14:12:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA30719
	for <slinkp@ulster.net>; Fri, 1 Oct 1999 14:03:45 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA09298 for linux-audio-dev-list; Fri, 1 Oct 1999 13:14:04 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA09295 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 13:14:01 -0400
Received: from gardena.net ([194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id TAA30815;
	Fri, 1 Oct 1999 19:09:03 +0200
Received: from localhost (localhost [[UNIX: localhost]])
	by gardena.net (8.9.3/8.9.3) id TAA03569;
	Fri, 1 Oct 1999 19:00:42 +0200
From: Benno Senoner <sbenno@gardena.net>
To: est@hyperreal.org, Juhana Sadeharju <kouhia@nic.funet.fi>
Subject: Re: [linux-audio-dev] shared memory synchronization
Date: Fri, 1 Oct 1999 18:58:23 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <19991001162232.17065.qmail@hyperreal.org>
MIME-Version: 1.0
Message-Id: <99100119004202.00776@goblin.flashnet.it>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 44d20a4cf472f2ff5577fa07c4c9b38b

On Fri, 01 Oct 1999, est@hyperreal.org wrote:
> Juhana Sadeharju discourseth:
> > >From:   est@hyperreal.org
> > >
> > >Some of the recent discussions, especially the anomalous behavior
> > >observed by Juhana, have got me thinking about three issues involving
> > >the use of shared memory between threads and among processors.
> > 
> > I have recently suspected that the corresponding page just was swapped
> > out.
> 
> Wouldn't the access cause a page fault (and swap-in) if that were the case?
> 
> > I don't exactly recall when I upgraded memory from 16 to 32 Mbytes
> > but when I had 16 Mbytes, the system swapped easily. Perhaps locking
> > of allocated pages would help...? I could test this with XWave2.
> 
> A small test program that illustrates the behavior would be ideal.
> 
> Eric

I tested the behavior on my box, 
(no code handy in this moment .. sorry)
but it works,
I have one task writing values to shmem, and the other
printing the values:
the values show up about 10-20ms later, 
(when you printf the kernel has to schedule the X server)
which is the scheduling interval on a HZ=100 box.

Therefore I assume that there is nothing wrong.

Benno.

From - Fri Oct  1 15:22:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA08224
	for <slinkp@ulster.net>; Fri, 1 Oct 1999 15:10:10 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA09481 for linux-audio-dev-list; Fri, 1 Oct 1999 14:14:53 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id OAA09478 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 14:14:43 -0400
From: est@hyperreal.org
Received: (qmail 21233 invoked by uid 162); 1 Oct 1999 18:10:05 -0000
Message-ID: <19991001181005.21232.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] shared memory synchronization
In-Reply-To: <99100119004202.00776@goblin.flashnet.it> from Benno Senoner at
 "Oct 1, 1999 06:58:23 pm"
To: Benno Senoner <sbenno@gardena.net>
Date: Fri, 1 Oct 1999 11:10:05 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f5462a57a2fd35f9c8724390a654ea82

Benno Senoner discourseth:
>
> I tested the behavior on my box, 
> (no code handy in this moment .. sorry)
> but it works,

Shared memory works for me too. :)

I'm curious as to how it *didn't* work for Juhana.

Eric

From - Fri Oct  1 16:02:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA14501
	for <slinkp@ulster.net>; Fri, 1 Oct 1999 15:53:30 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA09642 for linux-audio-dev-list; Fri, 1 Oct 1999 15:09:37 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA09638 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 15:09:29 -0400
Received: from someip.ppp.op.net (d-bm2-18.ppp.op.net [209.152.194.56]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id PAA10091 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 15:04:40 -0400 (EDT)
Message-Id: <199910011904.PAA10091@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: AES Show "99" NYC 
In-reply-to: Your message of "Fri, 01 Oct 1999 13:08:12 EDT."
             <002101bf0c2f$b0e42080$6cc9c3d1@www.gomrs.com> 
Date: Fri, 01 Oct 1999 16:01:16 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: d885dea8698d3863b76b36f117d502cd

Just for-anyone's-information, I did not stop by the booth of
gomrs.com, and I did not give them, or anyone else, the email address
of this list to spam.

--p

From - Fri Oct  1 16:12:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA15432
	for <slinkp@ulster.net>; Fri, 1 Oct 1999 15:59:39 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA09651 for linux-audio-dev-list; Fri, 1 Oct 1999 15:11:30 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA09648 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 15:11:27 -0400
Received: from someip.ppp.op.net (d-bm2-18.ppp.op.net [209.152.194.56]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id PAA10419 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 15:06:34 -0400 (EDT)
Message-Id: <199910011906.PAA10419@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] 3D audio? 
In-reply-to: Your message of "Fri, 01 Oct 1999 17:24:36 +0300."
             <19991001142444Z46221-606+261@nic.funet.fi> 
Date: Fri, 01 Oct 1999 16:03:07 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: a0a49ebe2e7ba2c53e28b9630785f5c1

>>speaker configurations; 5.1 for example is 4 speakers plus a subwoofer.
>
>5 speakers (left, right, center, back left, back right) plus subwoofer
>having 0.1 of the frequency range of other speakers.

hehe. like i said, and should have stopped there, "i know nothing about
these formats" :)

From - Fri Oct  1 16:32:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA18781
	for <slinkp@ulster.net>; Fri, 1 Oct 1999 16:19:15 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA09704 for linux-audio-dev-list; Fri, 1 Oct 1999 15:31:06 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA09700 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 15:31:04 -0400
Received: from someip.ppp.op.net (d-bm2-18.ppp.op.net [209.152.194.56]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id PAA12556 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 15:26:20 -0400 (EDT)
Message-Id: <199910011926.PAA12556@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Plugin madness 
In-reply-to: Your message of "Fri, 01 Oct 1999 10:22:56 +0200."
             <14324.26082.700605.264811@gige> 
Date: Fri, 01 Oct 1999 16:22:56 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: dba08c86fc81d46cef0ea056a5562357


Thanks to Geiger to attempting to summarize the voluminous discussions
on plugin API's in the last couple of weeks. I don't want to take the
spotlight away from the summary view, but I do need to clarify a
couple of things.

>1) VST plugin like
>The plugin programmer declares the variables he wants and communicates 
>them via some setparameter(), getparameter() calls.
>
>--> not very efficient, as there is a function call for each parameter 
>change.
>
>2) Quasimodo like
>  - the parameters are communicated as pointers, the application
>    can store them and acess the parameters directly.
>
>--> better, more flexible.

actually, Quasimodo is closer to (1) than to (2). A GUI or any other
part of a system that communicates with the Quasimodo engine uses
Parameter::set() in order to reset the value. That function in turn
calls another function, Plugin::parameter_edit() (well, its actually
Module::plugin(), but I'm trying to keep with the terminology :) which
carries out the *many* steps (many compared to "*p = newval;")
necessary to change the parameter.

    [ why is a parameter not a pointer ? 2 reasons. parameters exist,
      for the most part, as part of the closure that is passed to the
      plugin code as its argument. plugins are not "instantiated"
      until necessary, and neither are their closures. this means there
      cannot be a pointer to the parameter, since the memory location
      where it will live doesn't exist until the plugin is instantiated.

      Why not create one and bind it to the plugin ? Well, we do, in
      the sense that instantiated plugins (called DspProcess-es) are
      kept around and reused. But that doesn't help us because of the
      second reason.  Some plugins can be used polyphonically - that
      is, we instantiate multiple copies of them in response, say, to
      MIDI NoteOn messages. Each one is running with different values
      (say, for pitch) stored in its closure. So, editing a parameter
      for such a plugin actually means altering the data stored at
      *several* locations.  
    ]

However, its not a system like David's proposed event system, in that
no synchronization or communication is carried out between the GUI (or
automation system) and the DSP engine - the value of the parameter as
seen by dereferencing a pointer within the plugin's code can change at
any time without the plugin code or the engine "knowing" it. In this
sense, it is highly efficient. It cannot, however, support sample
accuracy.

--p


From - Fri Oct  1 16:32:34 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA19549
	for <slinkp@ulster.net>; Fri, 1 Oct 1999 16:23:42 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA09740 for linux-audio-dev-list; Fri, 1 Oct 1999 15:38:33 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA09737 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 15:38:31 -0400
Received: from someip.ppp.op.net (d-bm2-18.ppp.op.net [209.152.194.56]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id PAA13289 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 15:33:47 -0400 (EDT)
Message-Id: <199910011933.PAA13289@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: mutex madness 
In-reply-to: Your message of "Thu, 30 Sep 1999 19:52:53 PDT."
             <19991001025253.6467.qmail@hyperreal.org> 
Date: Fri, 01 Oct 1999 16:30:24 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1e5ca1d1305a8699bee0680cf65aabd4

EST requesteth:

>> >Yeah..simple is nice.  Is modification of the dsp done in real-time in
>> >q, or is is just `interactive'?

modification of the DSP works by sending requests to the DSP
thread. It checks the queue every control cycle, and instantiates a Module
as a new DspProcess, initializes it, and puts it on the work queue. At
the end of any given "process()" function it also checks to see if the
DspProcess is "dead", and removes+recycles it if so.

So if you do something (say, generate a MIDI NoteOn or NoteOff) that
requires a change in the DSP program (defined by the DspProcess-es on
the current work queue), then you have a maximum of one control cycle
to wait until it happens. Obviously, you get to define the length of a
control cycle. I typically use 64 samples.

--p

From - Fri Oct  1 16:42:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA20568
	for <slinkp@ulster.net>; Fri, 1 Oct 1999 16:30:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA09754 for linux-audio-dev-list; Fri, 1 Oct 1999 15:43:58 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA09751 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 15:43:56 -0400
Received: from someip.ppp.op.net (d-bm2-18.ppp.op.net [209.152.194.56]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id PAA14119 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 15:39:12 -0400 (EDT)
Message-Id: <199910011939.PAA14119@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] mutex madness 
In-reply-to: Your message of "Thu, 30 Sep 1999 22:14:57 EDT."
             <Pine.GSO.4.10.9909302211060.21241-100000@ux02.CS.Princeton.EDU> 
Date: Fri, 01 Oct 1999 16:35:48 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: cceb35f7c1c4abcc2811612c838c93aa

>Here's a derivative question... is there such a thing as a realtime OS
>that is usable by application developers who don't want to have to think
>at such a low level?  

i afraid that in general, if you want to use multiple threads and/or
realtime scheduling, these kinds of issues will likely have to dealt
with explicitly one way or another. you might get lucky, and find the
"defaults" of a given thread system and the OS scheduler work for you,
but the chances of that are low. 

Parallel programming is *hard*. People don't do consciously controlled
things in parallel (though we're good at multitasking :), and writing
software that does is a real challenge. Many people have tried to
write languages that cover up all the hard stuff, but to the best of
knowledge, none of them really succeed in their goals.

>Conversations about the "evils" of using conditional
>code, for example, make me as an application-level developer lose
>interest.

if (!if_is_ok) {
   goto new_language_or_processor;
}

BTW, several important DSP chips don't have conditional instructions
at all. Fast ? Yes. Useful ? That's a long story ...

--p

From - Fri Oct  1 21:59:50 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA09004
	for <slinkp@ulster.net>; Fri, 1 Oct 1999 18:55:32 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA10068 for linux-audio-dev-list; Fri, 1 Oct 1999 18:10:05 -0400
Received: from mail.virginia.edu (mail.Virginia.EDU [128.143.2.9]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id SAA10065 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 18:10:02 -0400
Received: from neon.mail.virginia.edu by mail.virginia.edu id aa05458;
          1 Oct 99 18:05 EDT
Received: from virginia.edu (djt7p@jangle.music.Virginia.EDU [128.143.140.24])
	by neon.mail.Virginia.EDU (8.8.7/8.8.7) with ESMTP id SAA26816;
	Fri, 1 Oct 1999 18:05:16 -0400 (EDT)
Message-ID: <37F53112.5E122044@virginia.edu>
Date: Fri, 01 Oct 1999 18:09:22 -0400
From: "David J. Topper" <topper@virginia.edu>
Organization: UVA - VCCM
X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i686)
MIME-Version: 1.0
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>,
        "alsa-devel@alsa.jcu.cz" <alsa-devel@alsa.jcu.cz>
Subject: [linux-audio-dev] Laptop MIDI devices
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 4d6af48b74558e3ebb3cedcf47625252

Hey folks,

I've heard something about serial devices for MIDI under Linux?  Anyone
know about this, or any other way to get MIDI into a Linux laptop?  I
know OSS does not have any kind of support just yet.

Email responses preferred.

Thanks all,

Dave Topper
--
Technical Director, Virginia Center for Computer Music
Programmer / Analyst, Dean's Office (School of A&S)
http://www.people.virginia.edu/~djt7p
(804) 924-6887

From - Fri Oct  1 21:59:51 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA09943
	for <slinkp@ulster.net>; Fri, 1 Oct 1999 19:03:07 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA10113 for linux-audio-dev-list; Fri, 1 Oct 1999 18:26:02 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA10110 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 18:25:59 -0400
Received: from localhost.localdomain (d212-151-32-240.swipnet.se [212.151.32.240]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA25452; 
          Sat, 2 Oct 1999 00:21:09 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: David Slomin <dgslomin@CS.Princeton.EDU>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] mutex madness
Date: Sat, 2 Oct 1999 00:17:12 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <Pine.GSO.4.10.9909302211060.21241-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Message-Id: <99100200273902.00441@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id AAA25452
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA09943
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 9d8591143f3e0335c19eb44b0f4e6263

On Fri, 01 Oct 1999, David Slomin wrote:
> On Thu, 30 Sep 1999, Paul Barton-Davis wrote:
> 
> > Also, when I think about keeping a GUI thread at a lower priority than
> > the DSP engine thread, I am thinking about kernel threads with system
> > scope scheduling, not user level threads with process scope
> > scheduling. To manage the relative priority of a GUI and a DSP thread
> > from user space implies switching the GUI and DSP user threads on and
> > off the same kernel thread(s). If you're using an SMP system, this is
> > a bad idea.
> 
> More proof why I should leave such low-level realtime stuff to the
> experts.  :-)  Thanks.
> 
> Here's a derivative question... is there such a thing as a realtime OS
> that is usable by application developers who don't want to have to think
> at such a low level?  Conversations about the "evils" of using conditional
> code, for example, make me as an application-level developer lose
> interest.

The "conditional code" thing I'm mentioning every now and then is just about
pure performance, and not really RT-related. The reason why it's important in a
plug-in API is that you certainly don't want overhead built into the design of
a system that you can't avoid. (Guess why I dropped WinNT. *heh...*)

Real time programming for the non-control engineer *is* actually a little more
complicated in a "mixed mode", all purpose system like Linux. For me, working
professionally with embeded RT systems, having a full-blown UNIX just around
the corner, on the same machine is heaven, but it also means you have to keep
in mind that synchronizing to non-RT parts of the system - directly or
indirectly - will break you guaranteed deadlines.

Pure RTOS's (like QNX) are probably a little nicer, as they have a cleaner
design, where you don't have to worry about system calls being problematic, or
even not possible to use from RT tasks, but you still have to code by the laws
of nature, of course. :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Oct  1 21:59:54 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA17007
	for <slinkp@ulster.net>; Fri, 1 Oct 1999 19:57:42 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA10191 for linux-audio-dev-list; Fri, 1 Oct 1999 18:56:46 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA10188 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 18:56:43 -0400
Received: from localhost.localdomain (d212-151-32-240.swipnet.se [212.151.32.240]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA14972; 
          Sat, 2 Oct 1999 00:51:57 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Guenter Geiger <geiger@epy.co.at>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Plugin madness
Date: Sat, 2 Oct 1999 00:38:21 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <14324.26082.700605.264811@gige>
MIME-Version: 1.0
Message-Id: <99100200583003.00441@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id AAA14972
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA17007
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 00b7b12033b39847ef61c39a2f9e2e0a

On Fri, 01 Oct 1999, Guenter Geiger wrote:
> As it seems it is getting calm around plugins again, everyone agrees
> that they disagree ... and again an ambitious project for linux audio
> died.
> 
> No !

Right, and I'm not giving up here. There is a reason why I'm writing an order
of magnitude more english than C.

(However, I need to get to bed soon, as I'm off to Denmark tomorrow. Will be
back sunday, perhaps with more ideas.)

> Ok, lets summarize. What do we actually need (or better what do
> plugin writers need). We need to agree on a common level, which will
> satisfy the needs for writing plugins.
> 
> Its really damn easy. No matter which audio engine, sound editor, 
> soft synth or whatever is built around. A plugin is not more
> that a simple routine which modifies some signals, together with some
> properties plugins share under each other, and parameters, or
> k-rate signal or events or whatever you call them.

Seems simple on the high level, but the complicated part is doing it
efficiently, and in a flexible enough way in low level code... We really need
to work hard on this, or we'll just end up with another useless "standard" thay
won't be adopted.


> Parameters
> ==========
> 
> The point on which people seem to disagree are these "parameters".
> Lets look at it from the plugin programmers point of view.
> He just wants to have some variable (lets say of type "double"),
> where he stores e.g his filter frequency.
> 
> The problem is, that this variable has to be communicated to the
> application, so that the application can handle it, change it.
> 
> 
> Ways to do it:
> 
> 1) VST plugin like
> The plugin programmer declares the variables he wants and communicates 
> them via some setparameter(), getparameter() calls.
> 
> --> not very efficient, as there is a function call for each parameter 
> change.

Yes, inefficient, clumsy, not very clean and nice, and it still doesn't handle
sample accuracy without splitting buffers.

> 2) Quasimodo like
>   - the parameters are communicated as pointers, the application
>     can store them and acess the parameters directly.
> 
> --> better, more flexible.

A *lot* nicer, and much more efficient. Still no sample accuracy without buffer
splitting, though...

> 3) Events system
> 
>  <To be filled out by David>, I still dont know how his will be handled. 

Well, basically, it's about turning events into data of a format similar to the
audio buffers. That is, you build a buffer of timestamped events to be executed
during the processing of the buffer, and then you send it all to the process()
callback with a single call. Event timing is independent of buffer size, and
the process() function can send events to plug-ins down the processing net,
still with sample accuracy.


> Sample accuracy:
> =================
> 
> 
> 1) Fixed buffer size, parameter are set with "sample offset" values.
>    The VST way
>    bad --> sample accuracy is only achievable by doing it in the process
>    function 

Fixed buffer size is good for optimization, but not very nice if you can't pass
accurate timing info...

> 2) Buffersize is passed as a process argument:
> 
>  --> better of both worlds.
>  some applications want to have fixed buffers, and change paramters 
>  directly between process() calls
> 
>  other applications may implement an events system and call the process
>  function with different buffer sizes (up to single sample processing).

...which leads to lots of function call overhead when there's heavy event
traffic... Inline code will have to be slow to be beaten by such a design,
performance wise.

With a timestamped/buffered event system, you can, in a way, do both.

>  (NOTE: at this place I *can* imagine an events system, we may even
>  add an 
> 
> 
>  Application Library 
>  ===================
> 
>  where the whole events system is implemented, and probably other 
>  solutions, multithreading and the like.

For my design, this is mostly inline code funcs/macros, and a few function
calls to use in special cases.

>  Ok, enough for now, I know we havnt touched the GUI topic, but first
>  let us agree upon the Plugin API.

Yep. I think the GUI part belongs pretty far from the DSP part anyway. Some
plug-ins may not even have a GUI, and some kinds of systems won't have much of
a UI at all. What about games sound engines and embeded systems, for example?


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Oct  1 22:00:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA24960
	for <slinkp@ulster.net>; Fri, 1 Oct 1999 21:00:17 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA10387 for linux-audio-dev-list; Fri, 1 Oct 1999 20:09:29 -0400
Received: from mout0.01019freenet.de (mout0.01019freenet.de [62.104.201.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA10384 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 20:09:27 -0400
From: depet@gmx.de
Received: from [62.104.201.6] (helo=mx0.01019freenet.de)
	by mout0.01019freenet.de with esmtp (Exim 3.03 #1)
	id 11XCfL-000849-00
	for linux-audio-dev@ginette.musique.umontreal.ca; Sat, 02 Oct 1999 02:04:43 +0200
Received: from [212.81.159.142] (helo=Nirvana.Saustall)
	by mx0.01019freenet.de with esmtp (Exim 3.03 #1)
	id 11XCf7-0006tG-00
	for linux-audio-dev@ginette.musique.umontreal.ca; Sat, 02 Oct 1999 02:04:36 +0200
Message-ID: <XFMail.991002011107.depet@gmx.de>
X-Mailer: XFMail 1.3 [p0] on Linux
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Date: Sat, 02 Oct 1999 01:11:07 +0200 (CEST)
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] announce: LDse
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: e23e8b9a0ff3374bba7459912eef0759


LDse is a hack that takes an alsa fragment from one soundcard screws on
it (effects) and writes the fragment to a second soundcard.
It's basically a "realtime" effects unit (I use it for guitar playing and dub
music)

It has an ugly bui (blind user interface) that is buggy. If you care you
can give it a try: members.xoom.com/ldsehome/index.html

mail me with problems, but be warned, I recently lost daily access to email
so it may take a week to respond.

...o..oO0 NoehliE 0Oo..o...

From - Fri Oct  1 21:59:57 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA19243
	for <slinkp@ulster.net>; Fri, 1 Oct 1999 20:14:17 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA10290 for linux-audio-dev-list; Fri, 1 Oct 1999 19:23:58 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA10287 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 19:23:56 -0400
Received: from localhost.localdomain (d212-151-32-240.swipnet.se [212.151.32.240]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA23791; 
          Sat, 2 Oct 1999 01:19:07 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] mutex madness
Date: Sat, 2 Oct 1999 01:17:55 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199910011939.PAA14119@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99100201253804.00441@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id BAA23791
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA19243
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: de563cea603250f61d13f96dd4c25382

On Fri, 01 Oct 1999, Paul Barton-Davis wrote:
> BTW, several important DSP chips don't have conditional instructions
> at all. Fast ? Yes. Useful ? That's a long story ...

For those who are interested: Conditional processing can be done as in
mathematics; through expressions that "select" values depedning on other
values.

What's the point? (As it usually results in slower code...) Simpler DSP cores
and one single flow of control. The later can be very useful when you have just
about enough power to get the job done. (Which is what you'll have in a low
power system, for example.)

BTW, MMX use something in between these methods; instructions that test for
certain conditions and output masks of the full word size. The reason why that
is needed is that you cannot split the control flow when 2, 4 or 8 "channels" of
processing are using the same instructions at once...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Oct  1 22:01:46 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA31771
	for <slinkp@ulster.net>; Fri, 1 Oct 1999 21:53:26 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA10449 for linux-audio-dev-list; Fri, 1 Oct 1999 20:55:10 -0400
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id UAA10446 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 20:55:08 -0400
Message-Id: <199910020055.UAA10446@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Floating-point exceptions
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Fri, 1 Oct 1999 20:49:51 -0400 (EDT)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
In-Reply-To: <37F4CB41.689C211B@ircam.fr> from "Francois Dechelle" at Oct 1, 99 04:54:57 pm
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 6d0e4bfaf9ea264cff45daedcc9c9cc8

Francois Dechelle wrote:
> DSP algorithms (filters for example) do a lot of floating-point underflow=
> s.
> In theory, masking the corresponding trap bits in the pentium FPU control
> register should do it, and silently flush the underflows to zero.

You're talking about denormals, where there's no implicit leading 1 on
the mantissa?  These don't cause underflow exceptions (until they
finally do underflow to zero).  They're just ungodly slow.

I am told that Intel hardware implements them through a trap to
software, but this is not an IEEE FP exception -- you can't turn it
off through IEEE.  It could just as well be slow microcode.  There is
no way I know of to disable denormal-handling and flush to zero,
presumably because that would violate the FP spec.

Some architectures do permit this little violation.  Lacking that, 
I think you have to resort to adding DC, adding noise, testing for
small values, that sort of thing.

Sometimes I wonder how Linux is running G4 PowerMacs.

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Fri Oct  1 22:39:46 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA03273
	for <slinkp@ulster.net>; Fri, 1 Oct 1999 22:25:47 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA10556 for linux-audio-dev-list; Fri, 1 Oct 1999 21:54:30 -0400
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id VAA10553 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 21:54:27 -0400
Message-Id: <199910020154.VAA10553@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: mutex madness
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Fri, 1 Oct 1999 21:49:35 -0400 (EDT)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
In-Reply-To: <199909301308.JAA21970@renoir.op.net> from "Paul Barton-Davis" at Sep 30, 99 10:04:20 am
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 65300b06d55cb3cdde82e70e625f02ba

Paul Barton-Davis wrote:
> is this related to herlihy's wait free synchronization, or something
> else ?

Dunno.  The logic here is 
single writer:
        check head beyond tail 
        write through tail pointer
        advance tail 
single reader:
        check tail beyond head 
        read through head pointer
        advance head
where "beyond" and "advance" are circular.
(Disclaimer: I got this from the comments, not the code.)

I think the requirements for this to be safe are
1) pointers are written atomically.
2) writes don't get reordered.

As David Olofson mentioned, RTLinux uses these.  They're handy when
you can't deal with priority inversion -- when priority inheritance
makes no sense, as in RTLinux, or when it doesn't fix the problem, as
in many hard RT systems.

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Fri Oct  1 23:09:45 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA07083
	for <slinkp@ulster.net>; Fri, 1 Oct 1999 22:57:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA10624 for linux-audio-dev-list; Fri, 1 Oct 1999 22:22:53 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA10621 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 22:22:51 -0400
Received: from someip.ppp.op.net (d-bm2-0d.ppp.op.net [209.152.194.45]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id WAA12898 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 1 Oct 1999 22:18:06 -0400 (EDT)
Message-Id: <199910020218.WAA12898@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Floating-point exceptions 
In-reply-to: Your message of "Fri, 01 Oct 1999 20:49:51 EDT."
             <199910020055.UAA10446@ginette.musique.umontreal.ca> 
Date: Fri, 01 Oct 1999 23:14:47 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 53d7636d9bb90ba2879b678d1b913f6b

>Sometimes I wonder how Linux is running G4 PowerMacs.

You're not the only one :) OTOH, its not clear to what extent there is
any plan to offer SMP motherboards or support for the G4. Also, Benno
pointed me at the AMD K7 (Athlon) which looks like it should be able
to match the G4 *and* will have SMP motherboards available RSN. The
price is right, too.

--p

From - Sat Oct  2 00:37:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA15561
	for <slinkp@ulster.net>; Sat, 2 Oct 1999 00:25:44 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA10781 for linux-audio-dev-list; Sat, 2 Oct 1999 00:04:43 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA10778 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 2 Oct 1999 00:04:40 -0400
Received: from op.net (d-bm2-0d.ppp.op.net [209.152.194.45]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id XAA17646; Fri, 1 Oct 1999 23:59:21 -0400 (EDT)
Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id AAA00850; Sat, 2 Oct 1999 00:55:55 -0400
Date: Sat, 2 Oct 1999 00:55:55 -0400
Message-Id: <199910020455.AAA00850@op.net>
From: Paul Barton-Davis <pbd@Op.Net>
To: linux-audio-dev@ginette.musique.umontreal.ca,
        csound-unix-dev@ilogic.com.au, csound@maths.ex.ac.uk,
        qm-dev@exp.firstpr.com.au, music-dsp@shoko.calarts.edu
Subject: [linux-audio-dev] [Quasimodo] version 0.1.7 released
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 31218d647a4fbbb7174c77dd00ebc3ca

The newest release of Quasimodo(*) is now available as a tarball or 3
from:

	http://www.op.net/~pbd/quasimodo/

This is still very much an in-development release, but a very
substantial amount of internal code restructuring has taken place to
support the new firewall between the DSP engine + a user interface.
As usual, there are also lots of bug fixes, plus (no doubt) a few new
bugs. You will be better off if you use ALSA under Linux rather than
OSS. I have not used the OSS layer in months.

Please look forward to a much more frequent release schedule from now
on. Also, I hope to offer binary releases around version 0.1.9 or 0.1.10.

Although 99.9% of the email concerning Quasimodo's development has
been between Stephane Conversey and myself, the quasimodo development
mailing list will be the forum that the two of us will use from now
on, and we invite anyone who isn't on that list to subscribe and
contribute ideas, bug reports, code etc. to Quasimodo's development.
Details on the web site.

--regards,
--p
---------------------------------------------------------------------------
(*) Description:
----------------

Quasimodo is an advanced, real-time, 32-bit floating point,
extensible, MIDI-controllable environment for generating and
processing audio and MIDI data.

Quasimodo supports the Csound "programming" language, plugin opcodes,
themeable graphics, a simple scripting language for user-interface
design, and an intuitive graphical user interface for real-time
manipulation. It supports both Csound scorefiles, real-time MIDI
input, and its own user interface for playing audio and MIDI
compositions. 

Internally, Quasimodo features advanced object-oriented design,
multithreading, formal grammars, high-precision timing, and a highly
portable GUI toolkit.

Quasimodo runs on advanced and stable operating systems based on the
POSIX OS specification (so far: Linux and IRIX)

Quasimodo is fully controllable from any physical control surface that
generates MIDI, without any programming of the control surface.
(e.g. Mackie HUI, Peavey PC1600X, JL Cooper CS10 or
FaderMaster/MixMaster).  It automatically learns which MIDI controller
you want to control a given parameter/visual element.

Quasimodo is open source, free software. It can be extended at many
levels: rewriting the source, adding new opcodes, writing new
Quasimodules, creating new visuals for the user interface. You are
free to do anything you want with (most) of Quasimodo, as long as you
don't restrict others freedom to do the same.

From - Sun Oct  3 19:59:05 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA07732
	for <slinkp@ulster.net>; Sun, 3 Oct 1999 16:56:49 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA21708 for linux-audio-dev-list; Sun, 3 Oct 1999 16:35:29 -0400
Received: from gauss.deltav.hu (gauss.deltav.hu [194.9.64.225]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA21705 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 3 Oct 1999 16:35:22 -0400
Received: from cerealbox (99.dial02.deltav.hu [194.9.64.99])
          by gauss.deltav.hu (Netscape Messaging Server 3.6)  with ESMTP
          id AAA4390 for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Sun, 3 Oct 1999 22:34:01 +0200
Received: from reactor by cerealbox with local (Exim 1.92 #1 (Debian))
	id 11XrRT-00003U-00; Sun, 3 Oct 1999 21:37:07 +0200
Message-ID: <19991003213707.A209@cerealbox>
Date: Sun, 3 Oct 1999 21:37:07 +0200
From: "RACZ Mate (reactor/CTPmedia)" <reactor@sagv5.gyakg.u-szeged.hu>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] new sequencer
Reply-To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.91.2
Organization: CTP media laboratories
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: e2f54d285cf9d8b6c52897f956a5037f

yo!

i think everyone reads Freshmeat, but maybe not...
so, there's a new sequencer program out there, called Brahms.
it uses Qt, so i couldn't check it out. (i'm gonna install Qt today)
as i read, it cooperates well with aRts (BTW, a new aRts is out, 0.3.4), 
so maybe we got something like DreamStation for linux.

Brahms download URL:
http://www.stud.uni-hamburg.de/~arts/download/Brahms-0.97.1.tar.gz

bye!

-- 

  Mt Rcz a.k.a. reactor  -  http://linux.gyakg.u-szeged.hu/~reactor/
   CTP media - since 1995   -  http://ctpmedia.scene.hu/

From - Mon Oct  4 23:08:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id FAA08712
	for <slinkp@ulster.net>; Mon, 4 Oct 1999 05:35:25 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id EAA26824 for linux-audio-dev-list; Mon, 4 Oct 1999 04:59:07 -0400
Received: from pat.bath.ac.uk (pat.bath.ac.uk [138.38.32.2]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id EAA26821 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 4 Oct 1999 04:59:04 -0400
Received: (qmail 10838 invoked from network); 4 Oct 1999 08:54:09 -0000
Received: from mary.bath.ac.uk (HELO bath.ac.uk) (mmdf@138.38.32.14)
  by pat.bath.ac.uk with SMTP; 4 Oct 1999 08:54:09 -0000
Received: from tobi.bath.ac.uk by mary.bath.ac.uk id aa15354; 4 Oct 99 9:54 BST
Message-ID: <37F86B31.2781@bath.ac.uk>
Date: Mon, 04 Oct 1999 09:54:09 +0100
From: "P.J.Leonard" <P.J.Leonard@bath.ac.uk>
Organization: Applied Electromagnetic Research Centre
X-Mailer: Mozilla 3.0 (X11; I; OSF1 V2.0 alpha)
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] new sequencer
References: <19991003213707.A209@cerealbox>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7e9120c8025a142ff12cdf1b6ba2e11b

RACZ Mate (reactor/CTPmedia) wrote:
> 
> yo!
> 
> i think everyone reads Freshmeat, but maybe not...
> so, there's a new sequencer program out there, called Brahms.
> it uses Qt, so i couldn't check it out. (i'm gonna install Qt today)


 You also need KDE.

>>> checking for KDE... configure: error: <<<
	

-- 
 Cheers Paul (P.J.Leonard)                                        

 Tel: +44 (0)1225 826108  Applied Electromagnetic Research Centre,
 Fax: +44 (0)1225 826305   University of Bath, BATH. BA2 7AY  UK

From - Mon Oct  4 23:08:44 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA14332
	for <slinkp@ulster.net>; Mon, 4 Oct 1999 17:49:56 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA28615 for linux-audio-dev-list; Mon, 4 Oct 1999 17:07:54 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA28612 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 4 Oct 1999 17:07:51 -0400
Received: from localhost.localdomain (d212-151-102-231.swipnet.se [212.151.102.231]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id XAA12983; 
          Mon, 4 Oct 1999 23:02:48 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: John Littler <linuxmusic@crosswinds.net>
Subject: [linux-audio-dev] Draft: Audiality article for MusicStation
Date: Mon, 4 Oct 1999 22:25:53 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
MIME-Version: 1.0
Message-Id: <99100423092700.00574@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id XAA12983
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id RAA14332
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 0db8bbe11433ad06431fd5aafca7136a

Here's a first draft of my article. As this is more about the plug-in API than
about the project I actually started up a few months ago, I'd really like some
comments from the ones involved in the API discussion.

I think this article is a bit too technical to get the "political" message
"Design Open Standards and *use* them" across, and I think that actually
belongs in a separate article. Is there actually a need for such a document, or
is the problem more of the kind "How do we get people to actually participate
in the design discussions?" It seems that there's no problem getting people to
realize that standard interfaces makes code more reusable (unless the
interfaces are crap, that is), but it's harder to get the work done. Hacking is
more fun, right?

Of course all comments are welcome! :-) And keep in mind that this document (the
first part, at least) is meant to make sense to end users - not just audio
hackers.


//David

---8<-------------------------------------------------------------------


Audiality
-------------------------------------

What's Audiality all about?
===========================
The name "Audiality" was constructed from the words "audio" and "reality",
and turned out to be very handy, in that it's unique and not used anywhere
on the Net. As might be guessed from the origin of the name, it's about
audio.

While starting out as yet another Windows application, doomed to suffer from
Windows' poor real time performance, Audiality has since been dropped and
restarted as a similar project for Linux/RTLinux. Apart from the new
environment, the restart project also has a slightly different goal: Rather
than Audiality being a stand-alone application, it's now being designed from
the ground up as a generic audio/MIDI/multimedia engine, or rather server,
optimized for reliable, high accuracy, low latency real time processing.

Currently, it seems to be evolving into an open design/standardization
effort, where a plug-in API and a client/server API currently have higher
priority than the actual implementation. The implementation itself may
actually end up as a part of some other project.


What does it mean for the user?
===============================
Basically, the success of Audiality would mean that most future development
efforts in the Linux multimedia area would result in plug-ins that can be
used by most applications, and/or applications that can cooperate on a level
that is not possible with any currently existing systems. The client/server
model allows fine grained integration all the way down to intermixing
plug-ins managed by different applications, and even controlling individual
plug-in parameters from different applications.

Everything will automatically stay in sync, as all time critical work is
done centrally, inside the engine, or is done using the same time base.
Further, all processing that is done inside the engine can be done with
very low latencies, as all plug-ins are executed as a part of the engine
thread. (Or threads, on multiprocessor systems.) Currently, that means less
than 5 ms with Ingo Molnar's low latency patch, and less than .5 ms with
RTLinux. (The later is actually a hardware restriction of most PCI sound
cards - RTLinux itself allows latencies lower than .05 ms even on Pentium
CPUs.)

As both Ingo's patch and RTLinux provide hard real time characteristics
(that is, guaranteed maximum response times), the reliability is in the
same class as that of dedicated hardware systems. The processing is done
reliably with the above mentioned latencies, as long as the operating
system stays alive. And Linux is pretty good at staying up, as you
probably know!


What does it mean for the developer?
====================================
Most importantly, easier code reuse. Plug-ins don't even have to be
recompiled to be reused with new applications. Although the recommended
method is letting the central engine/server host the plug-ins, and use the
client/server API to control them, applications may host plug-ins locally,
which means the plug-ins can be used in environments without the server.

(Note: The APIs are under heavy discussion on the linux-audio-dev list,
and some details mentioned below may change before the final standard is
agreed upon.)

Client/server architecture
--------------------------  
The most important advantage of running the plug-ins in the server is that
the application can take advantage of the performance provided by Linux
SCHED_FIFO, or even RTLinux - without the need for complicated real time
code in the application. And of course, you don't have to implement a
plug-in host yourself. Another important advantage is that multiple
applications may do this at once without the reliability problems caused
by multiple real time threads running at once.

The client/server API also allows things like streaming to/from applications
(which means you *can* have applications directly processing data if you
really don't want to do it the right way; hack a plug-in ;-), sample
accurate timing with low communication overhead (events are passed in
buffers, or through pipes, much like the audio data) and off-line
processing. It's likely that a linked library containing a full
implementation of the engine will be available, which would be very handy
when porting applications to environments lacking a working server
implementation.

As an extra bonus, the server will provide OSS and ALSA interfaces, and will
act as a sound daemon for those, hiding the real devices from applications.
This will make old/non-Audiality applications work, and even fit nicely into
the system - their outputs and inputs will show up as extra ports inside the
processing net of the engine.

Plug-in architecture
--------------------
The plug-in API is OS independent, and a basic requirement for normal
plug-ins (as opposed to "system" plug-ins, like interfaces and drivers) is
that they don't do any system calls. The plug-in API is the only interface
available, and covers all things that makes sense to do within the real
time part of a plug-in. (The user interface part of plug-ins is different
in that it *allows* any other APIs to be used, and only adds part of the
Audiality plug-in API for communication with the engine and the processing
part of the plug-in.)

The API is rather low level, and provides very few function calls. Many of
the details are handled by macros and inline code for performance reasons,
much like things are done inside the Linux kernel. The plug-in API itself
doesn't know much about audio data formats, and can handle other kinds of
data, like video and compressed formats. It can be seen as a real time IPC
system, optimized for low latency, real time streaming.
    
The event system
----------------
One important part of the plug-in API that also shows up in the
client/server API is the event system. It allows sending *buffers* of
timestamped events (as opposed to sending one event at a time through a
function call), and supports request/reply schemes for higher levels of
communication. Events are allocated dynamically, and can have different
sizes. Timestamps are normally in samples from the start of the current
buffer, but it's likely that higher resolution formats will be supported.
     
Design and performance
----------------------
Plug-ins are callbacks - not individual threads as in some other systems.
Currently, this is the only sane way of doing it, for performance and
complexity reasons. Running plug-ins as individual threads would make it
virtually impossible for the engine to keep track of who's doing what and
when, and also means far too much context switch overhead, even for
RTLinux.

Plug-in scheduling is based on sub nets with homogenous cycle times, which
means that the inter-plug-in communication and streaming can be efficiently
optimized. All plug-ins within a sub net will execute one at a time, in a
fixed order.

The language of the API is C. C++ would add more complexity and hidden
overhead than it would simplify development, as a single plug-in is a very
simple, low level object.

Relation to OSS and ALSA
------------------------
This is actually implementation dependent, and has nothing to do with the
Audiality APIs. However, a server/engine implementation is likely to run on
top of the OSS or ALSA API, and as mentioned above, there will be interfaces
that allow non-Audiality applications to communicate with the server.

Audiality and RTLinux
---------------------
When the Audiality project was started, the only option for reliable low
latency processing was using the RTLinux kernel patch. A while later, there
was a discussion on low latency audio processing and real time programming
in general on the linux-kernel list, and shortly after that, the low latency
patch made low latency processing using SCHED_FIFO scheduling possible. This
will make things easier for users and developers, as production systems can
actually run high end multimedia applications in user space.

The RTLinux implementation is still part of the plans, and will be an
alternative for applications that demand extremely low latencies. A driver
API, the Driver Programming Interface (DPI) is in development, and will make
it easy to port standard Linux drivers to RTLinux. (Source can be downloaded
from the Audiality site.)


David Olofson <audiality@swipnet.se>, 1999


---8<-------------------------------------------------------------------

 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Mon Oct  4 23:08:50 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA24621
	for <slinkp@ulster.net>; Mon, 4 Oct 1999 22:14:55 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA29103 for linux-audio-dev-list; Mon, 4 Oct 1999 21:55:17 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA29100 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 4 Oct 1999 21:55:15 -0400
Received: from someip.ppp.op.net (d-bm2-1b.ppp.op.net [209.152.194.59]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id VAA25387; Mon, 4 Oct 1999 21:50:01 -0400 (EDT)
Message-Id: <199910050150.VAA25387@renoir.op.net>
To: David Olofson <audiality@swipnet.se>
cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Draft: Audiality article for MusicStation 
In-reply-to: Your message of "Mon, 04 Oct 1999 22:25:53 +0200."
             <99100423092700.00574@localhost.localdomain> 
Date: Mon, 04 Oct 1999 22:47:26 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f09ba319fa70b1ab9f1dd7edf99c894e

>The language of the API is C. C++ would add more complexity and hidden
>overhead than it would simplify development, as a single plug-in is a very
>simple, low level object.

a small detail. I think the above is needlessly religious. Instead of
inviting language wars, you can write:

  As the Gimp ToolKit (GTK+) has shown very well, it tends to be
  easier to bind a variety of different languages to an API written
  for C. This decision makes it possible for users of, for example,
  C++, Java, and Python to use the API effectively while using the
  idioms of their chosen language.

And remember, I'm a C++ bigot :)

On a broader front, I feel that its the purpose of the article is a
little mixed. Although I think that Audiality is an interesting and
worthwhile project, it holds no more significance for me than aRtS,
Brahms or a variety of other excellent pieces of software. By
contrast, the development of a well-defined plugin API for audio
applications under Linux is of enormous significance. I may very well
never use Audiality, but I might write or use a different
server/engine that supported this standard API, and I might write
or use plugins that could be used with it.

Reading your article doesn't give me much of a handle on the
distinction between these two, and makes it sound as if, in order to
support the development of a standard API, I need to be thinking about
Audiality. If this is true, then the whole idea of a standard API will
have failed before we even get started.

So I think that you should decide whether the article is really a call
for a standard API or for participation in Audiality. I am very happy
to contribute my energy, stupidity and some time to the former, but
I'm not terribly interested in the latter. 

As it happens, I've spent a lot of time thinking about your proposed
event-based system, and I suspect that I could get Quasimodo to
support it in a weekend or less, although there would be no plugins
that could use it (yet) :) So for me, this distinction is critical.

--regards,
--p

From - Thu Oct  7 01:30:54 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA24564
	for <slinkp@ulster.net>; Tue, 5 Oct 1999 10:23:24 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA04408 for linux-audio-dev-list; Tue, 5 Oct 1999 09:45:39 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA04405 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 5 Oct 1999 09:45:37 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46659AbPJENkO>; Tue, 5 Oct 1999 16:40:14 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <37F86B31.2781@bath.ac.uk> (P.J.Leonard@bath.ac.uk)
Subject: Re: [linux-audio-dev] new sequencer
Message-Id: <19991005134017Z46659-561+8@nic.funet.fi>
Date:   Tue, 5 Oct 1999 16:40:14 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 6384ab9194ad7c6e9143b5dc573f63e4

>>>> checking for KDE... configure: error: <<<

Arts does have static binary version, Bramhs should have too.

I think it would be very nice to have static binaries of audio programs.
I'm not able to compile any GNOME or KDE programs because I only have GTK+...

Yours,

Juhana

From - Thu Oct  7 01:30:58 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA32256
	for <slinkp@ulster.net>; Tue, 5 Oct 1999 11:11:50 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA04499 for linux-audio-dev-list; Tue, 5 Oct 1999 10:32:47 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA04496 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 5 Oct 1999 10:32:44 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46710AbPJEO1W>; Tue, 5 Oct 1999 17:27:22 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] new GVerb samples
Message-Id: <19991005142726Z46710-563+8@nic.funet.fi>
Date:   Tue, 5 Oct 1999 17:27:22 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 4853248c1253a0507c2e80a586ef5dd6

Hello. For a long time I were improving my GVerb (a late reverb).
It produces now "fake stereo" output and smoother tail. New stereo
samples are available at "http://www.funet.fi/~kouhia/waves/reverb/".
I will make the source code available later.

Yours,

Juhana

From - Thu Oct  7 01:31:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA01266
	for <slinkp@ulster.net>; Tue, 5 Oct 1999 14:38:25 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA01342 for linux-audio-dev-list; Tue, 5 Oct 1999 14:02:38 -0400
Received: from sculpcave (cvx-2-361.dyn.nic.fi [62.236.195.107]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA01339 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 5 Oct 1999 14:02:25 -0400
Received: from localhost (localhost [127.0.0.1])
	by sculpcave (Postfix) with ESMTP
	id CB1AC34D23; Tue,  5 Oct 1999 18:26:54 +0300 (EEST)
Date: Tue, 5 Oct 1999 18:26:54 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
X-Sender: root@sculpcave.localdomain
To: "P.J.Leonard" <P.J.Leonard@bath.ac.uk>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] new sequencer
In-Reply-To: <37F86B31.2781@bath.ac.uk>
Message-ID: <Pine.LNX.4.10.9910051824300.7521-100000@sculpcave.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: cdf29805b0c9c6f6eab811f3abceb203

On Mon, 4 Oct 1999, P.J.Leonard wrote:

>> so, there's a new sequencer program out there, called Brahms.
>> it uses Qt, so i couldn't check it out. (i'm gonna install Qt today)
>  You also need KDE.

Well, only the KDE libs. I have it running under flwm.

-- cut ldd `which Brahms` --
libkfile.so.2 => /opt/kde/lib/libkfile.so.2 (0x40014000)
libkfm.so.2 => /opt/kde/lib/libkfm.so.2 (0x4005e000)
libkdecore.so.2 => /opt/kde/lib/libkdecore.so.2 (0x4006c000)
libqt.so.1 => /usr/lib/libqt.so.1 (0x4010f000)
libkdeui.so.2 => /opt/kde/lib/libkdeui.so.2 (0x4036c000)   
[... X, c++, etc libs]
--cut--

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav
 . http://www.wakkanet.fi/kerttulin_listat/ - music&movies (in Finnish)

From - Thu Oct  7 01:31:02 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA19423
	for <slinkp@ulster.net>; Tue, 5 Oct 1999 13:07:52 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA04727 for linux-audio-dev-list; Tue, 5 Oct 1999 12:34:23 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA04724 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 5 Oct 1999 12:34:19 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m11YWus-000dxtC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Tue, 5 Oct 1999 17:54:14 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Tue,  5 Oct 1999 17:54:14 +0200 (CEST)
To: David Olofson <audiality@swipnet.se>
Cc: John Littler <linuxmusic@crosswinds.net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Draft: Audiality article for MusicStation
In-Reply-To: <99100423092700.00574@localhost.localdomain>
References: <99100423092700.00574@localhost.localdomain>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14330.5265.576349.61042@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id NAA19423
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 625ff84a14e748a4143a57145dafe992

David Olofson writes:
 >
 > Currently, it seems to be evolving into an open design/standardization
 > effort, where a plug-in API and a client/server API currently have higher
 > priority than the actual implementation. The implementation itself may
 > actually end up as a part of some other project.
 > 

 ... and thats the sentence with most relevance for the Plugin API 
 specification. I think we should keep Audiality in mind by designing
 the API, as it stands for one kind of application  with very special needs. 

 But, yes there are other applications for the API, which are to be
 considered as well ... hmmm ... someone ever thought
 of doing audio processing faster than realtime ?
 Thats what most soundeditors are about :) (dont need to tell you).

 As a last word, we should start to build a basis for the API 
 definition by probably writing a kind of RFC, which will be updated
 and reposted each week or two for discussion on audiodev.  

 It is interesting who else (especially authors of applications)
 want to take part in the discussion.

 We may write to authors of audio applications, who probably dont
 read the discussion and ask them what they think about it and 
 if the like to take part. 

 This way we will see potential problems very fast and can react to
 them.


 Guenter

 
 
   
  

From - Thu Oct  7 01:30:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA26961
	for <slinkp@ulster.net>; Tue, 5 Oct 1999 10:37:42 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA04452 for linux-audio-dev-list; Tue, 5 Oct 1999 10:07:07 -0400
Received: from upf.es (newton.upf.es [193.145.54.60]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA04449 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 5 Oct 1999 10:06:42 -0400
Received: from toolazytolookup.com (mtg150.upf.es [193.145.44.150])
	by upf.es (8.9.0/8.9.0) with SMTP id QAA12708
	for linux-audio-dev@ginette.musique.umontreal.ca; Tue, 5 Oct 1999 16:01:28 +0200 (MET DST)
References: <19991005134017Z46659-561+8@nic.funet.fi>
In-Reply-To: <19991005134017Z46659-561+8@nic.funet.fi>
Date: Tue, 5 Oct 1999 15:09:21 CEST
From: maarten de boer <mdeboer@iua.upf.es>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] new sequencer
Organization: iua
Message-ID: <PstOfc.37f9f881.8b4567@localhost>
X-Mailer: PostOffice 0.7
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4cd8395e7c5cdfbf2b026ced30190dc6

Juhana wrote:
> > > > > checking for KDE... configure: error: <<<
> 
> Arts does have static binary version, Bramhs should have too.
> 
> I think it would be very nice to have static binaries of audio programs. 
> I'm not able to compile any GNOME or KDE programs because I only have 
> GTK+...

I think it would be a good idea to try to provide RPMs for these
applications. Building an RPM is rather easy, so if you build an
application, you might want to take the effort of creating the
SPEC file and the RPM. We might want to have some place where to
put all these.

Maarten


From - Thu Oct  7 01:31:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA03473
	for <slinkp@ulster.net>; Tue, 5 Oct 1999 18:08:07 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA01733 for linux-audio-dev-list; Tue, 5 Oct 1999 17:34:46 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA01730 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 5 Oct 1999 17:34:43 -0400
Received: from localhost.localdomain (d212-151-88-221.swipnet.se [212.151.88.221]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id XAA27305; 
          Tue, 5 Oct 1999 23:29:44 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>
Subject: Re: [linux-audio-dev] Draft: Audiality article for MusicStation
Date: Tue, 5 Oct 1999 21:43:45 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
References: <199910050150.VAA25387@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99100523061500.00407@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id XAA27305
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA03473
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 046241c96609eccc41ea0e9aa342c708

On Tue, 05 Oct 1999, Paul Barton-Davis wrote:
> >The language of the API is C. C++ would add more complexity and hidden
> >overhead than it would simplify development, as a single plug-in is a very
> >simple, low level object.
> 
> a small detail. I think the above is needlessly religious.

Yep. I actually had in mind leaving out the motivation altogether, or cutting
it down to "it works for The Kernel"...

> Instead of inviting language wars, you can write:
> 
>   As the Gimp ToolKit (GTK+) has shown very well, it tends to be
>   easier to bind a variety of different languages to an API written
>   for C. This decision makes it possible for users of, for example,
>   C++, Java, and Python to use the API effectively while using the
>   idioms of their chosen language.

Ok.

> And remember, I'm a C++ bigot :)

Well, I usually prefer C++ too, even for RT stuff :-), but I don't think it's
the right tool for this job.

> On a broader front, I feel that its the purpose of the article is a
> little mixed.

Yes. Should be three articles, or at least two...

> Although I think that Audiality is an interesting and
> worthwhile project, it holds no more significance for me than aRtS,
> Brahms or a variety of other excellent pieces of software. By
> contrast, the development of a well-defined plugin API for audio
> applications under Linux is of enormous significance. I may very well
> never use Audiality, but I might write or use a different
> server/engine that supported this standard API, and I might write
> or use plugins that could be used with it.

Yep... But what's the name of the API?

> Reading your article doesn't give me much of a handle on the
> distinction between these two, and makes it sound as if, in order to
> support the development of a standard API, I need to be thinking about
> Audiality. If this is true, then the whole idea of a standard API will
> have failed before we even get started.

That's the strange thing here... Currently, I'm not really working on the
Audiality engine, but on the plug-in API. I have no name for the *interesting*
part of what I'm doing, and besides, I was asked to write about the "proposed
API", referred to as Audiality... Need to make a decision here.

> So I think that you should decide whether the article is really a call
> for a standard API or for participation in Audiality. I am very happy
> to contribute my energy, stupidity and some time to the former, but
> I'm not terribly interested in the latter.

The former is what it's all about. Frankly, by now the Audiality _Engine_ is
little more than my starting point for getting a useful plug-in API together.
Except for the RTL implementation, it may well never be needed.

Audiality is just a name that happened to get mixed up with what I'm currently
trying to do... I didn't expect this much interest when I went public with the
project. I expected to gather a few useful ideas, and then get back to hacking,
not hearing much from anyone before I had yet another engine, living in a world
of it's own like most of the others. At that time, it would have made sense to
find a new name for the API, if anyone would care to use it in other projects.

Now, I have a project name that some people think is the name of the API...
Should have thought about that first! *hehe*

> As it happens, I've spent a lot of time thinking about your proposed
> event-based system, and I suspect that I could get Quasimodo to
> support it in a weekend or less, although there would be no plugins
> that could use it (yet) :) So for me, this distinction is critical.

I'd be happy to see any form of working implementation ASAP. There will most
certainly be details of the API that don't turn out as well in IRL as in the
headers, so I think the best way to get the API ready within the next few
centuries is to hack, and yell some at me as design flaws are encountered. I'll
hack some myself of course, but as I don't have a working engine of my own to
play with anyway, perhaps I'd better stay around the design department for now.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Thu Oct  7 01:31:17 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA23913
	for <slinkp@ulster.net>; Tue, 5 Oct 1999 20:22:34 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA02046 for linux-audio-dev-list; Tue, 5 Oct 1999 20:05:04 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id UAA02043 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 5 Oct 1999 20:05:02 -0400
From: est@hyperreal.org
Received: (qmail 29440 invoked by uid 162); 5 Oct 1999 21:02:09 -0000
Message-ID: <19991005210209.29439.qmail@hyperreal.org>
Subject: [linux-audio-dev] powerpc/g4
In-Reply-To: <199910020218.WAA12898@renoir.op.net> from Paul Barton-Davis at
 "Oct 1, 1999 11:14:47 pm"
To: Paul Barton-Davis <pbd@Op.Net>
Date: Tue, 5 Oct 1999 14:02:09 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 813ce541bcbcdb2240dc7012cb97ba94

Paul Barton-Davis discourseth:
> >Sometimes I wonder how Linux is running G4 PowerMacs.
> 
> You're not the only one :) OTOH, its not clear to what extent there is
> any plan to offer SMP motherboards or support for the G4. Also, Benno
> pointed me at the AMD K7 (Athlon) which looks like it should be able
> to match the G4 *and* will have SMP motherboards available RSN. The
> price is right, too.

i'm excited about both!

g4 has the altivec simd unit which has 32 128-bit registers and a
beautiful instruction set.  3dnow on the athlon, otoh, is virtually
broken..i haven't heard whether amd has plans to fix this

also, i'd bet money that there will be some interesting powerpc
hardware alternatives next year..check out www.totalimpact.com, for
example

Eric

From - Thu Oct  7 01:31:13 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA04187
	for <slinkp@ulster.net>; Tue, 5 Oct 1999 18:12:14 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA01738 for linux-audio-dev-list; Tue, 5 Oct 1999 17:34:53 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA01735 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 5 Oct 1999 17:34:50 -0400
Received: from localhost.localdomain (d212-151-88-221.swipnet.se [212.151.88.221]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id XAA27360; 
          Tue, 5 Oct 1999 23:29:46 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Guenter Geiger <geiger@epy.co.at>
Subject: Re: [linux-audio-dev] Draft: Audiality article for MusicStation
Date: Tue, 5 Oct 1999 23:09:47 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: John Littler <linuxmusic@crosswinds.net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
References: <14330.5265.576349.61042@gige>
MIME-Version: 1.0
Message-Id: <99100523311901.00407@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id XAA27360
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA04187
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3a3bbc509bb251a80a0ef6ceb32a6379

On Tue, 05 Oct 1999, Guenter Geiger wrote:
> David Olofson writes:
>  >
>  > Currently, it seems to be evolving into an open design/standardization
>  > effort, where a plug-in API and a client/server API currently have higher
>  > priority than the actual implementation. The implementation itself may
>  > actually end up as a part of some other project.
>  > 
> 
>  ... and thats the sentence with most relevance for the Plugin API 
>  specification. I think we should keep Audiality in mind by designing
>  the API, as it stands for one kind of application  with very special needs.
> 
>  But, yes there are other applications for the API, which are to be
>  considered as well ... hmmm ... someone ever thought
>  of doing audio processing faster than realtime ?
>  Thats what most soundeditors are about :) (dont need to tell you).

I see no problem here... Plug-ins and sub nets of plug-ins sync to the data
streams, and the event system's time stamps are sample frames. Real time
systems sync to the I/O devices, while off-line systems sync to the hard drive
(or whatever media used).

>  As a last word, we should start to build a basis for the API 
>  definition by probably writing a kind of RFC, which will be updated
>  and reposted each week or two for discussion on audiodev.  
> 
>  It is interesting who else (especially authors of applications)
>  want to take part in the discussion.

Agree.

>  We may write to authors of audio applications, who probably dont
>  read the discussion and ask them what they think about it and 
>  if the like to take part. 

Actually, I'd like to hear from other kinds of multimedia developers as well.
If the buffers + event system foundation of the plug-in API can be kept as low
level and generic as I'd like, there's no excuse for dedicating it to audio.
POSIX I/O, /dev, IPC and pipes works well for most things. This is about the
same thing, but with optimized real time streaming support.

>  This way we will see potential problems very fast and can react to
>  them.

Yep, and that's why I'd like to see some prototype implementations soon, so
that lower level or more obscure design flaws can be found as well.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Thu Oct  7 01:31:16 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA21404
	for <slinkp@ulster.net>; Tue, 5 Oct 1999 20:05:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA01998 for linux-audio-dev-list; Tue, 5 Oct 1999 19:41:11 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA01994 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 5 Oct 1999 19:41:08 -0400
Received: from localhost.localdomain (d212-151-45-20.swipnet.se [212.151.45.20]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA27904; 
          Wed, 6 Oct 1999 01:35:55 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Draft: Audiality article for MusicStation
Date: Wed, 6 Oct 1999 00:36:13 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199910052202.SAA29161@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99100601423703.00407@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id BAA27904
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA21404
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b2736a37a74c3a82d6704de03bc87b83

On Wed, 06 Oct 1999, Paul Barton-Davis wrote:
> Finally, after all that wasted time talking about design, We get down
> the heart of things ! :))))
> 
> >Yep... But what's the name of the API?

Exactly! :-))

> Here are a few midst-of-the-hack ideas:
> 
> LAPS     Linux Audio Plugin Standard
> LAPLAND  Linux Audio Plugin Language and Design
> LAPI     Linux Audio Plugin Interface

Linux specific? That could possibly be OK for an implementation...

> YAPI     Yet Another Plugin Interface
> TAPDANCE The Audio Plugin Definition ANd Connection Extension
> LAPDOG   Linux Audio Plugin Definition 
> SOCKET   Sound Connection and Key Extension Tools
> GACK     GNU Audio Connector Kit

Graphic Adventure Construction Kit, IIRC... (Old C64 title. :-)

> TEDIUM   This Extension Definition Is Under new Management
> inVeST   is not VeST

TREPIN    The REal Plugin INterface
IIAPI     IIAPI Is A Plugin Interface

However, I'd like the client/server API to be a part of the definition as
well... And audio only is too restrictive.

PACIM     Plugin And Client Interface for Multimedia (Boring...)
MUMIS     MUltiMedia Integration Standard (*hehe*)
MINI      Multimedia INtegration Interface
MINTIN    Multimedia INTegration INterface

Not very inspired today...

And typing on a Dvorak layout is still a bit tiresome one day after the
switch...! *hehe* It does make a lot more sense than Qwerty, though. (You have
many frequently used words completely on the homeline.) Relearning is not as
hard as it may appear. :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Thu Oct  7 01:31:14 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA07039
	for <slinkp@ulster.net>; Tue, 5 Oct 1999 18:31:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA01795 for linux-audio-dev-list; Tue, 5 Oct 1999 18:07:23 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA01792 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 5 Oct 1999 18:07:20 -0400
Received: from someip.ppp.op.net (d-bm2-08.ppp.op.net [209.152.194.40]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id SAA29161 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 5 Oct 1999 18:02:23 -0400 (EDT)
Message-Id: <199910052202.SAA29161@renoir.op.net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Draft: Audiality article for MusicStation 
In-reply-to: Your message of "Tue, 05 Oct 1999 21:43:45 +0200."
             <99100523061500.00407@localhost.localdomain> 
Date: Tue, 05 Oct 1999 19:00:00 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b308e0c24ceac4e6f9e90b96dda22c72

Finally, after all that wasted time talking about design, We get down
the heart of things ! :))))

>Yep... But what's the name of the API?

Here are a few midst-of-the-hack ideas:

LAPS     Linux Audio Plugin Standard
LAPLAND  Linux Audio Plugin Language and Design
LAPI     Linux Audio Plugin Interface
YAPI     Yet Another Plugin Interface
TAPDANCE The Audio Plugin Definition ANd Connection Extension
LAPDOG   Linux Audio Plugin Definition 
SOCKET   Sound Connection and Key Extension Tools
GACK     GNU Audio Connector Kit
TEDIUM   This Extension Definition Is Under new Management
inVeST   is not VeST

I don't like any of these very much, but I know that Dan Hollis can
often come up with the goods in this department :)

Anything that reeks of generality, typical understated Linux humor is
welcome by me, and there are extra points for a good recursive
acronym.

--p

From - Thu Oct  7 01:31:18 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA13708
	for <slinkp@ulster.net>; Tue, 5 Oct 1999 22:46:45 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA02265 for linux-audio-dev-list; Tue, 5 Oct 1999 22:23:07 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA02262 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 5 Oct 1999 22:23:04 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id WAA17519
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 5 Oct 1999 22:17:42 -0400 (EDT)
Received: from localhost by ux02 (8.9.1b+Sun) id WAA07362; Tue, 5 Oct 1999 22:17:43 -0400 (EDT)
Date: Tue, 5 Oct 1999 22:17:43 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] new sequencer
In-Reply-To: <19991003213707.A209@cerealbox>
Message-ID: <Pine.GSO.4.10.9910052205130.7265-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: bbdcd45f1d3b0c887df84b2b66aab9ad

On Sun, 3 Oct 1999, RACZ Mate (reactor/CTPmedia) wrote:

> so, there's a new sequencer program out there, called Brahms.

Umm, nobody noticed that "Brahms" is just the new name of Kubase?  As I'm
not a particularly big fan of the real Cubase, I think it's a step in the
right direction that they've given up trying to clone the name... maybe it
also means they'll stop trying to clone the program and instead create
something truly great on their own.

On a side note (so to speak), has anybody played with Cantor, the other
Qt-based sequencer project?  It was a very quiet project, no announcements
and no web site, and I don't know if it ever got very far.  Is it
worthwhile downloading, building, and installing it?

Div.

From - Thu Oct  7 01:31:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA25088
	for <slinkp@ulster.net>; Wed, 6 Oct 1999 00:29:40 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA02395 for linux-audio-dev-list; Tue, 5 Oct 1999 23:59:08 -0400
Received: from www.tomy.net (www.tomy.net [209.186.149.104]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA02391 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 5 Oct 1999 23:59:05 -0400
From: thudson@cygnus.com
Received: from cygnus.com (IDENT:thudson@jimi.tomy.net [192.168.1.2])
	by www.tomy.net (8.9.3/8.9.3) with ESMTP id XAA27360
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 5 Oct 1999 23:54:11 -0400
Message-ID: <37FAC802.60CA7058@cygnus.com>
Date: Tue, 05 Oct 1999 23:54:42 -0400
Organization: Cygnus Solutions
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
CC: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Plugin API
References: <199910052202.SAA29161@renoir.op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 6b5b33d7fba9fb23f858d62df5b0d60f


What is the possibility of making at least a subset of the API
cross-platform. These days when everyone feels that Linux has
already achieved World Domination(TM), it is easy to loose sight
of the fact that 'Freedom of Choice (TM)' was once a noble goal.
Perhaps a good, simple, easily supported cross-platform API would
entice closed-source vendors to consider Linux, thus enhancing
perception of Linux to hardware vendors. 

If latency happens to suck on particular platforms after the API
becomes a standard...

Thomas

From - Thu Oct  7 01:31:21 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA28955
	for <slinkp@ulster.net>; Wed, 6 Oct 1999 01:19:46 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA02758 for linux-audio-dev-list; Wed, 6 Oct 1999 00:47:22 -0400
Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [207.175.42.154]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA02755 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 00:47:19 -0400
Received: from localhost (sopwith@localhost)
	by lacrosse.corp.redhat.com (8.9.3/8.9.3) with ESMTP id AAA24044;
	Wed, 6 Oct 1999 00:42:19 -0400
Date: Wed, 6 Oct 1999 00:42:19 -0400 (EDT)
From: Elliot Lee <sopwith@redhat.com>
X-Sender: sopwith@lacrosse.corp.redhat.com
To: thudson@cygnus.com
cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Plugin API
In-Reply-To: <37FAC802.60CA7058@cygnus.com>
Message-ID: <Pine.LNX.4.10.9910060039250.23860-100000@lacrosse.corp.redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 44421cd6b7a6ca4e46b0bda70469fd1a

On Tue, 5 Oct 1999 thudson@cygnus.com wrote:

> What is the possibility of making at least a subset of the API
> cross-platform.

Unless the API is somehow relying on stuff from the kernel headers (which
would make it "broken" in any case), it's already cross-platform. It's
possible to implement almost any given API on a cross-platform basis. An
example that comes to mind is gtk+, which was written with only UNIX in
mind, but has been ported to Windows (BeOS in progress).

I think you'd have to try very hard to come up with an example of an API
that wasn't cross-platform.
-- Elliot					http://developer.gnome.org/
The first thing a programmer needs to admit is that any program is by far
more complex than his own mind. Thats why he partitions it into neat
pieces and avoids complexity.

From - Thu Oct  7 01:31:22 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA30828
	for <slinkp@ulster.net>; Wed, 6 Oct 1999 01:51:09 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id BAA06656 for linux-audio-dev-list; Wed, 6 Oct 1999 01:34:17 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA06653 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 01:34:14 -0400
Received: from op.net (d-bm2-0e.ppp.op.net [209.152.194.46]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id BAA02605 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 01:29:15 -0400 (EDT)
Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id CAA00965; Wed, 6 Oct 1999 02:24:43 -0400
Date: Wed, 6 Oct 1999 02:24:43 -0400
Message-Id: <199910060624.CAA00965@op.net>
From: Paul Barton-Davis <pbd@Op.Net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] API design again
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 40d039a6ba74dc1ebf3f9ed33790834a

I'd like to hear Gunter and David discuss the issue of varying the
process() "sample count argument" again. 

I understand both of their positions, and I'm worried that I am
missing something important. Would you both care to argue a little for
or against calling process() with a variable sample count vs. with a
fixed count and a sample-accurate event buffer ?

--p

From - Thu Oct  7 01:31:23 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA30855
	for <slinkp@ulster.net>; Wed, 6 Oct 1999 01:51:29 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id BAA06662 for linux-audio-dev-list; Wed, 6 Oct 1999 01:34:30 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA06659 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 01:34:27 -0400
Received: from someip.ppp.op.net (d-bm2-0e.ppp.op.net [209.152.194.46]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id BAA02614 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 01:29:29 -0400 (EDT)
Message-Id: <199910060529.BAA02614@renoir.op.net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Plugin API 
In-reply-to: Your message of "Tue, 05 Oct 1999 23:54:42 EDT."
             <37FAC802.60CA7058@cygnus.com> 
Date: Wed, 06 Oct 1999 02:24:58 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 08fcf619b116227f2f4b277279b5ff94

>What is the possibility of making at least a subset of the API
>cross-platform ?

Thomas - I don't think that any of us are thinking of a Linux-specific
API. Certainly nothing that has been discussed here has been Linux
specific except for a few of my hokey name "suggestions".

But I want so sound a cautionary note about plugin API's. If defining
(and implementing) a reasonable API was all it took to get everyone to
use it, then why doesn't digidesign use VST ? Why doesn't the GIMP use
TDM ? Why doesn't Netscape use EASI ? 

Everyone has their own idea of what a plugin API should accomplish,
and the situation is worse for us, since we *do* have freedom of
choice, or rather, freedom to recode. Since we don't have Steinberg,
Emagic or Digidesign breathing down our backs (or holding our hands),
if we don't like the LADAPI, we can simply implement our own - with
dlopen(2) as your friend, it doesn't take long. This is, of course,
good and bad.

I know that one of the joys of the programming I do nowadays, as
opposed to the stuff I did in the past when people paid me to do it,
is that I can make it work *just right*. It only takes a couple of
minor problems with an existing library, and I'll tend to roll my
own. 

If the API under discussion here is to succeed, there must be
*compelling* reasons to use it. By "it", I must stress that I mean the
API, not the facilities that can be accessed by using it, since under
Linux, they are always available via other routes.

--p

From - Thu Oct  7 01:31:24 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id FAA09472
	for <slinkp@ulster.net>; Wed, 6 Oct 1999 05:31:51 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA07600 for linux-audio-dev-list; Wed, 6 Oct 1999 05:00:19 -0400
Received: from pat.bath.ac.uk (pat.bath.ac.uk [138.38.32.2]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id FAA07597 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 05:00:16 -0400
Received: (qmail 28431 invoked from network); 6 Oct 1999 08:55:16 -0000
Received: from mary.bath.ac.uk (HELO bath.ac.uk) (mmdf@138.38.32.14)
  by pat.bath.ac.uk with SMTP; 6 Oct 1999 08:55:16 -0000
Received: from tesla.bath.ac.uk by mary.bath.ac.uk id aa19325; 6 Oct 99 9:55 BST
Message-ID: <37FB0E6F.18FBB882@bath.ac.uk>
Date: Wed, 06 Oct 1999 09:55:11 +0100
From: "P.J.Leonard" <P.J.Leonard@bath.ac.uk>
Organization: Applied Electromagnetic Research Centre
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.6 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: David Slomin <dgslomin@cs.princeton.edu>
CC: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] new sequencer
References: <Pine.GSO.4.10.9910052205130.7265-100000@ux02.CS.Princeton.EDU>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7877183018b33de848762bf8ec2c672a

David Slomin wrote:

> On a side note (so to speak), has anybody played with Cantor, the other
> Qt-based sequencer project?  It was a very quiet project, no announcements
> and no web site, and I don't know if it ever got very far.  Is it
> worthwhile downloading, building, and installing it?

 Hello,

  I am responsible for cantor. There is no work going on at present.
There seems to be little point in continuing now kooBase (now Brahms)
has taken over the Qt slot. There are I believe at least 3 people
working
on Brahms/aRts they seem very keen and I have very little time myself.

We did talk about sharing a common song structure which could be used by
both projects with some sort of CORBA  interface. But the practical
difficulties
seem to be too great. I am not sure what Brahms is doing long term about 
the problems of using OSS. When I tried out kooBase I liked the GUI but
the sequencing was a bit unstable. 

 If you have an AWE32 with some memory and a midi keyboard
then you might like to play with cantor. It allows you to load
individual
patches from the .SF2 font files. You can also use it to map midi
controllers
onto any of the AWE32 voice parameters (make your pitch wheel into a wah
input).
YOu can also load midi files and then play along if you want.

 The music representation also implements a subject observer pattern
which
is useful for building GUI which automatically redisplay phrases etc (I
did
not see this in kooBase ?).

 The interface to edit songs just about works and I have written stuff
using it
but it is not very intuitive unless you share the same brain patterns as
me.


  cheers Paul.

From - Thu Oct  7 01:31:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA30959
	for <slinkp@ulster.net>; Wed, 6 Oct 1999 09:20:47 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA07868 for linux-audio-dev-list; Wed, 6 Oct 1999 08:46:28 -0400
Received: from www.tomy.net (www.tomy.net [209.186.149.104]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA07865 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 08:46:26 -0400
From: thudson@cygnus.com
Received: from cygnus.com (IDENT:thudson@jimi.tomy.net [192.168.1.2])
	by www.tomy.net (8.9.3/8.9.3) with ESMTP id IAA27877;
	Wed, 6 Oct 1999 08:41:27 -0400
Message-ID: <37FB439A.824C1321@cygnus.com>
Date: Wed, 06 Oct 1999 08:42:02 -0400
Organization: Cygnus Solutions
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Elliot Lee <sopwith@redhat.com>
CC: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Plugin API
References: <Pine.LNX.4.10.9910060039250.23860-100000@lacrosse.corp.redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7848057debd23c2d31bc0c23b846cb3f

Elliot Lee wrote:

> Unless the API is somehow relying on stuff from the kernel headers (which
> would make it "broken" in any case), it's already cross-platform. It's
> possible to implement almost any given API on a cross-platform basis. An
> example that comes to mind is gtk+, which was written with only UNIX in
> mind, but has been ported to Windows (BeOS in progress).

Yes. But there is a big difference between compiling/running on a
given platform and being platform agnostic. I haven't seen any commercial
products using gtk+ on windows.

I agree that for an audio plugin API in C, chances are pretty good that
it would be fairly cross-platform, as long as there was no mix of gui
code. Perhaps the point I should have made is that some thought should
be given to existing plugin API's, so that vendors would not have difficulty
moving their existing code to Linux.

> 
> I think you'd have to try very hard to come up with an example of an API
> that wasn't cross-platform.

DirectX

Thomas

From - Thu Oct  7 01:31:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA04252
	for <slinkp@ulster.net>; Wed, 6 Oct 1999 09:57:34 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA07952 for linux-audio-dev-list; Wed, 6 Oct 1999 09:12:22 -0400
Received: from www.tomy.net (www.tomy.net [209.186.149.104]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA07949 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 09:12:20 -0400
From: thudson@cygnus.com
Received: from cygnus.com (IDENT:thudson@jimi.tomy.net [192.168.1.2])
	by www.tomy.net (8.9.3/8.9.3) with ESMTP id JAA27907;
	Wed, 6 Oct 1999 09:07:14 -0400
Message-ID: <37FB49A5.91703AEC@cygnus.com>
Date: Wed, 06 Oct 1999 09:07:49 -0400
Organization: Cygnus Solutions
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Barton-Davis <pbd@Op.Net>
CC: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Plugin API
References: <199910060529.BAA02614@renoir.op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e84e1dda90dcb5a960fea6e1ab929559

Paul Barton-Davis wrote:

> If the API under discussion here is to succeed, there must be
> *compelling* reasons to use it. By "it", I must stress that I mean the
> API, not the facilities that can be accessed by using it, since under
> Linux, they are always available via other routes.
> 
Thanks for better stating what I was trying to get across. The API is
worthless if not widely adopted. If one could go to a vendor of
commercial plugins and show them how easy it was to support this API
alongside VST or [plugin api du jour], more code might be ported to
linux and along with it more pro hardware support. I really believe
that the first pro audio vendor to annouce support for Linux will
open the floodgate. Everyone has a wait and see attitude, but no one
wants to be left behind.

It might be possible to write a VST-compatible layer on top of this 
API. However, if this API assumes functionality in the plugin that
most existing APIs don't implement, it would be difficult to do.

Thomas

From - Thu Oct  7 01:31:37 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA30745
	for <slinkp@ulster.net>; Wed, 6 Oct 1999 12:51:05 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA08065 for linux-audio-dev-list; Wed, 6 Oct 1999 10:07:59 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA08062 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 10:07:56 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m11Yr7O-000dy0C@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Wed, 6 Oct 1999 15:28:30 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Wed,  6 Oct 1999 15:28:30 +0200 (CEST)
To: Paul Barton-Davis <pbd@Op.Net>
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] API design again
In-Reply-To: <199910060624.CAA00965@op.net>
References: <199910060624.CAA00965@op.net>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14331.19292.243358.830223@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: ff7d5a7515c818023d06b774d2b811dc

Paul Barton-Davis writes:
 > I'd like to hear Gunter and David discuss the issue of varying the
 > process() "sample count argument" again. 
 > 

 Actually I didn't discuss it that much but  ...
 ... digging in the archives .....

 Davids code:

------------------------------------------------------------------------
process(...**inputs, ...**outputs, ...**events, samples)
{
	int current_sample = 0;
	int current_event = 0;
	int count;
	while(current_sample < samples) {
		/* process until next event should take effect */
		count = event[current_event]->time - current_sample;
		current_sample = [current_event]->time;
		while(count--) {
			process one sample;
		}
		/* handle event... */
			.
			.
			.
	}
}
-----------------------------------------------------------------------

as opposed to the other (Benno/Paul) proposal (which does basically the same):

-----------------------------------------------------------------------
event_time=event.time;  (in samples)
samples_before_event=actual_time-event_time;
rest_samples=samples_per_buffer=samples_before_event;

pluginobj->process(inputs,outputs,samples_before_event)

process the event (change parameters etc)

pluginobj->process(inputs,outputs,samples_after_event);

----------------------------------------------------------------------


Under the assumption, that events occur on a basis smaller than 
the processing blocksize, this is equally fast as fixed buffers,
but with sample accuracy.

The big advantage: 
==================

Plugins can be written as ever without taking care of the applications
implementation, be that fixed buffers, the events system, 
single sample (only for networks with recursions).

The plugin programmer only has to take care that the plugin works
with different block sizes down to 1.

Guenter
 

From - Thu Oct  7 01:31:34 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA26087
	for <slinkp@ulster.net>; Wed, 6 Oct 1999 12:20:55 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA08267 for linux-audio-dev-list; Wed, 6 Oct 1999 11:48:20 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA08264 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 11:48:17 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m11YsgR-000dy0C@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Wed, 6 Oct 1999 17:08:47 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Wed,  6 Oct 1999 17:08:47 +0200 (CEST)
To: Paul Barton-Davis <pbd@Op.Net>
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] API design again 
In-Reply-To: <199910061435.KAA02834@renoir.op.net>
References: <14331.19292.243358.830223@gige>
	<199910061435.KAA02834@renoir.op.net>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14331.25584.522781.936285@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id MAA26087
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 6d2ac812fcb476545d7a12d334b4c8c5

Paul Barton-Davis writes:
 > However, the benefit of the plugin's own code being *independent* of
 > the API framework seems enormous. 

Exactly, and, this is in line with the concerns Thomas issued about
porting plugins from other standards.

Well, well see if David can live with this. Best thing to solve this 
problem would be by implementing and events system with both schemes
and look at the performance. It doesnt help us much if we spare
5 % of processing power by loosing that much of flexibility.

Guenter  

From - Thu Oct  7 01:31:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA15549
	for <slinkp@ulster.net>; Wed, 6 Oct 1999 11:11:59 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA08131 for linux-audio-dev-list; Wed, 6 Oct 1999 10:40:31 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA08128 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 10:40:27 -0400
Received: from someip.ppp.op.net (d-bm3-12.ppp.op.net [209.152.194.82]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id KAA02834 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 10:35:26 -0400 (EDT)
Message-Id: <199910061435.KAA02834@renoir.op.net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] API design again 
In-reply-to: Your message of "Wed, 06 Oct 1999 15:28:30 +0200."
             <14331.19292.243358.830223@gige> 
Date: Wed, 06 Oct 1999 11:31:00 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f4f095130291e5ad6f6b7c8b7528a666

>The big advantage: 
>==================
>
>Plugins can be written as ever without taking care of the applications
>implementation, be that fixed buffers, the events system, 
>single sample (only for networks with recursions).
>
>The plugin programmer only has to take care that the plugin works
>with different block sizes down to 1.

Thanks. 

David has raised concerns about efficiency, which I think probably
refers to the function call overhead associated with this
situation. Notice that:

	   process the event

probably involves something like:

	   pluginobj->notify (event)

for each (active?) plugin.

So you could end up calling 3N where N is the number of active plugins
instead of just N. Given that in some cases, the samples_to_process
might be very small, the function call overhead of this scheme is not
necessarily small, although most of the time, it probably will be
because the event density is so low.

However, the benefit of the plugin's own code being *independent* of
the API framework seems enormous. One of my concerns about David's
proposed event system is the amount of work it would take to port
existing DSP code to use it, because it has to be aware of the event
model. 

By contrast, if we adopted this model, we could adopt, for example,
all or many of the Csound opcodes with "very little" effort. They all
currently rely on a global called nsmps. "All" we'd have to do to use
them would be to make nsmps the name of the buffer size argument (as
declared in their source), and presto - they'd do the right thing. Of
course, in reality, there would be more to it than that, but not
much. I imagine that many other examples of DSP code could be used in
a similar way.

--p

From - Thu Oct  7 01:31:54 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA15413
	for <slinkp@ulster.net>; Wed, 6 Oct 1999 14:43:19 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA08581 for linux-audio-dev-list; Wed, 6 Oct 1999 14:20:15 -0400
Received: from sculpcave (cvx-2-768.dyn.nic.fi [62.236.197.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA08578 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 14:20:10 -0400
Received: from localhost (localhost [127.0.0.1])
	by sculpcave (Postfix) with ESMTP
	id 2534B34D22; Wed,  6 Oct 1999 19:58:55 +0300 (EEST)
Date: Wed, 6 Oct 1999 19:58:55 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
X-Sender: root@sculpcave.localdomain
To: Guenter Geiger <geiger@epy.co.at>
Cc: David Olofson <audiality@swipnet.se>,
        John Littler <linuxmusic@crosswinds.net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Draft: Audiality article for MusicStation
In-Reply-To: <14330.5265.576349.61042@gige>
Message-ID: <Pine.LNX.4.10.9910061712040.725-100000@sculpcave.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by nerf.ulster.net id OAA15413
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 90d2674c5dc08009e2e374d81b6f6917

On Tue, 5 Oct 1999, Guenter Geiger wrote:

>  It is interesting who else (especially authors of applications)
>  want to take part in the discussion.
[...] 
>  We may write to authors of audio applications, who probably dont
>  read the discussion and ask them what they think about it and 
>  if the like to take part. 

This is an important point. Number of people have asked me about
OpS (or whatever), but currently all I can say is that they should 
join this list. Starting to keep a list archive would help 
and even better, if someone has time to create a simple web site 
for this project, that would be great.

One thing that might help this project would be to collect 
a list of linux applications and people (well, apps are often
better known in the open-source world) that are involved.

So, all programmers out there: What software are you working on 
right now and are you ready to add support for OpS and maybe 
convert your existing effects to OpS?

As for myself, I'm ready to add OpS support for ecasound as soon
as we have something usable. 

If/when I can grasp what David's event system is all about,
I can start commenting on the design. ;) I guess a concrete 
use-case example would help. 

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav
 . http://www.wakkanet.fi/kerttulin_listat/ - music&movies (in Finnish)

From - Thu Oct  7 01:31:46 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA11094
	for <slinkp@ulster.net>; Wed, 6 Oct 1999 14:14:06 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA08498 for linux-audio-dev-list; Wed, 6 Oct 1999 13:48:17 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA08495 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 13:48:14 -0400
Received: from localhost.localdomain (d212-151-92-92.swipnet.se [212.151.92.92]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id TAA07668; 
          Wed, 6 Oct 1999 19:43:04 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: thudson@cygnus.com, Elliot Lee <sopwith@redhat.com>
Subject: Re: [linux-audio-dev] Plugin API
Date: Wed, 6 Oct 1999 19:46:31 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
References: <37FB439A.824C1321@cygnus.com>
MIME-Version: 1.0
Message-Id: <99100619494800.00450@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id TAA07668
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id OAA11094
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 498f72ad1303cd37a5d91d1943928942

On Wed, 06 Oct 1999, thudson@cygnus.com wrote:
> > I think you'd have to try very hard to come up with an example of an API
> > that wasn't cross-platform.
> 
> DirectX

Yeah... And M$ worked pretty hard on making sure DirectX got as Windoze
dependent as possible. As usual...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Thu Oct  7 01:31:53 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA14872
	for <slinkp@ulster.net>; Wed, 6 Oct 1999 14:39:15 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA08553 for linux-audio-dev-list; Wed, 6 Oct 1999 14:10:15 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA08550 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 14:10:12 -0400
Received: from localhost.localdomain (d212-151-92-92.swipnet.se [212.151.92.92]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id UAA07396; 
          Wed, 6 Oct 1999 20:05:03 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: thudson@cygnus.com, Paul Barton-Davis <pbd@Op.Net>
Subject: Re: [linux-audio-dev] Plugin API
Date: Wed, 6 Oct 1999 19:51:29 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
References: <37FB49A5.91703AEC@cygnus.com>
MIME-Version: 1.0
Message-Id: <99100620114601.00450@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id UAA07396
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id OAA14872
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5e02b2b51d65003ba42e6fb461365247

On Wed, 06 Oct 1999, thudson@cygnus.com wrote:
> It might be possible to write a VST-compatible layer on top of this 
> API. However, if this API assumes functionality in the plugin that
> most existing APIs don't implement, it would be difficult to do.

The only functionality that my idea of this API assumes, is the low level stuff,
like how buffers are passed to the process() function and that kind of things.
The initialization events only add functionality that makes it *easier* to fit
other kinds of plug-ins into the system. The "foreign plug-in interface layer"
gets a chance to express more in detail how it wants to interface with the
engine.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Thu Oct  7 01:31:43 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA09598
	for <slinkp@ulster.net>; Wed, 6 Oct 1999 14:05:24 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA08454 for linux-audio-dev-list; Wed, 6 Oct 1999 13:26:33 -0400
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA08451 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 13:26:30 -0400
Received: from d1o43.telia.com (root@d1o43.telia.com [194.22.195.241])
	by mailb.telia.com (8.9.3/8.9.3) with ESMTP id TAA26617
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 19:21:29 +0200 (CEST)
Received: from skelleftea.mail.telia.com (t3o43p7.telia.com [194.22.195.127])
	by d1o43.telia.com (8.8.8/8.8.5) with ESMTP id TAA24113
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 19:21:27 +0200 (CEST)
Message-ID: <37FB8F81.3B821FDC@skelleftea.mail.telia.com>
Date: Wed, 06 Oct 1999 19:05:53 +0100
From: Roger Larsson <roger.larsson@skelleftea.mail.telia.com>
X-Mailer: Mozilla 4.6 [en] (Win95; I)
X-Accept-Language: sv,en
MIME-Version: 1.0
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] API design again
References: <199910061435.KAA02834@renoir.op.net>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by mailb.telia.com id TAA26617
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id OAA09598
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0b20fdfef1aef48f4f4db0b7dcfb4a89



Paul Barton-Davis wrote:
> 
> >The big advantage:
> >==================
> >
> >Plugins can be written as ever without taking care of the applications
> >implementation, be that fixed buffers, the events system,
> >single sample (only for networks with recursions).
> >
> >The plugin programmer only has to take care that the plugin works
> >with different block sizes down to 1.
> 
> Thanks.
> 
> David has raised concerns about efficiency, which I think probably
> refers to the function call overhead associated with this
> situation. Notice that:
> 
>            process the event
> 
> probably involves something like:
> 
>            pluginobj->notify (event)
> 
> for each (active?) plugin.

Yes but the event is supposed to affect the current executing plugin
only (my interpretation) and can then be coded as:
  selfHandleEvent(event);	// could be inlined by the compiler,
// or at least it is a static call, no miss in jump prediction.
  engineGetNextEvent(this, event); // Have not seen this
shouldn't we be able to process more than one event during one
buffer....
(or was the event a linked list)

[Side note: misses in jump prediction are costly. You have to restart
the
 processors pipeline. You can avoid misses in selfHandleEvent by
treating
 the event as an (index,value) pair and only doing:

static inline selfHandleEvent(event) {
  int index = event.index;
  float value = event.data;
  if (index >= 0 && index < maxParameter) ... // predicated correctly
  parameter[index] = value; // instead of switch(index)]
}


]

It also does simplify coding for FFT since you get the same size all the
time,
you would probably need less memory to keep state from previous.
(Especially
if the plugin can specify buffer size)

> 
> So you could end up calling 3N where N is the number of active plugins
> instead of just N. Given that in some cases, the samples_to_process
> might be very small, the function call overhead of this scheme is not
> necessarily small, although most of the time, it probably will be
> because the event density is so low.
> 
> However, the benefit of the plugin's own code being *independent* of
> the API framework seems enormous. One of my concerns about David's
> proposed event system is the amount of work it would take to port
> existing DSP code to use it, because it has to be aware of the event
> model.
> 

It should be easy to write a compatibility plugin that calls plugins
without event handling. The reverse is not true...

// Pseudocode...
compatibilityPlugin(..., event)
current = 0;
for(full range)
{
   partSize = nextEvent - current;

   plugin->process(..., current, partSize);

   plugin->processEvent(event);
   current = nextEvent;
   engineGetNextEvent(plugin, event) // the last event is not removed
}


> By contrast, if we adopted this model, we could adopt, for example,
> all or many of the Csound opcodes with "very little" effort. They all
> currently rely on a global called nsmps. "All" we'd have to do to use
> them would be to make nsmps the name of the buffer size argument (as
> declared in their source), and presto - they'd do the right thing. Of
> course, in reality, there would be more to it than that, but not
> much. I imagine that many other examples of DSP code could be used in
> a similar way.
> 
> --p

-- 

The Internet interprets Windows as damage, 
             and routes around it.

Roger Larsson
Skellefte
Sweden

From - Thu Oct  7 01:31:55 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA16459
	for <slinkp@ulster.net>; Wed, 6 Oct 1999 14:50:06 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA08591 for linux-audio-dev-list; Wed, 6 Oct 1999 14:23:00 -0400
Received: from bashir.belgium.eu.net (bashir.Belgium.EU.net [193.74.208.147]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA08587 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 14:22:58 -0400
Received: from (adial176.liege.eunet.be [195.207.174.176])
	by bashir.belgium.eu.net  with SMTP id UAA22370 
	for <linux-audio-dev@ginette.musique.umontreal.ca>;
	Wed, 6 Oct 1999 20:17:50 +0200 (MET DST)
Subject: Re: [linux-audio-dev] Plugin API
From: Benjamin GOLINVAUX <golinvaux@benjamin.net>
Reply-To: Benjamin GOLINVAUX <golinvaux@benjamin.net>
In-Reply-To: <99100619494800.00450@localhost.localdomain>
Message-ID: <0003563a5deea79d_mailit@relay.eunet.be>
References: <37FB439A.824C1321@cygnus.com> <99100619494800.00450@localhost.localdomain>
Date: Wed, 06 Oct 1999 20:13:34 +0200
X-Mailer: BeatWare Mail-It 2.0.3
X-BeOS-Platform: Intel or clone
X-Priority: 3 (Normal)
To: linux-audio-dev@ginette.musique.umontreal.ca
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 62464c70989e366f735a7400edc06316

>Yeah... And M$ worked pretty hard on making sure DirectX got as Windoze
>dependent as possible. As usual...

Hum Hem Hom Erm Glop

DirectX is based on COM... it _is_ a crappy interface for audio, but any COM 
implementation could host a DirectX set of objects and interfaces. I agree 
COM is widely adopted on windows only, but it is not
bound, by nature, to the Win32 api, or to the kernel (because it runs under 
9x and NT/2K which have very
different kernels).

COM is a quite nice technology... Perhaps too heavy for audio plug-ins, but 
powerful and multi-purpose.

COM has been developed by Digital.

No comments.

Benjamin


From - Thu Oct  7 01:31:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA20372
	for <slinkp@ulster.net>; Wed, 6 Oct 1999 15:14:39 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA08630 for linux-audio-dev-list; Wed, 6 Oct 1999 14:42:56 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA08627 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 14:42:53 -0400
Received: from localhost.localdomain (d212-151-92-92.swipnet.se [212.151.92.92]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id UAA22762; 
          Wed, 6 Oct 1999 20:37:42 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Guenter Geiger <geiger@epy.co.at>, Paul Barton-Davis <pbd@Op.Net>
Subject: Re: [linux-audio-dev] API design again
Date: Wed, 6 Oct 1999 20:14:40 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
References: <14331.25584.522781.936285@gige>
MIME-Version: 1.0
Message-Id: <99100620442602.00450@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id UAA22762
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id PAA20372
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2abf3a16467e55bb9ebcc6e47ad27004

On Wed, 06 Oct 1999, Guenter Geiger wrote:
> Paul Barton-Davis writes:
>  > However, the benefit of the plugin's own code being *independent* of
>  > the API framework seems enormous. 

Agree. The event system adds complexity to the plug-in code, and it doesn't
make a big performance difference unless the event density is high.

> Exactly, and, this is in line with the concerns Thomas issued about
> porting plugins from other standards.

Just a note: VST 2.0 already has a quite similar event system...

> Well, well see if David can live with this. Best thing to solve this 
> problem would be by implementing and events system with both schemes
> and look at the performance. It doesnt help us much if we spare
> 5 % of processing power by loosing that much of flexibility.

If it was only about the 5% (or whatever) of CPU time, I would have dropped the
buffered event system. But how do you generate and/or process events in a
system where plug-ins don't know about events? I see events as data that can be
processed - not just a simple parameter control interface.

Hiding the event system from plug-ins that don't want to use it directly could
be done (a layer that maps events directly to control variables in the closure
of the "simple mode" plug-in, for example), but the other way around would
require a new extension to be added to the API later on...

IMHO, VST 1.0 wasn't too sexy, and the addition of multiple new APIs to it
made 2.0 an uggly, inefficient mess. (BTW, C++ didn't seem to help much
there... ;-)

Is that the way to do it? I'd suggest we think about the less trivial uses of
the API right from the start, instead of oversimplifying, just to be forced to
wreck the nice and clean API later on, because it lacks essential features.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Thu Oct  7 01:31:58 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA22452
	for <slinkp@ulster.net>; Wed, 6 Oct 1999 15:26:29 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA08686 for linux-audio-dev-list; Wed, 6 Oct 1999 15:00:35 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA08683 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 15:00:33 -0400
Received: from localhost.localdomain (d212-151-92-92.swipnet.se [212.151.92.92]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id UAA11147; 
          Wed, 6 Oct 1999 20:55:21 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Benjamin GOLINVAUX <golinvaux@benjamin.net>,
        Benjamin GOLINVAUX <golinvaux@benjamin.net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Plugin API
Date: Wed, 6 Oct 1999 20:51:43 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <0003563a5deea79d_mailit@relay.eunet.be>
MIME-Version: 1.0
Message-Id: <99100621020403.00450@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id UAA11147
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id PAA22452
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5ae9543bd24eaf09b1210bad44d9591e

On Wed, 06 Oct 1999, Benjamin GOLINVAUX wrote:
> >Yeah... And M$ worked pretty hard on making sure DirectX got as Windoze
> >dependent as possible. As usual...
> 
> Hum Hem Hom Erm Glop
> 
> DirectX is based on COM... it _is_ a crappy interface for audio, but any COM 
> implementation could host a DirectX set of objects and interfaces. I agree 
> COM is widely adopted on windows only, but it is not
> bound, by nature, to the Win32 api, or to the kernel (because it runs under 
> 9x and NT/2K which have very
> different kernels).
> 
> COM is a quite nice technology... Perhaps too heavy for audio plug-ins, but 
> powerful and multi-purpose.

Yes, now that you mention it... But what about all the code inside the actual
implementations of COM objects? DirectX plug-ins with the GUI built right in...
How many DX plug-ins would actually port without porting a few other - Windoze
specific - COM objects as well? I can't say I have very detailed knowledge in
this area, so I'd like to see a comment from someone who does.

BTW, Java is platform independent, right? ;-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Thu Oct  7 01:32:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA13927
	for <slinkp@ulster.net>; Wed, 6 Oct 1999 21:26:04 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA09654 for linux-audio-dev-list; Wed, 6 Oct 1999 21:05:24 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA09651 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 21:05:22 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id UAA03596
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 20:59:43 -0400 (EDT)
Received: from localhost by ux02 (8.9.1b+Sun) id UAA05474; Wed, 6 Oct 1999 20:59:41 -0400 (EDT)
Date: Wed, 6 Oct 1999 20:59:41 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Plugin API
In-Reply-To: <0003563a5deea79d_mailit@relay.eunet.be>
Message-ID: <Pine.GSO.4.10.9910062050390.5407-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e3115275243b38d1ee52e343c1c03f19

On Wed, 6 Oct 1999, Benjamin GOLINVAUX wrote:

> COM has been developed by Digital.

By that logic, so was Windows NT itself, since NT is merely the Windows
interface tacked on top of DEC VMS (honestly... it was engineered by the
same guy).

I'm personally of the opinion that _nothing_ warrants as heavy a solution
as COM or possibly even as heavy as CORBA.  (/me ducks as the firestorm
heads his way from the aRTs and KDE folks)  If you need some sort of RPC,
open a damn socket.  It's not hard to code, it's supported on every
platform in existence today, and is accessible from every programming
language that takes itself seriously.  Geez.

Div.

From - Thu Oct  7 01:32:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA13728
	for <slinkp@ulster.net>; Wed, 6 Oct 1999 21:24:51 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA09636 for linux-audio-dev-list; Wed, 6 Oct 1999 21:05:03 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA09633 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 21:05:00 -0400
Received: from someip.ppp.op.net (d-bm3-16.ppp.op.net [209.152.194.86]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id UAA05202 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 20:59:57 -0400 (EDT)
Message-Id: <199910070059.UAA05202@renoir.op.net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] API design again 
In-reply-to: Your message of "Wed, 06 Oct 1999 20:14:40 +0200."
             <99100620442602.00450@localhost.localdomain> 
Date: Wed, 06 Oct 1999 21:55:38 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: dd92dbfa2b33f4e1fbf2379e727029c9


>If it was only about the 5% (or whatever) of CPU time, I would have
>dropped the buffered event system. But how do you generate and/or
>process events in a system where plug-ins don't know about events? I
>see events as data that can be processed - not just a simple
>parameter control interface.

Its not about keeping the event system hidden from the plugin. Its
about separating the delivery of real-time information about the state
of the world from the request to process some sound.

Clearly, a plugin must still be able to handle state changes. But the
code to do that will, in most cases, simple be resetting variables,
setting flags, etc. This is quite distinct from the task done by
process(). If an event generates or actually contains data to be
processed, then it goes into the plugin via process(). If it merely
tells us about a state change ("MIDI NoteOn", "GUI says value shifted
to 0.92", etc.), then the plugin gets told via (we'll call it ...)
notify().

Think of it another way. Lets suppose I have the code for the Antares
AutoTune TDM plugin. Lets suppose its written without any idea of an
event system, it might even be written without much idea that its a
plugin at all.

If I want to use this code as a plugin for <insert-plugin-API-name-here>, 
then there are two possibilities that I can see:

1) if the API passes an event buffer to process()
   
   - I need to write a wrapper for the code along the lines suggested
     by Roger Larsson.

2) if the API passes events to a separate function, and a frame count
   to process()

   - I can probably use the code as-is, and add an event-handling
     function. 
     
So, in both cases, I'll have to do some real work. Which is better ?

My guess, and its only a guess, is that for the most part, it will be
less work, and less disruptive to the code, to use (2). But I could be
wrong. I see this as a key question, because the idea that the only
code to be used with a plugin API will be new code is crazy - reuse is
part of the whole joy of open source, and
reuse-without-excessive-rewriting is even better.

And if anyone *does* have the Antares AutoTune source code, please
post it ! :))

--p


From - Thu Oct  7 01:32:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA14920
	for <slinkp@ulster.net>; Wed, 6 Oct 1999 21:32:39 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA09680 for linux-audio-dev-list; Wed, 6 Oct 1999 21:11:45 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA09677 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 21:11:43 -0400
Received: from someip.ppp.op.net (d-bm3-16.ppp.op.net [209.152.194.86]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id VAA05853 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 21:06:40 -0400 (EDT)
Message-Id: <199910070106.VAA05853@renoir.op.net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] API design again 
In-reply-to: Your message of "Wed, 06 Oct 1999 19:05:53 BST."
             <37FB8F81.3B821FDC@skelleftea.mail.telia.com> 
Date: Wed, 06 Oct 1999 22:02:21 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3bd7dada3683e8714bc878e2586bfa41

>Yes but the event is supposed to affect the current executing plugin
>only (my interpretation) and can then be coded as:
>  selfHandleEvent(event);	// could be inlined by the compiler,
>// or at least it is a static call, no miss in jump prediction.
>  engineGetNextEvent(this, event); // Have not seen this

I don't think this is correct. If the event is, say, a MIDI continuous
controller value change, then many plugins may need to know about it
(i.e. all plugin's that want to use the CC value for something).

>shouldn't we be able to process more than one event during one
>buffer....
>(or was the event a linked list)

we'd better be able to ... otherwise, its a stupid design. so yes, i
think you can assume that the `event' is some kind of linked list/null
terminated array etc.

>It also does simplify coding for FFT since you get the same size all
>the time, you would probably need less memory to keep state from
>previous.  (Especially if the plugin can specify buffer size)

This is a very valid concern. I was trying to find an example of where
the varying frame count would cause problems - this is a good
one. Anyone else have comments on FFT (or other algorithms) and the
problems that variable frame counts might cause ?

>It should be easy to write a compatibility plugin that calls plugins
>without event handling. The reverse is not true...
>
>// Pseudocode...
>compatibilityPlugin(..., event)
>current = 0;
>for(full range)
>{
>   partSize = nextEvent - current;
>
>   plugin->process(..., current, partSize);
>
>   plugin->processEvent(event);
>   current = nextEvent;
>   engineGetNextEvent(plugin, event) // the last event is not removed
>}

Excellent example. The question remains: should this be the
responsibility of the plugin or the engine ? Do you really want
*every* plugin derived from non-event-based code to contain this kind
of wrapper ? Doesn't it remove most of the benefits of the approach ?

--p

From - Thu Oct  7 01:32:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA16331
	for <slinkp@ulster.net>; Wed, 6 Oct 1999 21:41:40 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA09700 for linux-audio-dev-list; Wed, 6 Oct 1999 21:23:02 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA09697 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 21:23:00 -0400
Received: from someip.ppp.op.net (d-bm3-16.ppp.op.net [209.152.194.86]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id VAA06712 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 6 Oct 1999 21:17:57 -0400 (EDT)
Message-Id: <199910070117.VAA06712@renoir.op.net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Draft: Audiality article for MusicStation 
In-reply-to: Your message of "Wed, 06 Oct 1999 19:58:55 +0300."
             <Pine.LNX.4.10.9910061712040.725-100000@sculpcave.localdomain> 
Date: Wed, 06 Oct 1999 22:13:38 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: a492a6eb6fe40df0b07d72ea574f649f

>If/when I can grasp what David's event system is all about,
>I can start commenting on the design. ;) I guess a concrete 
>use-case example would help. 

I'll try to give my understanding. Consider a two thread system, one
of them is basically doing a tight select(2) loop on an fd
representing a MIDI interface, and the other is the DSP engine thread.

--------------------------------------------------------------------

Thread 1:
=========

while (1) {
      select (N, &fds, ...)
      if (readable (midi_fd)) {
             get_sample_accurate_timestamp ();
	     read_midi_data ();
	     event_list = parse_midi_data ();
	     engine->inject_events ();
      }
}

Thread 2:
=========

while (1) {

      get_new_events ();
      foreach active plugin {
	   build_plugin_event_list ();
	   plugin->process (...., event_list, ...);
      }			   

}

---------------------------------------------------------------------

You can also thread 1 or an additional thread running a GUI, and
sending events about UI-driven changes to the engine.

Key components of the system are:

    get_sample_accurate_timestamp () - this gets the number of the
				       the sample currently believed to
				       be playing on the DSP's
				       output(s).

    engine->inject_events ()         - allows another thread to add
				       events to those waiting to be
				       processed by the DSP engine thread.
				       
    build_plugin_event_list ()       - takes events from the pending
				       event list in the DSP engine thread,
				       and puts them in a data
				       structure that is passed to the 
				       plugin.
 
Notice the need for mutexes within engine->inject_events(), at the
very least.

I hope this helps, if only to clarify my own understanding of David's
proposal. 

Here is the current "competing" idea (quite possibly a serious logic
flaw here, but you'll get the idea):

Thread 2:
=========

while (1) {

      pending_events = get_new_events ();
      foreach active plugin {
           foreach pending_event {
		   compute_frames_till_event ();
		   plugin->process (...., frames );
		   plugin->notify (pending_event);
		   compute_frames_till_next_event ();
		   plugin->process (...., remaining_frames);
      }			   
}

--p
 
				       

From - Thu Oct  7 01:32:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA08083
	for <slinkp@ulster.net>; Thu, 7 Oct 1999 01:03:41 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA09992 for linux-audio-dev-list; Thu, 7 Oct 1999 00:46:19 -0400
Received: from duq3a.cc.duq.edu (duq3a.cc.duq.edu [165.190.9.207]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id AAA09989 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 7 Oct 1999 00:46:16 -0400
Received: from carmick5721.duq.edu ([165.190.208.140]) by duq3a.cc.duq.edu with SMTP;
          Thu, 7 Oct 1999 0:33:49 -0400
Message-Id: <3.0.5.32.19991007003753.017a0840@duq3.cc.duq.edu>
X-Sender: carmick5721@duq3.cc.duq.edu
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 07 Oct 1999 00:37:53 -0400
To: linux-audio-dev@ginette.musique.umontreal.ca
From: "Frank J. Carmickle" <frankiec@unforgettable.com>
Subject: Re: [linux-audio-dev] powerpc/g4 and Alpha
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 8baa686b50478bd3a8a2f8366224e58c

At 02:02 PM 10/5/99 -0700, you wrote:
>Paul Barton-Davis discourseth:
>> >Sometimes I wonder how Linux is running G4 PowerMacs.
>> 
>> You're not the only one :) OTOH, its not clear to what extent there is
>> any plan to offer SMP motherboards or support for the G4. Also, Benno
>> pointed me at the AMD K7 (Athlon) which looks like it should be able
>> to match the G4 *and* will have SMP motherboards available RSN. The
>> price is right, too.

We all know why the Athlan is as good as it is.  It uses the Alpha EV6 bus.
 I would like to see us focus on being completely cross platform for the
reasons that the G4 and the Alpha have a lot to offer the Linux audio
community. 

>
>i'm excited about both!
>
>g4 has the altivec simd unit which has 32 128-bit registers and a
>beautiful instruction set.  3dnow on the athlon, otoh, is virtually
>broken..i haven't heard whether amd has plans to fix this
>
>also, i'd bet money that there will be some interesting powerpc
>hardware alternatives next year..check out www.totalimpact.com, for
>example

One of the things that bothers me is that the RME cards are supported by
OSS on X86 only.  Don't they know that if anything they should have drivers
just for Alpha.  I'm sorry but we are limited by how much processing power
we have by are computers.  Don't they know this and can't they read the
bench marks?  Alpha is and will be the fastest processor on the market for
quite some time.  Cost is very much another issue but Alpha's aren't
usually as expensive as people might think.  

FJC

From - Thu Oct  7 01:32:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA05781
	for <slinkp@ulster.net>; Thu, 7 Oct 1999 00:32:57 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA09942 for linux-audio-dev-list; Thu, 7 Oct 1999 00:08:07 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA09935 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 7 Oct 1999 00:08:04 -0400
Received: from op.net (d-bm2-12.ppp.op.net [209.152.194.50]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id AAA17757 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 7 Oct 1999 00:03:00 -0400 (EDT)
Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id AAA11038; Thu, 7 Oct 1999 00:58:43 -0400
Date: Thu, 7 Oct 1999 00:58:43 -0400
Message-Id: <199910070458.AAA11038@op.net>
From: Paul Barton-Davis <pbd@Op.Net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] a new application underway
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: d82d2406c38cec43f92250f0acd306a4

To see the latest in my line of programs inspired by "hmm, Creamware
make nice GUI's but I can write that myself", take a look at this:

     http://www.op.net/~pbd/hdr/screen.gif

You see only the strip window - there is a parallel window containing
bus controls. These will be merged into a notebook-style arrangement
soon. 

This is a HDR program oriented toward live multi-track recording
(distinct from many Linux programs that seem geared to recoding single
tracks and merging them into a multi-track context). Currently, it
allows multitrack recording to and from ALSA-supported soundcards, and
over the weekend, or before, I will add support for multi-channel
soundfiles as both a recording source and destination. Any number of
tracks and buses are supported, subject only to machine limits. Full
MIDI control of relevant controls is of course supported.

As usual, work is needed on the GUI visuals, but as an example of code
re-use (c/o Quasimodo), its been pretty impressive - what you see took
me 2 days to write, and features the same GUI/engine separation as
Quasimodo. I still have to add support for inserts, but plan to wait
for our API debate to settle since then I'll know what API to use :)

Any resemblance to the Creamware mixer for the Pulsar/SCOPE is
entirely deliberate. 

--p

ps. this program is dedicated to a <company elided> employee reported
to have said "I don't understand these Linux people. Why do they want
to do for free what I do for <company elided> ?" 

pps. i suddenly saw a bright future this evening with
Linux/ALSA. Imagine this beautifully modular system: an automated
mixer like this one that writes Standard MIDI files as its automation
session record, and can connect to the ALSA sequencer for automation
playback. To automate a session, you fire up your preferred ALSA
sequencer-compatible MIDI player, and dump the automation session into
the sequencer. Presto - the mixer is automated. This is something that
my studio friends would truly be impressed by. "Free automation ? Who
are these Linux people ?" No, it probably would not be sample accurate
(though who knows), but wow, would it be cool.


From - Fri Oct  8 00:41:52 1999
Received: from li.org (load103.varesearch.com [209.81.8.103])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id FAA24016
	for <slinkp@ulster.net>; Thu, 7 Oct 1999 05:57:53 -0400
Received: (from majordomo@localhost)
	by li.org (8.9.3/8.9.3) id BAA28384
	for linart-list; Thu, 7 Oct 1999 01:59:38 -0700
X-Authentication-Warning: li.org: majordomo set sender to owner-linart@li.org using -f
Message-ID: <37FC6103.1C5CA53A@ulster.net>
Date: Thu, 07 Oct 1999 04:59:47 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: LINART list <linart@li.org>
CC: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>,
        linux-announce@sws1.ctd.ornl.gov
Subject: Audio-Quality-HOWTO updated
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linart@li.org
Precedence: bulk
Reply-To: linart@li.org
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 55ea0a03716a879331c48256acd406c8

The Audio-Quality-HOWTO has been updated. The new version is 0.0.8.

There are a few new juicy tidbits of soundcard information, some more
info on 60-cycle hum, and a notice about kernel patches for improved
realtime performance.

http://www.ulster.net/~abigoo/pw_linux/Audio-Quality-HOWTO.html
-- 

----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Fri Oct  8 00:41:58 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA31398
	for <slinkp@ulster.net>; Thu, 7 Oct 1999 11:33:40 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA15400 for linux-audio-dev-list; Thu, 7 Oct 1999 11:00:03 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA15397 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 7 Oct 1999 11:00:00 -0400
Received: from someip.ppp.op.net (d-bm3-0b.ppp.op.net [209.152.194.75]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id KAA22317; Thu, 7 Oct 1999 10:54:52 -0400 (EDT)
Message-Id: <199910071454.KAA22317@renoir.op.net>
To: "Frank J. Carmickle" <frankiec@unforgettable.com>
cc: linux-audio-dev@ginette.musique.umontreal.ca, alsa-devel@alsa-project.com
Subject: Re: [linux-audio-dev] powerpc/g4 and Alpha (and RME)
In-reply-to: Your message of "Thu, 07 Oct 1999 00:37:53 EDT."
             <3.0.5.32.19991007003753.017a0840@duq3.cc.duq.edu> 
Date: Thu, 07 Oct 1999 11:50:41 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2870a100f54e5dfa84aecfe578cfca4f

>One of the things that bothers me is that the RME cards are supported by
>OSS on X86 only.  Don't they know that if anything they should have drivers
>just for Alpha.  

Forget about OSS. Winfried thinks he will have his ALSA drivers for
the RME Hammerfall ready very soon, and they will be available in
source form.  You'll get OSS compatibility for free, because ALSA does
that itself. Right, Winfried ?

Meanwhile, it is likely/hopeful/possible that some people from IRCAM
will write ALSA drivers for the rest of the RME cards, at least in the
form that SEK'D repackages them in (which I don't think involves
hardware manipulations).

--p

From - Fri Oct  8 00:42:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA10337
	for <slinkp@ulster.net>; Thu, 7 Oct 1999 12:49:41 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA15591 for linux-audio-dev-list; Thu, 7 Oct 1999 12:08:21 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA15580 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 7 Oct 1999 12:06:14 -0400
Received: from op.net (d-bm3-0b.ppp.op.net [209.152.194.75]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id MAA29289 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 7 Oct 1999 12:01:01 -0400 (EDT)
Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id MAA17849; Thu, 7 Oct 1999 12:56:50 -0400
Date: Thu, 7 Oct 1999 12:56:50 -0400
Message-Id: <199910071656.MAA17849@op.net>
From: Paul Barton-Davis <pbd@Op.Net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] multi-track audio files - what format ?
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 2064aaada2e2615890f673fccf3738ef

OK, so to my disappointment, Michael Pruett's libaudiofile, just like
its SGI counterpart, doesn't support multi-track files. Does anyone
have any advice on file formats that support non-interleaved,
multi-track sound ?

I was going to start hacking up my own C++-ified version of Bill
Schottstaedt's snd library to support multiple tracks as multiple
(interleaved) channels, but the interleaving is clearly a performance
problem. Surely one of the existing major formats allows multiple
tracks ? The comments in SGI's documentation say otherwise ...

--p

From - Fri Oct  8 00:42:06 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA20843
	for <slinkp@ulster.net>; Thu, 7 Oct 1999 17:12:33 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA01444 for linux-audio-dev-list; Thu, 7 Oct 1999 14:58:20 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA01441 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 7 Oct 1999 14:58:17 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id OAA25926
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 7 Oct 1999 14:52:10 -0400 (EDT)
Received: from localhost by ux02 (8.9.1b+Sun) id OAA11857; Thu, 7 Oct 1999 14:52:08 -0400 (EDT)
Date: Thu, 7 Oct 1999 14:52:08 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway
In-Reply-To: <199910070458.AAA11038@op.net>
Message-ID: <Pine.GSO.4.10.9910071449330.11750-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: fe15ff2edada9a62d80d4ec31f92a6e5

On Thu, 7 Oct 1999, Paul Barton-Davis wrote:

> pps. i suddenly saw a bright future this evening with
> Linux/ALSA. Imagine this beautifully modular system: an automated
> mixer like this one that writes Standard MIDI files as its automation
> session record, and can connect to the ALSA sequencer for automation
> playback. To automate a session, you fire up your preferred ALSA
> sequencer-compatible MIDI player, and dump the automation session into
> the sequencer. Presto - the mixer is automated. This is something that
> my studio friends would truly be impressed by. "Free automation ? Who
> are these Linux people ?" No, it probably would not be sample accurate
> (though who knows), but wow, would it be cool.

Yes, now you understand the second reason (other than just for composing)
that MIDI sequencers are my main area of focus.  Think millisecond
accurate cron for automating just about anything!

Div.

From - Fri Oct  8 00:42:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA21811
	for <slinkp@ulster.net>; Thu, 7 Oct 1999 17:18:52 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA01457 for linux-audio-dev-list; Thu, 7 Oct 1999 15:02:25 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA01454 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 7 Oct 1999 15:02:22 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id OAA26343
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 7 Oct 1999 14:56:29 -0400 (EDT)
Received: from localhost by ux02 (8.9.1b+Sun) id OAA11903; Thu, 7 Oct 1999 14:56:27 -0400 (EDT)
Date: Thu, 7 Oct 1999 14:56:27 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] multi-track audio files - what format ?
In-Reply-To: <199910071656.MAA17849@op.net>
Message-ID: <Pine.GSO.4.10.9910071453250.11750-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 811db65a93bd112fa136d89dd6602e43

On Thu, 7 Oct 1999, Paul Barton-Davis wrote:

> OK, so to my disappointment, Michael Pruett's libaudiofile, just like
> its SGI counterpart, doesn't support multi-track files. Does anyone
> have any advice on file formats that support non-interleaved,
> multi-track sound ?

Non-interleaved?  Why not just use multiple conventional files (mono or
stereo) which get read or written in parallel?  

But why wouldn non-interleaved be better performance?  Wouldn't you have
to bounce around the disk more?

Can an entire email be written entirely in questions?
Div?

From - Fri Oct  8 00:42:11 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA28454
	for <slinkp@ulster.net>; Thu, 7 Oct 1999 18:02:03 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA01701 for linux-audio-dev-list; Thu, 7 Oct 1999 17:24:13 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA01698 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 7 Oct 1999 17:24:10 -0400
Received: from localhost.localdomain (d212-151-43-147.swipnet.se [212.151.43.147]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id XAA02943; 
          Thu, 7 Oct 1999 23:19:40 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] API design again
Date: Thu, 7 Oct 1999 22:38:29 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199910070059.UAA05202@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99100723262600.00471@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id XAA02943
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA28454
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: a08fb640cd6a444ac171a530169d7e8e

On Thu, 07 Oct 1999, Paul Barton-Davis wrote:
> >If it was only about the 5% (or whatever) of CPU time, I would have
> >dropped the buffered event system. But how do you generate and/or
> >process events in a system where plug-ins don't know about events? I
> >see events as data that can be processed - not just a simple
> >parameter control interface.
> 
> Its not about keeping the event system hidden from the plugin. Its
> about separating the delivery of real-time information about the state
> of the world from the request to process some sound.

Ok. Good point.

However, there is another point in keeping the event processing in the process()
function, apart from eliminating two extra function calls per state change: The
plug-in gets to decide the actual event timing precision. That is, if there is a
significant performance advantage in quantizing to a certain number of samples
(SIMD code, FFTs...) and full sample accuracy doesn't make much sense, the
plug-in code can be optimized that way.

That could be done by telling the engine about buffer size granularity or
something, but that adds code to the main path of the engine. Too many features
of that kind will make it very hard to hack efficient implementations...

Plug-in code would hardly add any overhead at all, as any quantizing would be
hardcoded.

Another advantage of using *fixed buffer sizes* and inline event handling in
the process() function, is that the entire "dynamic" buffer size management
logic moves out of the main engine code path.

Of course, this is only about performance. How much CPU is a simpler process()
function allowed to cost? :-)

> Clearly, a plugin must still be able to handle state changes. But the
> code to do that will, in most cases, simple be resetting variables,
> setting flags, etc. This is quite distinct from the task done by
> process(). If an event generates or actually contains data to be
> processed, then it goes into the plugin via process(). If it merely
> tells us about a state change ("MIDI NoteOn", "GUI says value shifted
> to 0.92", etc.), then the plugin gets told via (we'll call it ...)
> notify().

...but how would that be done if events are to be processed by another
callback? It's all or nothing here; no point in moving *some* events out of
process().

However, supporting two "levels" of plug-ins may be an alternative...

> Think of it another way. Lets suppose I have the code for the Antares
> AutoTune TDM plugin. Lets suppose its written without any idea of an
> event system, it might even be written without much idea that its a
> plugin at all.
> 
> If I want to use this code as a plugin for <insert-plugin-API-name-here>, 
> then there are two possibilities that I can see:
> 
> 1) if the API passes an event buffer to process()
>    
>    - I need to write a wrapper for the code along the lines suggested
>      by Roger Larsson.
> 
> 2) if the API passes events to a separate function, and a frame count
>    to process()
> 
>    - I can probably use the code as-is, and add an event-handling
>      function. 
>      
> So, in both cases, I'll have to do some real work. Which is better ?

Three possibilities:

3) if the API passes an event buffer to process()

   - You can use the code as-is (turn it into an inline if you like)
     and use it from your new "event handling" function, which is
     actually the new process() function.

> My guess, and its only a guess, is that for the most part, it will be
> less work, and less disruptive to the code, to use (2). But I could be
> wrong.

Not sure either, but I think it's more a matter of coding style than how well
the API fits code from other environments. A nice wrapper template (no, not a
C++ template! :-) should cover the "quick'n'dirty" porting. If you want the
best of performance and features of the new API, you need to do some extra
work on the details anyway.

> I see this as a key question, because the idea that the only
> code to be used with a plugin API will be new code is crazy - reuse is
> part of the whole joy of open source, and
> reuse-without-excessive-rewriting is even better.

It's important, but the issues you mentioned are probably more important if you
*don't* have the source code. Binary level wrappers can be hard to get efficient
no matter how similar the APIs are. While adding an "inline" here and there
directly eliminates the extra function call overhead, and then you can have a
look at the data type declarations, and the function prototypes... And *then*
you could start to look at the actual "old_process()" code, if you think
there are more cycles to gain.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Oct  8 00:42:10 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA24656
	for <slinkp@ulster.net>; Thu, 7 Oct 1999 17:37:48 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA01621 for linux-audio-dev-list; Thu, 7 Oct 1999 16:57:03 -0400
Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA01618 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 7 Oct 1999 16:56:59 -0400
Received: from hendrix (kyle17.zip.com.au [61.8.17.145])
	by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id GAA32539;
	Fri, 8 Oct 1999 06:36:15 +1000 (EST)
Message-ID: <37FD0800.79857C42@zip.com.au>
Date: Fri, 08 Oct 1999 06:52:16 +1000
From: Erik de Castro Lopo <erikd@zip.com.au>
Organization: Indonesian murders out of East Timor NOW!
X-Mailer: Mozilla 3.04Gold (X11; I; Linux 2.2.12 i586)
MIME-Version: 1.0
To: Paul Barton-Davis <pbd@Op.Net>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] multi-track audio files - what format ?
References: <199910071656.MAA17849@op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2df10b3e0ef3923f7e5b1e2d927b7bc6

Paul Barton-Davis wrote:
> 
> OK, so to my disappointment, Michael Pruett's libaudiofile, just like
> its SGI counterpart, doesn't support multi-track files. Does anyone
> have any advice on file formats that support non-interleaved,
> multi-track sound ?

This is one of my own longer term goals for libsndfile:

    http://www.zip.com.au/~erikd/libsndfile

> I was going to start hacking up my own C++-ified version of Bill
> Schottstaedt's snd library to support multiple tracks as multiple
> (interleaved) channels, but the interleaving is clearly a performance
> problem. Surely one of the existing major formats allows multiple
> tracks ? The comments in SGI's documentation say otherwise ...

Not to my knowledge.

If you can live with a C callable library, maybe we can work on a spec
for a multitrack file which can at some later date be integrated into
libsndfile.

Erik
-- 
+-------------------------------------------------+
     Erik de Castro Lopo     erikd@zip.com.au
+-------------------------------------------------+
"We reject kings, presidents, and voting. We believe in rough 
consensus and running code."  -- Dave Clark (IETF 1992)

From - Fri Oct  8 00:42:15 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA00416
	for <slinkp@ulster.net>; Thu, 7 Oct 1999 18:32:51 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA01758 for linux-audio-dev-list; Thu, 7 Oct 1999 17:58:24 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA01755 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 7 Oct 1999 17:58:21 -0400
Received: from localhost.localdomain (d212-151-43-147.swipnet.se [212.151.43.147]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id XAA20343; 
          Thu, 7 Oct 1999 23:53:51 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] API design again
Date: Thu, 7 Oct 1999 23:36:15 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199910070106.VAA05853@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99100800003701.00471@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id XAA20343
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA00416
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 30e3a54a525213feb243b7da671f4665

On Thu, 07 Oct 1999, Paul Barton-Davis wrote:
> >It also does simplify coding for FFT since you get the same size all
> >the time, you would probably need less memory to keep state from
> >previous.  (Especially if the plugin can specify buffer size)
> 
> This is a very valid concern. I was trying to find an example of where
> the varying frame count would cause problems - this is a good
> one. Anyone else have comments on FFT (or other algorithms) and the
> problems that variable frame counts might cause ?

Here's one: How to keep track of the buffers used to connect the plug-ins?
Could be done using circular buffers and either coping some data to get full
buffers at the wraps, or... breaking buffers that are split into two calls.

The next issue is related to the one above: How to control the plug-in
execution order? Either an fixed "official" buffer size is needed (which means
*required* buffer splits at a fixed interval; any event that happens to not
hit a fixed split will result in an extra split) - or full *dynamic* dependency
resolution for the entire processing net. (I tried to design such a beast - and
gave up. Maybe I missed something, but I think it's too expensive, no matter how
it's realized.)

> >It should be easy to write a compatibility plugin that calls plugins
> >without event handling. The reverse is not true...
> >
> >// Pseudocode...
> >compatibilityPlugin(..., event)
> >current = 0;
> >for(full range)
> >{
> >   partSize = nextEvent - current;
> >
> >   plugin->process(..., current, partSize);
> >
> >   plugin->processEvent(event);
> >   current = nextEvent;
> >   engineGetNextEvent(plugin, event) // the last event is not removed
> >}
> 
> Excellent example. The question remains: should this be the
> responsibility of the plugin or the engine ? Do you really want
> *every* plugin derived from non-event-based code to contain this kind
> of wrapper ? Doesn't it remove most of the benefits of the approach ?

No. Inline plugin.processEvent(), and you're pretty close to the performance of
a "real" plug-in. Then you can start to move things around if you like...

True, porting back to the old API, or using the same code base may not be as
nice as it could be... But OTOH, this problem will show up in *some* cases, no
matter which model we chose.

And finally; are we designing a Universal Plug-in Compatibility Layer, or a
real, flexible, efficient and powerful plug-in API? Let's not build in legacy
stuff right from the start... (Ok, it might turn out that dropping the events
out of the process() call isn't just a backwards compatibility hack, but I
still see more problems with that, than with the "all into process()" model in
the bigger perspective.)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Oct  8 00:42:21 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA04717
	for <slinkp@ulster.net>; Thu, 7 Oct 1999 19:04:08 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA01821 for linux-audio-dev-list; Thu, 7 Oct 1999 18:27:09 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA01818 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 7 Oct 1999 18:27:07 -0400
Received: from localhost.localdomain (d212-151-43-147.swipnet.se [212.151.43.147]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA14651; 
          Fri, 8 Oct 1999 00:22:31 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway
Date: Fri, 8 Oct 1999 00:06:45 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199910070458.AAA11038@op.net>
MIME-Version: 1.0
Message-Id: <99100800291702.00471@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id AAA14651
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA04717
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0f7c408602038d9eaf05575eea6bc83b

On Thu, 07 Oct 1999, Paul Barton-Davis wrote:
> To see the latest in my line of programs inspired by "hmm, Creamware
> make nice GUI's but I can write that myself", take a look at this:
> 
>      http://www.op.net/~pbd/hdr/screen.gif

Looks cool. :-)

> ps. this program is dedicated to a <company elided> employee reported
> to have said "I don't understand these Linux people. Why do they want
> to do for free what I do for <company elided> ?" 

Well, here's a simple argument that explains why I prefer hacking "in the
open":

If a few hackers work on the same GPLed project, each one of them will only have
to do part of the work, while the project will benefit from their combined
skills, and they all get a program with full source code.

It's a bit strange that so many people have serious trouble getting their
heads around this simple logic...

> pps. i suddenly saw a bright future this evening with
> Linux/ALSA. Imagine this beautifully modular system: an automated
> mixer like this one that writes Standard MIDI files as its automation
> session record, and can connect to the ALSA sequencer for automation
> playback. To automate a session, you fire up your preferred ALSA
> sequencer-compatible MIDI player, and dump the automation session into
> the sequencer. Presto - the mixer is automated. This is something that
> my studio friends would truly be impressed by. "Free automation ? Who
> are these Linux people ?" No, it probably would not be sample accurate
> (though who knows), but wow, would it be cool.

The same can be done with an engine using a plug-in API with my event system. A
sequencer could be either a plug-in or a client application, and it could
record anything that goes on in the system. (That's the routing functionality
that's one of all things I worry about when trying to design an efficient event
system...) No need for a special automated mixer (although one would be very
nice as a GUI) and *anything* could be automated. And it would be sample
accurate...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Oct  8 00:42:29 1999
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id TAA10166
	for <slinkp@ulster.net>; Thu, 7 Oct 1999 19:44:43 -0400
Received: from localhost.localdomain (d212-151-43-147.swipnet.se [212.151.43.147]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA04490; 
          Fri, 8 Oct 1999 01:43:11 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Winkler <slinkp@ulster.net>, LINART list <linart@li.org>
Subject: Re: [linux-audio-dev] Audio-Quality-HOWTO updated
Date: Fri, 8 Oct 1999 01:07:04 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>,
        linux-announce@sws1.ctd.ornl.gov
References: <37FC6103.1C5CA53A@ulster.net>
MIME-Version: 1.0
Message-Id: <99100801495704.00471@localhost.localdomain>
Content-Transfer-Encoding: 8bit
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 43abe27cce879739369a5a1874c7df42

On Thu, 07 Oct 1999, Paul Winkler wrote:
> The Audio-Quality-HOWTO has been updated. The new version is 0.0.8.
> 
> There are a few new juicy tidbits of soundcard information, some more
> info on 60-cycle hum, and a notice about kernel patches for improved
> realtime performance.
> 
> http://www.ulster.net/~abigoo/pw_linux/Audio-Quality-HOWTO.html

:-)

Just two notes on RTLinux and POSIX:

1) The new API is based on the "Minimal Realtime System Profile",
   which means it has the open/read/write/... calls, but just basic
   device I/O rather than full file system support. That's not
   "completely different from posix", as stated by Eric S. Teidemann.
   (See example below from my DPI package. Note that the kernel
   module specific stuff could be replaced with some nice stdio style
   wrapper if desired.)

2) The Driver Programming Interface I'm working on (not very much
   time for that lately...) is using the same API as the standard
   RTLinux distro. It affects only drivers - not applications. The
   POSIX I/O layer is already there. (BTW, I was too slow to hack one
   before the NMT guys did... ;-)


Some RTLinux "application" code:
(Beta, of course, and not very well tested... It runs rock solid with
'buffer=32 prewrite=4 fragshift=5' here. :-)

---8<------------------------------------------------------------
#include <linux/module.h>
#include <linux/kernel.h>
#include <rtl_fifo.h>
#include <rtl_time.h>
#include <rtl_sched.h>
#include <asm/io.h>
#include <linux/cons.h>
#include "dpi_posixio.h"

#include <linux/soundcard.h>

#define MAX_BUFFER	16384

int buffer = 1024;
int prewrite = 0;
int fragshift = 8;
int test = 0;
MODULE_PARM(buffer,"i");
MODULE_PARM(prewrite,"i");
MODULE_PARM(fragshift,"i");
MODULE_PARM(test,"i");


char *buf;

pthread_t thread;

int fd;

int monitor(void)
{
	while(1)
	{
		if(read(fd, buf, buffer)<=0)
			return -1;
		if(prewrite)
		{
			/* Note: This will drop the first input buffer */
			memset(buf, 0, prewrite);
			write(fd, buf, prewrite);
			prewrite = 0;
		}
		if(write(fd, buf, buffer)<=0)
			return -1;
	}
}

int siren(void)
{
	static int a = 0;
	static int f_lo = 300<<8;
	static int f;
	static int f_hi = 500<<8;
	static int d = 1;
	int j;
	int samples;
	short *dest = (short *)buf;

	samples = buffer * sizeof(char) / sizeof(dest[0]);
	f = (f_lo + f_hi) / 2;

	while(1)
	{
		for(j = 0; j<samples; j+=2)
		{
			dest[j] = a&0x7fff;
			dest[j+1] = -a&0x7fff;
			a+=f>>8;
			f+=d;
			if(f>f_hi || f<f_lo)
				d=-d;
		}
		if(write(fd, buf, buffer)<=0)
			return -1;
	}
}


void *thread_code(void *t)
{
	int val,r;

	/*
	 * This is very dangerous with the es1370 driver.
	 * Wrong settings and you get a kernel panic...
	 * (Can this really happen if done from user space?)
	 */
	val = 0x7fff000 | (fragshift & 0xffff);
	r = ioctl(fd,SNDCTL_DSP_SETFRAGMENT,&val);
	if(r<0) goto fail;

	r = ioctl(fd,SNDCTL_DSP_RESET,NULL);
	if(r<0) goto fail;
	val = 16;
	r = ioctl(fd,SNDCTL_DSP_SAMPLESIZE,&val);
	if(r<0) goto fail;
	val = AFMT_S16_LE;
	r = ioctl(fd,SNDCTL_DSP_SETFMT,&val);
	if(r<0) goto fail;
	val = 1;
	r = ioctl(fd,SNDCTL_DSP_STEREO,&val);
	if(r<0) goto fail;
	val = 44100;
	r = ioctl(fd,SNDCTL_DSP_SPEED,&val);
	if(r<0) goto fail;
	r = ioctl(fd,SNDCTL_DSP_SETDUPLEX,NULL);
	if(r<0)
	{
	fail:	rtl_printf("Failed to initialize sound device!\n");
		return (void *)-1;
	}

	switch(test)
	{
	case 0:		return (void *)monitor();
	default:	return (void *)siren();
	}
}


int init_module(void)
{
	buffer &= 0xfffffffc;
	if(buffer>MAX_BUFFER)
	{
		buffer=MAX_BUFFER;
		printk("Buffer can't be bigger than %d bytes.\n", MAX_BUFFER);
		return -1;
	}

	prewrite &= 0xfffffffc;
	if(prewrite>MAX_BUFFER)
	{
		prewrite=MAX_BUFFER;
		printk("Can't prewrite more than %d bytes.\n", MAX_BUFFER);
		return -1;
	}

	if( !(buf = kmalloc(buffer,GFP_KERNEL)) )
	{
		printk("Couldn't allocate buffer!\n");
		return -1;
	}

	if((fd = open("/dev/dsp0", O_RDWR)) < 0 )
	{
		printk("Couldn't open device! (%d)\n",fd);
		kfree(buf);
		return -1;
	}

	if( pthread_create(&thread,  NULL, thread_code, (void *)1) )
	{
		printk("Failed to create RT thread!\n");
		close(fd);
		kfree(buf);
		return -1;
	}

	return 0;
}


void cleanup_module(void)
{
	pthread_delete_np (thread);
	close(fd);
	kfree(buf);
}
---8<------------------------------------------------------------


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Oct  8 00:42:52 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA15413
	for <slinkp@ulster.net>; Thu, 7 Oct 1999 20:21:30 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA02034 for linux-audio-dev-list; Thu, 7 Oct 1999 19:47:51 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA02031 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 7 Oct 1999 19:47:48 -0400
Received: from localhost.localdomain (d212-151-43-147.swipnet.se [212.151.43.147]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA04490; 
          Fri, 8 Oct 1999 01:43:11 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Winkler <slinkp@ulster.net>, LINART list <linart@li.org>
Subject: Re: [linux-audio-dev] Audio-Quality-HOWTO updated
Date: Fri, 8 Oct 1999 01:07:04 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>,
        linux-announce@sws1.ctd.ornl.gov
References: <37FC6103.1C5CA53A@ulster.net>
MIME-Version: 1.0
Message-Id: <99100801495704.00471@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id BAA04490
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA15413
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: cc0f6fa3af5c1c3b12598f9b9480e3f6

On Thu, 07 Oct 1999, Paul Winkler wrote:
> The Audio-Quality-HOWTO has been updated. The new version is 0.0.8.
> 
> There are a few new juicy tidbits of soundcard information, some more
> info on 60-cycle hum, and a notice about kernel patches for improved
> realtime performance.
> 
> http://www.ulster.net/~abigoo/pw_linux/Audio-Quality-HOWTO.html

:-)

Just two notes on RTLinux and POSIX:

1) The new API is based on the "Minimal Realtime System Profile",
   which means it has the open/read/write/... calls, but just basic
   device I/O rather than full file system support. That's not
   "completely different from posix", as stated by Eric S. Teidemann.
   (See example below from my DPI package. Note that the kernel
   module specific stuff could be replaced with some nice stdio style
   wrapper if desired.)

2) The Driver Programming Interface I'm working on (not very much
   time for that lately...) is using the same API as the standard
   RTLinux distro. It affects only drivers - not applications. The
   POSIX I/O layer is already there. (BTW, I was too slow to hack one
   before the NMT guys did... ;-)


Some RTLinux "application" code:
(Beta, of course, and not very well tested... It runs rock solid with
'buffer=32 prewrite=4 fragshift=5' here. :-)

---8<------------------------------------------------------------
#include <linux/module.h>
#include <linux/kernel.h>
#include <rtl_fifo.h>
#include <rtl_time.h>
#include <rtl_sched.h>
#include <asm/io.h>
#include <linux/cons.h>
#include "dpi_posixio.h"

#include <linux/soundcard.h>

#define MAX_BUFFER	16384

int buffer = 1024;
int prewrite = 0;
int fragshift = 8;
int test = 0;
MODULE_PARM(buffer,"i");
MODULE_PARM(prewrite,"i");
MODULE_PARM(fragshift,"i");
MODULE_PARM(test,"i");


char *buf;

pthread_t thread;

int fd;

int monitor(void)
{
	while(1)
	{
		if(read(fd, buf, buffer)<=0)
			return -1;
		if(prewrite)
		{
			/* Note: This will drop the first input buffer */
			memset(buf, 0, prewrite);
			write(fd, buf, prewrite);
			prewrite = 0;
		}
		if(write(fd, buf, buffer)<=0)
			return -1;
	}
}

int siren(void)
{
	static int a = 0;
	static int f_lo = 300<<8;
	static int f;
	static int f_hi = 500<<8;
	static int d = 1;
	int j;
	int samples;
	short *dest = (short *)buf;

	samples = buffer * sizeof(char) / sizeof(dest[0]);
	f = (f_lo + f_hi) / 2;

	while(1)
	{
		for(j = 0; j<samples; j+=2)
		{
			dest[j] = a&0x7fff;
			dest[j+1] = -a&0x7fff;
			a+=f>>8;
			f+=d;
			if(f>f_hi || f<f_lo)
				d=-d;
		}
		if(write(fd, buf, buffer)<=0)
			return -1;
	}
}


void *thread_code(void *t)
{
	int val,r;

	/*
	 * This is very dangerous with the es1370 driver.
	 * Wrong settings and you get a kernel panic...
	 * (Can this really happen if done from user space?)
	 */
	val = 0x7fff000 | (fragshift & 0xffff);
	r = ioctl(fd,SNDCTL_DSP_SETFRAGMENT,&val);
	if(r<0) goto fail;

	r = ioctl(fd,SNDCTL_DSP_RESET,NULL);
	if(r<0) goto fail;
	val = 16;
	r = ioctl(fd,SNDCTL_DSP_SAMPLESIZE,&val);
	if(r<0) goto fail;
	val = AFMT_S16_LE;
	r = ioctl(fd,SNDCTL_DSP_SETFMT,&val);
	if(r<0) goto fail;
	val = 1;
	r = ioctl(fd,SNDCTL_DSP_STEREO,&val);
	if(r<0) goto fail;
	val = 44100;
	r = ioctl(fd,SNDCTL_DSP_SPEED,&val);
	if(r<0) goto fail;
	r = ioctl(fd,SNDCTL_DSP_SETDUPLEX,NULL);
	if(r<0)
	{
	fail:	rtl_printf("Failed to initialize sound device!\n");
		return (void *)-1;
	}

	switch(test)
	{
	case 0:		return (void *)monitor();
	default:	return (void *)siren();
	}
}


int init_module(void)
{
	buffer &= 0xfffffffc;
	if(buffer>MAX_BUFFER)
	{
		buffer=MAX_BUFFER;
		printk("Buffer can't be bigger than %d bytes.\n", MAX_BUFFER);
		return -1;
	}

	prewrite &= 0xfffffffc;
	if(prewrite>MAX_BUFFER)
	{
		prewrite=MAX_BUFFER;
		printk("Can't prewrite more than %d bytes.\n", MAX_BUFFER);
		return -1;
	}

	if( !(buf = kmalloc(buffer,GFP_KERNEL)) )
	{
		printk("Couldn't allocate buffer!\n");
		return -1;
	}

	if((fd = open("/dev/dsp0", O_RDWR)) < 0 )
	{
		printk("Couldn't open device! (%d)\n",fd);
		kfree(buf);
		return -1;
	}

	if( pthread_create(&thread,  NULL, thread_code, (void *)1) )
	{
		printk("Failed to create RT thread!\n");
		close(fd);
		kfree(buf);
		return -1;
	}

	return 0;
}


void cleanup_module(void)
{
	pthread_delete_np (thread);
	close(fd);
	kfree(buf);
}
---8<------------------------------------------------------------


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Oct  8 00:42:27 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA09486
	for <slinkp@ulster.net>; Thu, 7 Oct 1999 19:40:04 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA01883 for linux-audio-dev-list; Thu, 7 Oct 1999 18:55:58 -0400
Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA01880 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 7 Oct 1999 18:55:54 -0400
Received: from d1o43.telia.com (root@d1o43.telia.com [194.22.195.241])
	by maile.telia.com (8.9.3/8.9.3) with ESMTP id AAA26197
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 00:51:27 +0200 (CEST)
Received: from skelleftea.mail.telia.com (t6o43p51.telia.com [194.237.168.111])
	by d1o43.telia.com (8.8.8/8.8.5) with ESMTP id AAA13664
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 00:51:24 +0200 (CEST)
Message-ID: <37FD2E51.F9E770B3@skelleftea.mail.telia.com>
Date: Fri, 08 Oct 1999 00:35:45 +0100
From: Roger Larsson <roger.larsson@skelleftea.mail.telia.com>
X-Mailer: Mozilla 4.6 [en] (Win95; I)
X-Accept-Language: sv,en
MIME-Version: 1.0
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] API design again [code]
References: <199910070106.VAA05853@renoir.op.net>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by maile.telia.com id AAA26197
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA09486
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 458413955c18110b72f3507d773645c8



Paul Barton-Davis wrote:
> 
> >Yes but the event is supposed to affect the current executing plugin
> >only (my interpretation) and can then be coded as:
> >  selfHandleEvent(event);      // could be inlined by the compiler,
> >// or at least it is a static call, no miss in jump prediction.
> >  engineGetNextEvent(this, event); // Have not seen this
> 
> I don't think this is correct. If the event is, say, a MIDI continuous
> controller value change, then many plugins may need to know about it
> (i.e. all plugin's that want to use the CC value for something).

Yes, but all operators could get it in their code.
Note: the engineGetNextEvent does not free the data structure nor the
plugin itself. Allocating an freeing should be the responsibility of
the main engine.

> 
> >shouldn't we be able to process more than one event during one
> >buffer....
> >(or was the event a linked list)
> 
> we'd better be able to ... otherwise, its a stupid design. so yes, i
> think you can assume that the `event' is some kind of linked list/null
> terminated array etc.
>

Not using a linked list is probably a little more flexible. 
* The engine could then 'insert' events into the queue - probably not a
good
  idea, but anyway...
* Events that are to be hadled in multiple plugins needs to be copied in
a
  simple linked list model.

> >It also does simplify coding for FFT since you get the same size all
> >the time, you would probably need less memory to keep state from
> >previous.  (Especially if the plugin can specify buffer size)
> 
> This is a very valid concern. I was trying to find an example of where
> the varying frame count would cause problems - this is a good
> one. Anyone else have comments on FFT (or other algorithms) and the
> problems that variable frame counts might cause ?
> 
> >It should be easy to write a compatibility plugin that calls plugins
> >without event handling. The reverse is not true...
> >

> > [previous version removed]
>  
> Excellent example. The question remains: should this be the
> responsibility of the plugin or the engine ? Do you really want
> *every* plugin derived from non-event-based code to contain this kind
> of wrapper ? Doesn't it remove most of the benefits of the approach ?
>


If the engine in your model can handle the sending of events to ALL
non-event-based code. Then this compatibility plugin is equaly well
suited
to do the same for ALL non-event-based code :-)
[Ohh, that code was missing in my first suggestion, this is needed to be
to be able to use more than one instance of any plugin...]

But you would probably only need one compatibility plugin for each
type of non-event-based code.

// Pseudocode... rev. 2
// longer variable names => longer lines...

--- in API .h file ---
struct NewEngineInstanceData; // forward decl. of plugin instance data
struct NewEngineEventDescription {
 unsigned ... atSample;
 - - -
}
inline signed ... sampleDiff(unsigned ... a, unsigned ... b)
{
   return (signed ...)(a - b);
}

// and decalare <NewEngineProcessFuntionType> too
void engineGetNextEvent(NewEngineEventDescription **eventDesc);

--- in wrappers .c (or local .h) file ---
struct InstanceData {
 <PluginType>ProcessFunction *process;
 <PluginType>EventFunction *processEvent;
}

-- in <PluginType>Wrapper.c ---
static inline void processEvent(InstanceData *this, NewEngineEventData
*event) // but may need time...
(
  // translate needed data from event (and this)

  this->processEvent(<translated data>);
}

<NewEngineProcessFunctionType>
<PluginType>CompatibilityPlugin(InstanceData *this, ...,
NewEngineEventDescription *eventDesc) {
   unsigned ... fullFrame = this->fullFrame;
   unsigned ... startAtSample = this->lastSample;
   unsigned ... endAtSample = startAtSample + fullFrame;

   // following match the type this->process(...) wants
   unsigned ... currentSample = 0; // or signed, "small" value
   signed   ... remainingSamples;

   while ( (remainingSamples = fullFrame - currentSample) > 0) { //
note: assignment
      // strongly taken [fullRange >  2]

      signed ... samplesAfterEvent = -1; // no events before endAtSample
      if (eventDesc != NULL) samplesAfterEvent = sampleDiff(endAtSample,
eventDesc->atSample); // strongly not taken

      ASSERT(samplesAfterEvent <= remainingSamples);

      if (samplesAfterEvent < 0) { // strongly taken [with few events]
         // no more events within frame
         this->process(this->data, ..., currentSample,
remainingSamples);
         currentSample += remainingSamples;

         ASSERT(currentSample == fullFrame);
      } else {
         signed ... processSamples = remainingSamples -
samplesAfterEvent;

         if (processSamples > 0) {

            this->process(this->data, ..., currentSample,
processSamples);
            currentSample += processSamples;

         }
            
         processEvent(this, eventDesc);
         engineGetNextEvent(this, &eventDesc) // the last event is not
processed
      }
         
   }

   ASSERT(remainingSamples == 0);

   this->lastSample = endAtSample;

}


--- in wrappers .c (or local .h) file ---

struct InstanceData {
   ... param;
}

-- in <PluginType>.c ---
static inline void processEvent(InstanceData *this, NewEngineEventData
*event)
(
  this->param[event->attrib] = event->value; // todo: naive...
}

<NewEngineProcessFunctionType>
<PluginType>Plugin(InstanceData *this, ..., NewEngineEventDescription
*eventDesc) {
   unsigned remainingSamples = this->fullFrame;

   while (remainingSamples) {

      signed ... samplesAfterEvent = -1; // no events before endAtSample
      if (eventDesc != NULL) samplesAfterEvent = sampleDiff(endAtSample,
eventDesc->atSample); // strongly not taken

      ASSERT(samplesAfterEvent <= remainingSamples);

      while (remainingSamples > samplesAfterEvent) {
        // process sample here, inline
        remainingSamples--; // note: can't be in while since there might
be several events at the same time
      }

      if (remainingSamples > 0) {
         processEvent(this, eventDesc->data);
         engineGetNextEvent(this, &eventDesc);
      }
   }


Starts to look like real code... 
I guess I have to take another look at Davids API and try to merge...
[where is it]

/RogerL

-- 

The Internet interprets Windows as damage, 
             and routes around it.

Roger Larsson
Skellefte
Sweden

From - Fri Oct  8 00:42:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA07358
	for <slinkp@ulster.net>; Thu, 7 Oct 1999 19:25:38 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA01867 for linux-audio-dev-list; Thu, 7 Oct 1999 18:49:11 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA01864 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 7 Oct 1999 18:49:08 -0400
Received: from someip.ppp.op.net (d-bm3-19.ppp.op.net [209.152.194.89]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id SAA18577 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 7 Oct 1999 18:44:40 -0400 (EDT)
Message-Id: <199910072244.SAA18577@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] multi-track audio files - what format ? 
In-reply-to: Your message of "Thu, 07 Oct 1999 14:56:27 EDT."
             <Pine.GSO.4.10.9910071453250.11750-100000@ux02.CS.Princeton.EDU> 
Date: Thu, 07 Oct 1999 19:40:10 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 93c0e3b5fa2147db0248734643836397

>> OK, so to my disappointment, Michael Pruett's libaudiofile, just like
>> its SGI counterpart, doesn't support multi-track files. Does anyone
>> have any advice on file formats that support non-interleaved,
>> multi-track sound ?
>
>Non-interleaved?  Why not just use multiple conventional files (mono or
>stereo) which get read or written in parallel?  

Looks like this will have to be the way for now. But this sucks from
the application/user point of view. I want my recording session
bundled up in a single file, not 2 or 3 or 17 files. 

>But why wouldn non-interleaved be better performance?  Wouldn't you have
>to bounce around the disk more?

well, now that i think about it, what with fs prefetching and all,
yes, you might be right for the read case. but for writing, it means
all kinds of lseek() calls if we just want to overwrite a single track
so that we can write single samples.

however, because the mixer doesn't do this (rewrite a single track),
its cheap enough for now. to be honest even if it did, it would be
reading the file in as a series of chunks, then do pointer skips
rather than lseeks() to reset the data for a given track, and then a
final write(2) of a chunk. its only in the case of wanting to
overwrite a track without reading the file first that the interleaving
will cost, right ?

[ ... unanswerable philosophy elided ... ]

--p

From - Fri Oct  8 00:42:54 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA27612
	for <slinkp@ulster.net>; Thu, 7 Oct 1999 21:39:46 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA02152 for linux-audio-dev-list; Thu, 7 Oct 1999 21:03:11 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA02149 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 7 Oct 1999 21:03:08 -0400
Received: from localhost.localdomain (d212-151-43-147.swipnet.se [212.151.43.147]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA08952; 
          Fri, 8 Oct 1999 02:58:40 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Roger Larsson <roger.larsson@skelleftea.mail.telia.com>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] API design again [code]
Date: Fri, 8 Oct 1999 01:58:24 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <37FD2E51.F9E770B3@skelleftea.mail.telia.com>
MIME-Version: 1.0
Message-Id: <99100803052505.00471@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id CAA08952
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA27612
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 243aa6db40e76e7df49a8e30ca90a215

On Fri, 08 Oct 1999, Roger Larsson wrote:
> I guess I have to take another look at Davids API and try to merge...
> [where is it]

I think I've posted about all code I have for the current version on the list.

Anyway, I still have a problem, I think... In the last version I posted, the
plug-in gets the event buffer in the form of an array of "event descriptors".
The event port is the highest level interface to the event system:

---8<------------------------------
struct event_port_t {
	qm_heap_t		*heap;		/* For dynamic allocation */
	int			events;		/* Number of events
						 * currently in the buffer
						 */
	int			maxevents;	/* Size of the buffer */
	event_descriptor_t	**buffer;
};
------------------------------>8---

(qm_heap_t is the fast, inline dynamic memory allocator I presented earlier. In
short; one conditional and a few simple operations per qm_malloc(); a function
call if the current heap buffer is exhausted.)

In order to be able to send events to multiple recipients (with different time
bases), send events based on static data, send the same event multiple times,
sort/merge event buffers, and other things with minimal copying, I invented
event_descriptor_t:

---8<------------------------------
struct event_descriptor_t {
	event_time_t		time;
	event_t			*event;
};
------------------------------>8---

And the event, of course... (I think that **from should be removed from the
basic version - I'd guess most kinds of events aren't replied to anyway.)

---8<------------------------------
struct event_t {
	event_code_t		code;		/* What is this? */
	event_port_t		**from;		/* Who is this from? */
	int			size;		/* Number of data bytes */
};
------------------------------>8---


So for the problem: What happens when a plug-in (or someone else for that
matter) is sending events to a port?

Memory for the _events_ is allocated using

qm_malloc(destinationPort->heap,<SIZE>);

but the array of event descriptors? The descriptors are rather small, so
perhaps just setting up fixed buffers of adequate size is enough, but I don't
like it. It's clumsy, inflexible and a waste of RAM.

A few ideas:

A check will have to be done for every event in any case, unless we require
the engine to set up the MMU hardware to handle it. One conditional here, and
one for the event allocation...

A quick "fix" would be to use smaller buffers for the arrays, adding buffers
as they fill up. Unlimited number of events, but it's a real mess.

Quick fix 2:
---8<------------------------------
struct event_descriptor_t {
	event_descriptor_t	*next;	/* <- Right here... */
	event_time_t		time;
	event_t			*event;
};
------------------------------>8---

A lot cleaner, but now it starts to look like an entry in some damn Maximum
Indirection Design contest... Where does this start to cost more than the extra
copying that would be needed without it? Or; How frequently will events be
reused, and how big data sections will these reused events have?

This is another solution...:

---8<------------------------------
typedef unsigned int event_code_t;
#define EV_CLASS_MASK    0xff000000 /* EVC_SYSTEM, EVC_CONTROL,... */
#define EV_FLAGS_MASK    0x00ff0000 /* EVF_REQUEST, EVF_REPLY... */
#define EV_KIND_MASK     0x0000ffff /* Exactly what event is this? */

struct event_t;

struct event_port_t {
	qm_heap_t		*heap;		/* For dynamic allocation */
	event_t			*events;	/* First event */
};

struct event_t {
	event_t			*next;
	event_time_t		time;
	event_code_t		code;		/* What is this? */
	int			size;		/* Number of data bytes */
};
------------------------------>8---

Nice, simple, and perhaps the extra copying doesn't make much difference,
considering the added complexity when trying to avoid it? After all, events are
supposed to be pretty small most of the time... And moving pointers around is
data copying as well.

Of course, events may include pointers... And qm_malloc() doesn't care much
what it's allocating memory for. Adding an EVC_EXTDATA event class that adds
pointer + size entries to event_t allows the engine to keep track of this
correctly, even accross networks and other messy settings.

Note: Zapped the reply port here. Should be the first entry in the data area
of events with (code & EVF_REQUEST).

Note2: The event_port_t events pointer it just what you see from the plug-in
(or client) side; it can be changed (or copied, or whatever) by the engine for
each "context switch" in order to optimize the merging of events for ports that
recieve events from multiple senders. Better ideas may emerge as we dig into
the "connection control system"...


Hmm... 02:40 local time. Bed time, I think...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Oct  8 00:42:17 1999
Received: from em.gardena.net ([212.11.71.70])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id SAA02693
	for <slinkp@ulster.net>; Thu, 7 Oct 1999 18:49:04 -0400
Received: from linuxhost.localdomain (IDENT:root@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id AAA11032;
	Fri, 8 Oct 1999 00:46:58 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id CAA01011;
	Fri, 8 Oct 1999 02:47:40 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Paul Winkler <slinkp@ulster.net>, LINART list <linart@li.org>
Subject: Re: [linux-audio-dev] Audio-Quality-HOWTO updated , latency: small corrections
Date: Fri, 8 Oct 1999 02:23:31 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>,
        linux-announce@sws1.ctd.ornl.gov
References: <37FC6103.1C5CA53A@ulster.net>
MIME-Version: 1.0
Message-Id: <99100802474000.00789@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: cb1c42c0431b2a46ac4a32749daadca5

On Thu, 07 Oct 1999, Paul Winkler wrote:
> The Audio-Quality-HOWTO has been updated. The new version is 0.0.8.
> 
> There are a few new juicy tidbits of soundcard information, some more
> info on 60-cycle hum, and a notice about kernel patches for improved
> realtime performance.
> 
> http://www.ulster.net/~abigoo/pw_linux/Audio-Quality-HOWTO.html
> -- 

looking good !

but IMHO the notes on latency reducing are not very correct:

"Don't run top or similar, which make extensive use of the /proc file system." 

true: on regular kernels heavy /proc filesystem access causes up to 20-30ms
latencies.
on 2.2.10-lowlatency-N6, no latency problems


"In linux/include/asm/param.h change HZ up from the #DEFINE HZ 100 line (and then rebuild the kernel)... 
This can reduce latency, but increases CPU overhead - more scheduling per
second... HZ is the "jiffies" value,  the basic interval used by the scheduler.
It is 100 on Intel platforms,  but... As it is at 1024 by default on Alpha
Linux then I suspect there is no serious probs setting it to that on a
modern-ish Intel box." 

increasing HZ is almost useless, except you need a more finegrained usleep()
(down to 2ms), but it doesn't help to lower the latency peaks during heavy 
disk I/O , /proc etc, since when this happens the kernel doesn't reschedule our
audio processes.

"In the kernel sources, change DEF_PRIORITY ... (it) is defined in linux/include/linux/sched.h and controls the default maximum timeslice. 
It defaults to 20 which corresponds to 200ms. A value of 1 means 10ms
timeslices. Setting this value to 1 TOTALLY DESTROYS the functionality of
nice.... lowering it means that each process runs for less time before schedule
checks for the next runner. It means in general the time between successive
scheduled runs of your code is less, this in general being a good thing for
(pseudo-realtime) stuff." 

very bad idea IMHO, and Linus would 100% agree on this,
again the cause is not priority (lowering timeslices doesn't help) or HZ
related, but the reason is that when Linux is in kernel mode, it runs in a sort
of cooperative multitasking, that means, if a kernel routine doesn't check the
need of rescheduling for too much time , then you will get latencies,
regardless of your workaround tricks.

Jim then adds a caveat: "To be honest I have not yet had the application that stresses the system enough for these to make a major impact.
 Since I upgraded my venerable 486 last year to a K5-166, I have loadsa
headroom.  I've altered the HZ (1000) stuff on my kernel, Seems fine, I'm
planning on making it permanent."

increasing HZ to 1000 drops the overall performance by a few % (not much on a
PII), but in some cases there is an advantage:
for example the SB AWE64 MIDI out FIFO doesn't have an IRQ, therefore you must
use busywaiting or high frequency polling, and in fact
with the default HZ=100 you get up to 10ms MIDI-out latency which is bad ,
(but consider this MIDI hardware is crap, as Jaroslav and Paul
Barton-Davis pointed out). Increasing HZ to 1000 you don't get the full MIDI
bandwidth but come close to 60-70% ( 2000bytes/sec vs 3125bytes/sec from the
MIDI port), plus the MIDI out latency will go down to about 2ms when setting
HZ=1000.

As Paul Barton-Davis discovered even on a HZ=100 box using decent MIDI
interfaces (for example audiopci or trident), you can get close to the HW
limits, 1.1ms on his trident.

Paul Winkler: please add the above notes to your HOWTO,
since people should not be fooled by some wrong (and useless) workarounds.


regards,
Benno.

From - Fri Oct  8 00:42:23 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA06940
	for <slinkp@ulster.net>; Thu, 7 Oct 1999 19:22:17 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA01874 for linux-audio-dev-list; Thu, 7 Oct 1999 18:51:58 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA01871 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 7 Oct 1999 18:51:54 -0400
Received: from linuxhost.localdomain (IDENT:root@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id AAA11032;
	Fri, 8 Oct 1999 00:46:58 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id CAA01011;
	Fri, 8 Oct 1999 02:47:40 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Paul Winkler <slinkp@ulster.net>, LINART list <linart@li.org>
Subject: Re: [linux-audio-dev] Audio-Quality-HOWTO updated , latency: small corrections
Date: Fri, 8 Oct 1999 02:23:31 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>,
        linux-announce@sws1.ctd.ornl.gov
References: <37FC6103.1C5CA53A@ulster.net>
MIME-Version: 1.0
Message-Id: <99100802474000.00789@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 183ec579ae10af3c81832c0de6e150e9

On Thu, 07 Oct 1999, Paul Winkler wrote:
> The Audio-Quality-HOWTO has been updated. The new version is 0.0.8.
> 
> There are a few new juicy tidbits of soundcard information, some more
> info on 60-cycle hum, and a notice about kernel patches for improved
> realtime performance.
> 
> http://www.ulster.net/~abigoo/pw_linux/Audio-Quality-HOWTO.html
> -- 

looking good !

but IMHO the notes on latency reducing are not very correct:

"Don't run top or similar, which make extensive use of the /proc file system." 

true: on regular kernels heavy /proc filesystem access causes up to 20-30ms
latencies.
on 2.2.10-lowlatency-N6, no latency problems


"In linux/include/asm/param.h change HZ up from the #DEFINE HZ 100 line (and then rebuild the kernel)... 
This can reduce latency, but increases CPU overhead - more scheduling per
second... HZ is the "jiffies" value,  the basic interval used by the scheduler.
It is 100 on Intel platforms,  but... As it is at 1024 by default on Alpha
Linux then I suspect there is no serious probs setting it to that on a
modern-ish Intel box." 

increasing HZ is almost useless, except you need a more finegrained usleep()
(down to 2ms), but it doesn't help to lower the latency peaks during heavy 
disk I/O , /proc etc, since when this happens the kernel doesn't reschedule our
audio processes.

"In the kernel sources, change DEF_PRIORITY ... (it) is defined in linux/include/linux/sched.h and controls the default maximum timeslice. 
It defaults to 20 which corresponds to 200ms. A value of 1 means 10ms
timeslices. Setting this value to 1 TOTALLY DESTROYS the functionality of
nice.... lowering it means that each process runs for less time before schedule
checks for the next runner. It means in general the time between successive
scheduled runs of your code is less, this in general being a good thing for
(pseudo-realtime) stuff." 

very bad idea IMHO, and Linus would 100% agree on this,
again the cause is not priority (lowering timeslices doesn't help) or HZ
related, but the reason is that when Linux is in kernel mode, it runs in a sort
of cooperative multitasking, that means, if a kernel routine doesn't check the
need of rescheduling for too much time , then you will get latencies,
regardless of your workaround tricks.

Jim then adds a caveat: "To be honest I have not yet had the application that stresses the system enough for these to make a major impact.
 Since I upgraded my venerable 486 last year to a K5-166, I have loadsa
headroom.  I've altered the HZ (1000) stuff on my kernel, Seems fine, I'm
planning on making it permanent."

increasing HZ to 1000 drops the overall performance by a few % (not much on a
PII), but in some cases there is an advantage:
for example the SB AWE64 MIDI out FIFO doesn't have an IRQ, therefore you must
use busywaiting or high frequency polling, and in fact
with the default HZ=100 you get up to 10ms MIDI-out latency which is bad ,
(but consider this MIDI hardware is crap, as Jaroslav and Paul
Barton-Davis pointed out). Increasing HZ to 1000 you don't get the full MIDI
bandwidth but come close to 60-70% ( 2000bytes/sec vs 3125bytes/sec from the
MIDI port), plus the MIDI out latency will go down to about 2ms when setting
HZ=1000.

As Paul Barton-Davis discovered even on a HZ=100 box using decent MIDI
interfaces (for example audiopci or trident), you can get close to the HW
limits, 1.1ms on his trident.

Paul Winkler: please add the above notes to your HOWTO,
since people should not be fooled by some wrong (and useless) workarounds.


regards,
Benno.

From - Fri Oct  8 00:42:58 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA02929
	for <slinkp@ulster.net>; Thu, 7 Oct 1999 22:33:32 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA02266 for linux-audio-dev-list; Thu, 7 Oct 1999 21:54:59 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA02263 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 7 Oct 1999 21:54:56 -0400
Received: from someip.ppp.op.net (d-bm2-08.ppp.op.net [209.152.194.40]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id VAA03039 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 7 Oct 1999 21:50:28 -0400 (EDT)
Message-Id: <199910080150.VAA03039@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway 
In-reply-to: Your message of "Fri, 08 Oct 1999 00:06:45 +0200."
             <99100800291702.00471@localhost.localdomain> 
Date: Thu, 07 Oct 1999 22:46:00 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 074d550d41004df8dd64bb956e3a6000

[ ... MIDI-based automation with the ALSA sequencer ... ]	

>The same can be done with an engine using a plug-in API with my event
>system.  A sequencer could be either a plug-in or a client
>application, and it could record anything that goes on in the
>system. (That's the routing functionality that's one of all things I
>worry about when trying to design an efficient even t system...) No
>need for a special automated mixer (although one would be very nice
>as a GUI) and *anything* could be automated. And it would be sample
>accurate...

actually, i don't think this is quite true unless you're talking about
RTLinux or special audio apps. userspace processes have a fundamental
timing limit of 1/HZ seconds, unless they (1) run at RT priority and
use the RTC to kick them periodically or (2) continually drive +
monitor the status of a DAC of some kind.

the beauty of the ALSA sequencer is that it offers an extremely
generic event router with a timing limit that is not subject to the
same limits. Alas, this is a theoretical possibility right now, since
even the kernel doesn't check the timer queue more than HZ times a
second. However, add the UTIME patch, and the kernel can do flexibly
scheduled stuff with microsecond resolution.

also, note that my point about automation was not that one would have
a "specially automated mixer" - in fact, I meant *exactly* the
opposite: an application can take the simple step of writing a
Standard MIDI file as a record of all automation messages. why MIDI ?
why not some more "evolved" event specification ?  99% of all
available control surfaces use MIDI to do their thing. if you're doing
this stuff with any seriousness, US$300 for a PC1600X is a fairly
minimal investment in 16 physical faders. 

once you've got the MIDI file, the existence of MIDI playback tools
*and* the ALSA sequencer allow anything to become automated *without*
any special code: you just add the relevant sequencer port to the list
of MIDI ports you select(2) on, and it all works like magic.

yes, you could instead come up with a new event API and record the
"happenings" in the application with it, and then arrange for a way to
play it back. while you code it, we'll get on with using the ALSA
sequencer :)

--p

From - Fri Oct  8 03:01:54 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id CAA26055
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 02:52:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id CAA06414 for linux-audio-dev-list; Fri, 8 Oct 1999 02:18:47 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA06411 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 02:18:45 -0400
Received: from op.net (d-bm2-1c.ppp.op.net [209.152.194.60]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id CAA17139; Fri, 8 Oct 1999 02:14:06 -0400 (EDT)
Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id CAA14397; Fri, 8 Oct 1999 02:14:10 -0400
Date: Fri, 8 Oct 1999 02:14:10 -0400
Message-Id: <199910080614.CAA14397@op.net>
From: Paul Barton-Davis <pbd@Op.Net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] new tool: SFDB "the soundfile database"
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 23f80df83581b330b264fa526a163fcc

I wrote a new little tool tonight. You might enjoy it/find it useful.

            http://www.op.net/~pbd/sfdb-0.1.tar.gz

Here is the README file.
				 sfdb

		     Paul Barton-Davis, Fall 1999
		     ----------------------------

"sfdb" is a tool/library/GUI for working with and using a database of
soundfiles.

It arises from my own work developing applications that use soundfiles
in various ways - I wanted a standard way to look up all the available
soundfiles, and some basic information about them, without schlepping
all over the place.

It consists of 3 parts:

   libsfdb.a : a tiny library allowing for the creation of
               a database, adding new directory trees, and provide
	       database listings to stdout. Written in C.

   sfdb:       a small cmdline tool allowing you to create, add to
               and list soundfile databases. Written in C.

   gsfdb:      a Gtk-- interface to a soundfile database. It includes a
	       widget (sfdbDisplay) that can be used to play any
	       soundfile when it is selected from the display. You can
	       add new directories to an existing database in gsfdb,
	       but you can't create the database from scratch. Written
	       in C++.

It turns that gsfdb is something rather like a jukebox containing
every soundfile you have stuffed in the database. Its cool!

Things you need:
================

1) To build libsfdb.a and sfdb

   * Bill Schottstaedt's sndlib
        ftp://ccrma-ftp.stanford.edu/pub/Lisp/sndlib.tar.gz
   * the GNU DBM library (gdbm)
        (almost certainly installed on your machine already)

   With the current Makefile, both need to be installed in standard
   places (e.g. /usr/lib or /usr/local/lib)

2) to build gsfdb

   * all items in (1)
   * GTK+ 1.1 or above
   * Gtk-- 1.0.2 or above

Using the programs
==================

In all the cases below, "some-file-name" is the name of the file that
will contain the database.

* To build a database from the trees defined by SFDB_PATH (a
colon-separated list of directories):

   sfdb	-d some-file-name -c

* To build a database from the trees specified on the cmd line:

   sfdb -d some-file-name -c dir1:dir2:dir3:dir4

* To add to a database from a single directory tree (this will build a
new database if "some-file-name" doesn't already exist):

   sfdb -d some-file-name -a some-directory

* To inspect the contents of a database from the cmdline:

   sfdb -d some-file-name -l

* To run the GUI:

   gsfdb -d some-file-name [ --play | --noplay ]

You may wish to define the environment variable SFDB_PLAYER as the
full pathname of a program that can play arbitrary soundfiles. The
default is /usr/local/bin/sndplay, which uses the OSS sound
interfaces, which is a poor choice, but it works reliably on files
that some other players can't handle. Also, if you have Bill's sndlib
library, then you also have sndplay.

Future Possibilities (feel free to do any of them - it works for me)
====================

* use autoconf and automake
* add keywords/annotations
* allow searching
* consider using mySQL and relational searches



From - Fri Oct  8 04:11:49 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id EAA29362
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 04:00:06 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id DAA06542 for linux-audio-dev-list; Fri, 8 Oct 1999 03:30:19 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA06539 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 03:30:17 -0400
Received: from ulster.net (port196.ts2.ulster.net [208.242.164.196])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id DAA27867
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 03:27:13 -0400
Message-ID: <37FD9E56.6612A2F8@ulster.net>
Date: Fri, 08 Oct 1999 03:33:42 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Audio-Quality-HOWTO updated , latency: small 
 corrections
References: <37FC6103.1C5CA53A@ulster.net> <99100802474000.00789@linuxhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 92c48a84c45581d5e2dfbeb80a6e0980

Thanks very much Benno and David for the information. I am dependent
entirely on contributed information, so it's important to have
knowledgeable people point out such problems.
I have added your comments to the HOWTO and uploaded it again. (Didn't
change the version number, though...)


----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Fri Oct  8 06:21:49 1999
Received: from em.gardena.net ([212.11.71.70])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id GAA03827
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 06:13:19 -0400
Received: from linuxhost.localdomain (IDENT:root@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id MAA19157;
	Fri, 8 Oct 1999 12:11:30 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id OAA00838;
	Fri, 8 Oct 1999 14:12:03 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Paul Winkler <slinkp@ulster.net>,
        "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Audio-Quality-HOWTO updated , CD-ripping additions
Date: Fri, 8 Oct 1999 13:31:30 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <37FD9E56.6612A2F8@ulster.net>
MIME-Version: 1.0
Message-Id: <99100814120300.00774@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 591015154f355caf88095071f5da1802

On Fri, 08 Oct 1999, Paul Winkler wrote:
> Thanks very much Benno and David for the information. I am dependent
> entirely on contributed information, so it's important to have
> knowledgeable people point out such problems.
> I have added your comments to the HOWTO and uploaded it again. (Didn't
> change the version number, though...)
> 
> 

Yea, is important that the user gets the truth about system performance,
hw/sw limits etc., not like M$ where they make some claims, but can't provide
proofs or reliable tests.

Just an additional note to CD-ripping, that I would suggest to add in your 
HOWTO:

cdda2wav (and probably cdparanoia too), set the scheduling policy
to SCHED_FIFO during rippping  to minimize changes of corrupted CDDA
files on crappy CDROM drives  (old IDE CDROM drives), due to disk activity etc.

Modern CDROM drives (like the Plextor SCSI series and others (most SCSI and
modern IDE ones) provide bit-accurate audio extraction and large buffers.
That means there is no need for overlapping block reading
(to keep the track in sync) and high process priority for the cd ripping
software. 

Some time ago when I was experimenting with low-latency and system stressing,
I discovered CD ripping with my plextor CRDOM 32x SCSI causes frequent
audio dropouts, since it is able to rip CDDA up to 24x = 3MB/sec which causes
high disk writing output.

After running the cdda2wav as a regular user , so that it could not acquire
SCHED_FIFO privileges, running low-latency software (for example a realtime
FX processor) while ripping CDs at 24x speed worked perfectly.
Again I was able to get 2.1ms latency.

That means we would be able to run our DJ mixing software with RT effects etc,
while in background we rip CDs at maximum speed.
(and maybe even compressing them using an mp3 encoder).
Try to perform all this tasks simultaneously on windoze.
:-)

The drawback could be that if you have an old crappy IDE CDROM drive,
and run a low-latency SCHED_FIFO process which does a lot of CPU computations,
your ripped audio could contain some glitches (but the low-latency app would
still function perfectly) , but in this case it's not Linux's fault, since the
audio processing has priority over the ripping, and the faulty CDROM drive
doesn't provide accurate CDDA data.

Note on your DROPOUTS section: (should mention it too in your HOWTO)

killing sendmail , syslog etc *MAY* help ,
but the general rule to keep low dropouts is to
avoid disk activity on unpatched kernels since it's the main latency source.
Of course, in order to get latencies <50ms you have to run your app with
SCHED_FIFO policy (need to be root for this).
You can take some ideas from my low-latency HOWTO at linuxmusicstation
(thanks to John Littler for publishing it)

 http://linuxmusic.cjb.net/

I even provided a little commandline app which allows you to set SCHED_FIFO
to arbitrary processes.
That means if you have an old binary-only app which doesn't set SCHED_FIFO,
you can use the cmdline tool to set the RT scheduling policy.

When the lowlatency patches will (hopefully !!) get into the mainstream kernel,
the only rules left will be:
- tune the IDE disks with hdparm (as described in my HOWTO), especially DMA=on,
- use SCHED_FIFO for the audio thread (and don't run higher priority SCHED_FIFO
apps, but you can run lower priority SCHED_FIFO processes and get no dropouts)
- avoid disk I/O in the audio playing tasks,
that means if you read from/write to your audio to disk,
you have to use a 2 threaded model:
SCHED_FIFO audio thread ,which exchanges data (via you preferred IPC mechanism,
shared mem, pipes etc) with the disk thread which runs at lower priority.

My tests showed that running the disk thread at normal priority (maybe with
nice -10) or running it SCHED_FIFO (at lower priority than the audio thread)
made not a big difference in terms of disk performance.
since the disk thread waits almost all the time on read()s and write()s.
 
regards,
Benno.

Benno Senoner
E-Mail: sbenno@gardena.net
Linux low-latency audio / scheduling latency benchmarks
http://www.gardena.net/benno/linux/audio


From - Fri Oct  8 15:05:15 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA21981
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 09:18:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA07174 for linux-audio-dev-list; Fri, 8 Oct 1999 08:32:36 -0400
Received: from ccrma.stanford.edu (ccrma.Stanford.EDU [36.49.0.84]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA07171 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 08:32:33 -0400
Received: from cmn14.stanford.edu (cmn14.stanford.edu [36.49.0.93])
	by ccrma.stanford.edu (8.9.3/8.9.3) with ESMTP id FAA04862;
	Fri, 8 Oct 1999 05:28:03 -0700 (PDT)
Received: (from bil@localhost)
	by cmn14.stanford.edu (8.9.3/8.9.3) id FAA09686;
	Fri, 8 Oct 1999 05:28:01 -0700 (PDT)
Message-Id: <199910081228.FAA09686@cmn14.stanford.edu>
Content-Type: text/plain
MIME-Version: 1.0 (NeXT Mail 3.3 v148.2.1)
In-Reply-To: <199910071656.MAA17849@op.net>
X-Nextstep-Mailer: Mail 3.3 [m68k] (Enhance 2.2p2)
Received: by NeXT.Mailer (1.148.2.1)
From: Bill Schottstaedt <bil@ccrma.Stanford.EDU>
Date: Fri,  8 Oct 1999 05:27:58 -0700
To: Paul Barton-Davis <pbd@Op.Net>
Subject: Re: [linux-audio-dev] multi-track audio files - what format ?
cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <199910071656.MAA17849@op.net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ee945e5bbd218ca625ac12894fd3acfb

>  Surely one of the existing major formats allows multiple
> tracks ?

NIST-Sphere headers have a "channels_interleaved" field that
can be false, but I've never seen an actual file that used it.

From - Fri Oct  8 15:05:18 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA25796
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 09:43:07 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA07255 for linux-audio-dev-list; Fri, 8 Oct 1999 09:09:43 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA07252 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 09:09:40 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46472AbPJHNEt>; Fri, 8 Oct 1999 16:04:49 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <199910060529.BAA02614@renoir.op.net> (message from Paul
	Barton-Davis on Wed, 06 Oct 1999 02:24:58 -0400)
Subject: Re: [linux-audio-dev] Plugin API
Message-Id: <19991008130451Z46472-565+92@nic.funet.fi>
Date:   Fri, 8 Oct 1999 16:04:49 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: acf20d75c6d6311c2f30006a77ed56fe

>From:   Paul Barton-Davis <pbd@Op.Net>
>
>But I want so sound a cautionary note about plugin API's. If defining
>(and implementing) a reasonable API was all it took to get everyone to
>use it, then why doesn't digidesign use VST ? Why doesn't the GIMP use
>TDM ? Why doesn't Netscape use EASI ? 

Because VST and TDM are not free. I have not found TDM specifications
at all.

They are fixed to underlying implementation (VST SDK refers to ASIO
which is not free and nothing is in public -- you have to sign NDA to
get anything on it).

If you think VST and TDM are as good as what we are doing, then we should
develop VST further to suit also our purposes and demand the changes to
official VST --- do you think that is possible?

As soon as VST and TDM are released to public domain or GPL/LGPL
I will check them more closely.

Yours,

Juhana

From - Fri Oct  8 15:05:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA27130
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 09:51:49 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA07250 for linux-audio-dev-list; Fri, 8 Oct 1999 09:09:08 -0400
Received: from www.tomy.net (www.tomy.net [209.186.149.104]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA07243 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 09:09:05 -0400
From: thudson@cygnus.com
Received: from cygnus.com (IDENT:thudson@jimi.tomy.net [192.168.1.2])
	by www.tomy.net (8.9.3/8.9.3) with ESMTP id JAA31028;
	Fri, 8 Oct 1999 09:04:26 -0400
Message-ID: <37FDEC0D.125A586A@cygnus.com>
Date: Fri, 08 Oct 1999 09:05:17 -0400
Organization: Cygnus Solutions
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Barton-Davis <pbd@Op.Net>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway
References: <199910080150.VAA03039@renoir.op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7e23c99cddde77ecffdd915ca734bfc1

Paul Barton-Davis wrote:
> the beauty of the ALSA sequencer is that it offers an extremely
> generic event router with a timing limit that is not subject to the
> same limits. Alas, this is a theoretical possibility right now, since
> even the kernel doesn't check the timer queue more than HZ times a
> second. However, add the UTIME patch, and the kernel can do flexibly
> scheduled stuff with microsecond resolution.
> 
> once you've got the MIDI file, the existence of MIDI playback tools
> *and* the ALSA sequencer allow anything to become automated *without*
> any special code: you just add the relevant sequencer port to the list
> of MIDI ports you select(2) on, and it all works like magic.
>
I agree. The ALSA sequencer architecture is one killer feature that
would make any user have to seriously consider linux over other OSes.
 
One feature I think would make the ALSA sequencer even more useful would
be to add a "fake" raw midi interface. That is, an interface that behaved
like the raw midi interface to the client application, but showed up
in the list of ALSA sequencer clients that could be routed to other 
applications. It would deliver raw midi events from other clients
at the right time. As far as the app is concerned it would see them
as coming in from an external port in real time. This would allow 
legacy apps to participate in the routing architecture and perhaps 
benefit from the enhanced timing *without modification*.

I know this was discussed at one time, was a decision ever made to
include this? Or could it be done with a separate alsa kernel client?

Thomas

From - Fri Oct  8 15:05:21 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA29367
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 10:07:54 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA07302 for linux-audio-dev-list; Fri, 8 Oct 1999 09:27:25 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA07299 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 09:27:23 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46600AbPJHNWb>; Fri, 8 Oct 1999 16:22:31 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <199910070458.AAA11038@op.net> (message from Paul Barton-Davis on
	Thu, 7 Oct 1999 00:58:43 -0400)
Subject: Re: [linux-audio-dev] a new application underway
Message-Id: <19991008132234Z46600-563+76@nic.funet.fi>
Date:   Fri, 8 Oct 1999 16:22:31 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ae12ca452009cca036485b78e5dfe0ef

>From:   Paul Barton-Davis <pbd@Op.Net>
>
>     http://www.op.net/~pbd/hdr/screen.gif

Strips are too wide: (1) you can't show many of them in the same screen
(forget scrolling screens), (2) faders are puried too much for user to
understand their positions quickly. You could see the design of hardware
mixers as an example -- forget poor audio software applications if they
give this bad design ideas.

>This is a HDR program oriented toward live multi-track recording
>(distinct from many Linux programs that seem geared to recoding single
>tracks and merging them into a multi-track context). Currently, it

KDE has already this kind of multitrack recorder.

Yours,

Juhana

From - Fri Oct  8 15:05:22 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA30223
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 10:13:29 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA07338 for linux-audio-dev-list; Fri, 8 Oct 1999 09:36:07 -0400
Received: from gate.suse.cz (perex.cb.cesnet.cz [194.212.165.105]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA07334 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 09:36:00 -0400
Received: from localhost (perex@localhost)
	by gate.suse.cz (8.8.8/8.8.8) with ESMTP id PAA04298;
	Fri, 8 Oct 1999 15:30:26 +0200
X-Authentication-Warning: gate.suse.cz: perex owned process doing -bs
Date: Fri, 8 Oct 1999 15:30:26 +0200 (MEST)
From: Jaroslav Kysela <perex@suse.cz>
To: thudson@cygnus.com
cc: Paul Barton-Davis <pbd@Op.Net>,
        Linux Audio Development Mailing list <linux-audio-dev@ginette.musique.umontreal.ca>,
        alsa-devel@alsa-project.org
Subject: Re: [linux-audio-dev] a new application underway
In-Reply-To: <37FDEC0D.125A586A@cygnus.com>
Message-ID: <Pine.LNX.4.05.9910081520230.3873-100000@gate.suse.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e16390150c6797b16b6ff95a012ceaf9

On Fri, 8 Oct 1999 thudson@cygnus.com wrote:

> Paul Barton-Davis wrote:
> > the beauty of the ALSA sequencer is that it offers an extremely
> > generic event router with a timing limit that is not subject to the
> > same limits. Alas, this is a theoretical possibility right now, since
> > even the kernel doesn't check the timer queue more than HZ times a
> > second. However, add the UTIME patch, and the kernel can do flexibly
> > scheduled stuff with microsecond resolution.
> > 
> > once you've got the MIDI file, the existence of MIDI playback tools
> > *and* the ALSA sequencer allow anything to become automated *without*
> > any special code: you just add the relevant sequencer port to the list
> > of MIDI ports you select(2) on, and it all works like magic.
> >
> I agree. The ALSA sequencer architecture is one killer feature that
> would make any user have to seriously consider linux over other OSes.
>  
> One feature I think would make the ALSA sequencer even more useful would
> be to add a "fake" raw midi interface. That is, an interface that behaved
> like the raw midi interface to the client application, but showed up
> in the list of ALSA sequencer clients that could be routed to other 
> applications. It would deliver raw midi events from other clients
> at the right time. As far as the app is concerned it would see them
> as coming in from an external port in real time. This would allow 
> legacy apps to participate in the routing architecture and perhaps 
> benefit from the enhanced timing *without modification*.
> 
> I know this was discussed at one time, was a decision ever made to
> include this?

I'm not against it, if someone create a separate module.

> Or could it be done with a separate alsa kernel client?

Yes, this code can be implemented as a separate alsa kernel client.

							Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA project  http://www.alsa-project.org


From - Fri Oct  8 15:05:21 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA30152
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 10:13:09 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA07344 for linux-audio-dev-list; Fri, 8 Oct 1999 09:36:58 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA07341 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 09:36:56 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46188AbPJHNcO>; Fri, 8 Oct 1999 16:32:14 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <199910071656.MAA17849@op.net> (message from Paul Barton-Davis on
	Thu, 7 Oct 1999 12:56:50 -0400)
Subject: Re: [linux-audio-dev] multi-track audio files - what format ?
Message-Id: <19991008133215Z46188-565+93@nic.funet.fi>
Date:   Fri, 8 Oct 1999 16:32:14 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 69a690831c6630b0c6ebd784435743ef

>From:   Paul Barton-Davis <pbd@Op.Net>
>
>OK, so to my disappointment, Michael Pruett's libaudiofile, just like
>its SGI counterpart, doesn't support multi-track files. Does anyone
>have any advice on file formats that support non-interleaved,
>multi-track sound ?

Why would you need such files? Well, nobody wants carry their multitrack
project in one 4 Gbytes audiofile!

Just store every clip to their own files and additionally store the project
file to disk.

If you really need to have them all in the same file, then look at OMF.
But even that is not meant to be a production format. Tar works very well
too.

Yours,

Juhana

From - Fri Oct  8 15:05:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA09904
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 11:26:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA07524 for linux-audio-dev-list; Fri, 8 Oct 1999 10:34:53 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA07521 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 10:34:51 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46600AbPJHOaB>; Fri, 8 Oct 1999 17:30:01 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <37FE04E7.11C4CA2C@folkwang.uni-essen.de>
	(nettings@folkwang.uni-essen.de)
Subject: Re: [linux-audio-dev] multi-track audio files - what format ?
Message-Id: <19991008143003Z46600-563+78@nic.funet.fi>
Date:   Fri, 8 Oct 1999 17:30:01 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2d0cef417929d0e63145c2f88f782376

>From:   =?iso-8859-1?Q?J=F6rn?= Nettingsmeier 
>        <nettings@folkwang.uni-essen.de>
>
>one file, many tracks interleaved: 
> + easy streaming

Only if playing the final product.

> + easier to organize and backup than multiple files

Not for large projects.

> + probably easier to implement (my guess)

Because edits and so on are impossible, the 100 lines code for playing
is easy to write.

Non-descructive takes turns this scheme to multiple files scheme
pretty quickly. If a track has only few sounds during the whole song,
you have plenty of silency on the disk.

Playing one track from multitrack interleaved file causes all tracks to
be read. 

> - changing track offsets means rewriting the entire file

Changing anything...

>one file per track:
> + easy offsetting, just add zeros at the beginning

It is not done by adding zeros... but with playlist/editlist/edit decision
list.

> + easy to move parts around
> + tracks can be spread over different disks, thus speeding up disk
>    i/o.
[ ... ]
>it seems that the first way is more elegant to read from/write to in
>real time, while the latter is nicer for editing purposes.

Sure playing tracks from different disks makes the latter better suited to
real-time.

(Naturally, stereo recordings from A/D or multitrack files need not be
splitted to individual track files.)

Yours,

Juhana

From - Fri Oct  8 15:05:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA09205
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 11:21:26 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA07543 for linux-audio-dev-list; Fri, 8 Oct 1999 10:41:44 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA07540 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 10:41:42 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id KAA27380
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 10:36:40 -0400 (EDT)
Received: from localhost by ux02 (8.9.1b+Sun) id KAA21181; Fri, 8 Oct 1999 10:36:40 -0400 (EDT)
Date: Fri, 8 Oct 1999 10:36:40 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] multi-track audio files - what format ? 
In-Reply-To: <199910072244.SAA18577@renoir.op.net>
Message-ID: <Pine.GSO.4.10.9910081024430.21000-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: dc5ceea22cbe072787792f0f54af44f8

On Thu, 7 Oct 1999, Paul Barton-Davis wrote:

> Looks like this will have to be the way for now. But this sucks from
> the application/user point of view. I want my recording session
> bundled up in a single file, not 2 or 3 or 17 files. 

On NeXTStep, there was this convention, the name of which I forget, that a
directory could be treated as a single file.  You'd name the directory
with a file extension (ie: "multi-track-song1.mts") and each file in that
directory would be equivalent to a chunk in an IFF file.  For the
application that needed the multiple chunks, you'd enter the directory and
access them like normal files, but for file management and distribution,
you'd move the directory around as a whole.  I'd love to see that on
Linux, as it would solve this problem and many others very cleanly.  The
only required code changes would be in file managers (kfm, gmc, etc).

> well, now that i think about it, what with fs prefetching and all,
> yes, you might be right for the read case. but for writing, it means
> all kinds of lseek() calls if we just want to overwrite a single track
> so that we can write single samples.

> however, because the mixer doesn't do this (rewrite a single track),
> its cheap enough for now. to be honest even if it did, it would be
> reading the file in as a series of chunks, then do pointer skips
> rather than lseeks() to reset the data for a given track, and then a
> final write(2) of a chunk. its only in the case of wanting to
> overwrite a track without reading the file first that the interleaving
> will cost, right ?

I'm a little confused.  Actually a lot confused.  Isn't the default and
most often used case to read and write all tracks at once?  Besides, if
you want to rewrite a single track efficiently in an interleaved file,
just mmap the thing, and let paging remove all the cost (and complexity)  
of lseeking.

Div.

From - Fri Oct  8 15:05:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA09600
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 11:23:57 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA07548 for linux-audio-dev-list; Fri, 8 Oct 1999 10:42:14 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA07545 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 10:42:03 -0400
Received: from someip.ppp.op.net (d-bm3-13.ppp.op.net [209.152.194.83]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id KAA03841 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 10:37:32 -0400 (EDT)
Message-Id: <199910081437.KAA03841@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway 
In-reply-to: Your message of "Fri, 08 Oct 1999 16:22:31 +0300."
             <19991008132234Z46600-563+76@nic.funet.fi> 
Date: Fri, 08 Oct 1999 10:37:41 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 34ce0363688c35bb8dc84bcd13236a5f

>>     http://www.op.net/~pbd/hdr/screen.gif
>
>Strips are too wide: (1) you can't show many of them in the same screen
>(forget scrolling screens), (2) faders are puried too much for user to
>understand their positions quickly. You could see the design of hardware
>mixers as an example -- forget poor audio software applications if they
>give this bad design ideas.

all understood. in fact, hdr (like the creamware mixer) is entirely
based on hardware mixers.

as I commented, the UI visual elements need work, but since they are
just a set of pixmaps, you don't need to recompile anything to change
how it looks. As soon as I design a set of narrow led pixmaps and
slider pixmaps, each strip will shrink down. I think that the current
limitation on width comes from the insert name display panels, which
are big enough to say "delay" in a 9pt font. i don't think i want
these any smaller.

scrolling screens matter. if i want 64 channels. there is no way to
*ever* fit them on the screen.

>KDE has already this kind of multitrack recorder.

well, thats an area i stay away from. the whole Qt thing just leaves a
bizarre taste in my mouth, and the idea that every application is part
of this "big thing" leaves an even funnier taste. note that this is
not even a GNOME application, just a Gtk-- one.

what is is called ? just so i can take a look :)

--p

From - Fri Oct  8 15:05:28 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA06294
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 11:03:07 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA07458 for linux-audio-dev-list; Fri, 8 Oct 1999 10:10:13 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA07455 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 10:10:11 -0400
Received: from bright.net (find-cas2-cs-11.dial.bright.net [209.143.26.165])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id KAA14788;
	Fri, 8 Oct 1999 10:05:24 -0400 (EDT)
Message-ID: <37FE01BC.AF6758B0@bright.net>
Date: Fri, 08 Oct 1999 10:37:48 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Juhana Sadeharju <kouhia@nic.funet.fi>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway
References: <19991008132234Z46600-563+76@nic.funet.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5a72210c668dad116523b3236c49347a

Juhana Sadeharju wrote:

> KDE has already this kind of multitrack recorder.

My version of KHDRec (0.4 beta) doesn't record. Something of a drawback,
I'd say...It also seems that development has halted on that project.
Open-sources, though, in case anyone wants to continue it...

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html

From - Fri Oct  8 15:05:34 1999
Received: from taz.ulster.net (root@taz.ulster.net [208.148.73.10])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id LAA10652
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 11:32:08 -0400
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34]) by taz.ulster.net (8.8.5/8.7.3) with SMTP id LAA06339 for <slinkp@ulster.net>; Fri, 8 Oct 1999 11:34:15 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA07589 for linux-audio-dev-list; Fri, 8 Oct 1999 10:49:08 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id KAA07586 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 10:49:05 -0400
From: est@hyperreal.org
Received: (qmail 25580 invoked by uid 162); 8 Oct 1999 14:44:29 -0000
Message-ID: <19991008144429.25579.qmail@hyperreal.org>
Subject: [linux-audio-dev] ALSA sequencer & PC1600X
In-Reply-To: <199910080150.VAA03039@renoir.op.net> from Paul Barton-Davis at
 "Oct 7, 1999 10:46:00 pm"
To: Paul Barton-Davis <pbd@Op.Net>
Date: Fri, 8 Oct 1999 07:44:29 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: d2d91f8b0fe85cfee7f89b74af8a7199

Paul Barton-Davis discourseth:
> 
> the beauty of the ALSA sequencer is that it offers an extremely
> generic event router with a timing limit that is not subject to the
> same limits.

Hmm..just how generic?

> if you're doing
> this stuff with any seriousness, US$300 for a PC1600X is a fairly
> minimal investment in 16 physical faders. 

Ooooh!  I found this on the Peavey site..must have.  Any
recommendations as to where to purchase it?  Also, do you know of any
configuration gotchas like requiring Windows/Mac software for
configuration?  As long as its all midi and documented I'll be happy.

Eric

From - Fri Oct  8 15:05:24 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA30893
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 10:17:13 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA07322 for linux-audio-dev-list; Fri, 8 Oct 1999 09:32:07 -0400
Received: from icemserv.folkwang.uni-essen.de (icemserv.folkwang.uni-essen.de [132.252.170.129]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA07316 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 09:31:54 -0400
Received: from folkwang.uni-essen.de (nettings@dialup2.folkwang.uni-essen.de [132.252.170.2]) by icemserv.folkwang.uni-essen.de (8.8.8/8.7.3) with ESMTP id PAA06799 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 15:16:05 +0200 (CEST)
Message-ID: <37FE04E7.11C4CA2C@folkwang.uni-essen.de>
Date: Fri, 08 Oct 1999 14:51:19 +0000
From: =?iso-8859-1?Q?J=F6rn?= Nettingsmeier <nettings@folkwang.uni-essen.de>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] multi-track audio files - what format ?
References: <199910072244.SAA18577@renoir.op.net>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: aa42dad74bf86891361d999945f21f9d

hello,

i hope you'll forgive me joining this thread as a non-programmer...
i have some thoughts about multitrack files that may be useful but
need verification.
some suggestions may be utterly stupid, and i'd appreciate
corrections from people who really know about this !

one file, many tracks interleaved: 
 + easy streaming
 + easier to organize and backup than multiple files
 + probably easier to implement (my guess)
 - changing track offsets means rewriting the entire file
    (these are useful for me to give a sloppy hihat-track a little
    more "edge" or relaxing eager bass players :). the adat has 
    this built in.)
 - moving around parts is complicated

one file per track:
 + easy offsetting, just add zeros at the beginning
 + easy to move parts around
 + tracks can be spread over different disks, thus speeding up disk
    i/o.
 - tracks will be read at differrent speeds depending on disk
    geometry and other fs related things, so i'd expect this needs
    larger buffers than interleaved files, thus greater latency. 
    (does that make sense ?)
 
it seems that the first way is more elegant to read from/write to in
real time, while the latter is nicer for editing purposes.

waiting for enlightenment,

jrn



Paul Barton-Davis wrote:
> 
> >> OK, so to my disappointment, Michael Pruett's libaudiofile, just like
> >> its SGI counterpart, doesn't support multi-track files. Does anyone
> >> have any advice on file formats that support non-interleaved,
> >> multi-track sound ?
> >
> >Non-interleaved?  Why not just use multiple conventional files (mono or
> >stereo) which get read or written in parallel?
> 
> Looks like this will have to be the way for now. But this sucks from
> the application/user point of view. I want my recording session
> bundled up in a single file, not 2 or 3 or 17 files.
> 
> >But why wouldn non-interleaved be better performance?  Wouldn't you have
> >to bounce around the disk more?
> 
> well, now that i think about it, what with fs prefetching and all,
> yes, you might be right for the read case. but for writing, it means
> all kinds of lseek() calls if we just want to overwrite a single track
> so that we can write single samples.
> 
> however, because the mixer doesn't do this (rewrite a single track),
> its cheap enough for now. to be honest even if it did, it would be
> reading the file in as a series of chunks, then do pointer skips
> rather than lseeks() to reset the data for a given track, and then a
> final write(2) of a chunk. its only in the case of wanting to
> overwrite a track without reading the file first that the interleaving
> will cost, right ?
-- 
Jrn Nettingsmeier     
Kurfrstenstr. 49        
45138 Essen, Germany

From - Fri Oct  8 15:05:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA11519
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 11:37:07 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA07607 for linux-audio-dev-list; Fri, 8 Oct 1999 10:59:44 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA07604 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 10:59:42 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id KAA29528
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 10:54:15 -0400 (EDT)
Received: from localhost by ux02 (8.9.1b+Sun) id KAA21352; Fri, 8 Oct 1999 10:54:15 -0400 (EDT)
Date: Fri, 8 Oct 1999 10:54:15 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway 
In-Reply-To: <199910080150.VAA03039@renoir.op.net>
Message-ID: <Pine.GSO.4.10.9910081050520.21000-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c1459f04438da8556f84c82dc5334c5c

On Thu, 7 Oct 1999, Paul Barton-Davis wrote:

> once you've got the MIDI file, the existence of MIDI playback tools
> *and* the ALSA sequencer allow anything to become automated *without*
> any special code: you just add the relevant sequencer port to the list
> of MIDI ports you select(2) on, and it all works like magic.

I hate to harp on this, but it doesn't require the ALSA sequencer at all
(yes, I really like the ALSA sequencer design, but it's not needed here).
You can read and write MIDI messages on any file descriptor, whether it's
an ALSA MIDI port, a pipe, or a socket.  If only today's sequencers
weren't hardwired to only look at /dev/midi...

Div.


From - Fri Oct  8 15:05:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA14914
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 12:00:06 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA07731 for linux-audio-dev-list; Fri, 8 Oct 1999 11:28:07 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA07725 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 11:28:04 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id LAA02487;
	Fri, 8 Oct 1999 11:21:44 -0400 (EDT)
Received: from localhost by ux02 (8.9.1b+Sun) id LAA21696; Fri, 8 Oct 1999 11:21:43 -0400 (EDT)
Date: Fri, 8 Oct 1999 11:21:43 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: thudson@cygnus.com
cc: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway
In-Reply-To: <37FDEC0D.125A586A@cygnus.com>
Message-ID: <Pine.GSO.4.10.9910081058030.21000-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 18154c2ad7093db993276916a04a7e18

On Fri, 8 Oct 1999 thudson@cygnus.com wrote:

> One feature I think would make the ALSA sequencer even more useful would
> be to add a "fake" raw midi interface. That is, an interface that behaved
> like the raw midi interface to the client application, but showed up
> in the list of ALSA sequencer clients that could be routed to other 
> applications. It would deliver raw midi events from other clients
> at the right time. As far as the app is concerned it would see them
> as coming in from an external port in real time. This would allow 
> legacy apps to participate in the routing architecture and perhaps 
> benefit from the enhanced timing *without modification*.

This is hitting very close to home with me.  I've looked at the way this
is done on Windows (MME) and SGI (libmd) and have implemented my own on
Linux (NetMIDI). If you view the problem in OOP terms, it is easier to
visualize the differences.

On MME and libmd, the "object" on which open, close, read, and write
methods are available is a MIDI port, which can be either an Out or an In.  
To call these methods is a trivial operation, but to create the object
is very difficult... it requires driver-level programming, which turns off
many programmers and thus stifles progress.

On NetMIDI, the object is not a port, but rather the "cable", which is
either a socket connection or a pipe.  You still have the same open,
close, read, and write methods, but to create a pipe or a socket
connection is a trivial operation, which requires no driver-level
programming; it can even be done via shell scripts.  An added benefit is
that there are a practically unlimited number of "cables" that you can
have open at once, which is not something that is guaranteed in either MME
or libmd.

If this happier view of the world is impractical to add to ALSA at this
point, we could write an ALSA midi port driver (once, so we'll not have to
deal with the pain of driver programming again) similar to the "MIDI Thru"
drivers available for Windows MME.  These screwy drivers act like fifos
which other MIDI apps (not drivers) can access the way I described for
NetMIDI.  Once you had this, you wouldn't write your softsynth as a
driver, but as a regular app that listened on the Thru driver's port. The
drawback here is that you have a strictly limited number of Thru "cables".

Div.

From - Fri Oct  8 15:05:40 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA16590
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 12:11:44 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA07787 for linux-audio-dev-list; Fri, 8 Oct 1999 11:40:18 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA07784 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 11:40:15 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46188AbPJHPf0>; Fri, 8 Oct 1999 18:35:26 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] fp underflow
Message-Id: <19991008153527Z46188-563+79@nic.funet.fi>
Date:   Fri, 8 Oct 1999 18:35:26 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 4d5a669e11e0063bb51e13e6edabb239

>I think you have to resort to adding DC, adding noise, testing for
>small values, that sort of thing.

Hello. I tested these ideas with my GVerb. Specially a reverb decays signals
toward zero but cutting the low amplitude tail away did decrease the
rate of exceptions only less than 5%.

Adding a DC feels like a bad idea but adding a DC at 24'th bit level
helped.

More I like the idea of adding noise. I added 24'th bit level noise
to input signal. The slowdown when underflow exception is on is
(1) 1.7 times without noise,
(2) 1.07 times with noise added to input.

The above estimates are based on the observation that a multiply with
underflow is 8.5 times slower than multiply without underflow.

I think adding noise can be done only the main inputs of the entire flow
network. Perhaps quantizer plug-in and already 24-bit signals are exceptions.

The effect of adding noise and DC were exactly the same.

Yours,

Juhana

From - Fri Oct  8 15:05:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA18671
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 12:25:55 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA07818 for linux-audio-dev-list; Fri, 8 Oct 1999 11:51:31 -0400
Received: from cygnus.com (runyon.cygnus.com [205.180.230.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA07815 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 11:51:28 -0400
Received: from cygnus.com (thudson1.cygnus.com [205.226.144.45])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id IAA10825;
	Fri, 8 Oct 1999 08:46:40 -0700 (PDT)
Message-ID: <37FE11DF.AE120910@cygnus.com>
Date: Fri, 08 Oct 1999 11:46:39 -0400
From: Thomas Hudson <thudson@cygnus.com>
Organization: Cygnus Solutions
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: David Slomin <dgslomin@CS.Princeton.EDU>
CC: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway
References: <Pine.GSO.4.10.9910081058030.21000-100000@ux02.CS.Princeton.EDU>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: db5c3d8ee26a17197192b780c9a3c8ce

David Slomin wrote:
>
> On NetMIDI, the object is not a port, but rather the "cable", which is
> either a socket connection or a pipe.  You still have the same open,
> close, read, and write methods, but to create a pipe or a socket
> connection is a trivial operation, which requires no driver-level
> programming; it can even be done via shell scripts.  An added benefit is
> that there are a practically unlimited number of "cables" that you can
> have open at once, which is not something that is guaranteed in either MME
> or libmd.
>
Yes, initially I thought I could do this w/ a user space client talking to
ALSA, interfacing w/ the legacy app thru a pipe, since the pipe would appear
as a device file to the app. Unfortunately, most of the apps I'm interested
in both read and write to the raw midi interface.

> If this happier view of the world is impractical to add to ALSA at this
> point, we could write an ALSA midi port driver (once, so we'll not have to
> deal with the pain of driver programming again) similar to the "MIDI Thru"
> drivers available for Windows MME.  These screwy drivers act like fifos
> which other MIDI apps (not drivers) can access the way I described for
> NetMIDI.  Once you had this, you wouldn't write your softsynth as a
> driver, but as a regular app that listened on the Thru driver's port. The
> drawback here is that you have a strictly limited number of Thru "cables".
> 
Seems like a ALSA kernel client could do this. 

Thomas

From - Sun Oct 10 22:31:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA31831
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 07:12:37 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA13780 for linux-audio-dev-list; Sat, 9 Oct 1999 06:41:02 -0400
Received: from sculpcave (cvx-2-413.dyn.nic.fi [62.236.195.159]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA13777 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 06:40:56 -0400
Received: from localhost (localhost [127.0.0.1])
	by sculpcave (Postfix) with ESMTP
	id 3FB5D34D3B; Fri,  8 Oct 1999 19:04:00 +0300 (EEST)
Date: Fri, 8 Oct 1999 19:03:59 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
X-Sender: root@sculpcave.localdomain
To: =?iso-8859-1?Q?J=F6rn?= Nettingsmeier <nettings@folkwang.uni-essen.de>
Cc: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] multi-track audio files - what format ?
In-Reply-To: <37FE04E7.11C4CA2C@folkwang.uni-essen.de>
Message-ID: <Pine.LNX.4.10.9910081756280.663-100000@sculpcave.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by nerf.ulster.net id HAA31831
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 805610df7932e8b3ae01a9a8bf087673

On Fri, 8 Oct 1999, Jrn Nettingsmeier wrote:

> one file, many tracks interleaved:
[.. vs ...]
> one file per track:

I definitely prefer using separate tracks. Storing your 
tracks to separate, standard audio files just gives you
so much flexibility. 

- using external programs is easy
- transfering your project to a new environment is simple (for
  instance, I've recorded a lot of material using the 
  combination: FastTracker2 (dos) -> Cakewalk (win) -> 
  ecasound (effects, os/2 back then) -> Cakewalk)

Of course, using separate files is less efficient. I often 
have performance problems when mixing big projects on 
my p166mmx, but this isn't so serious, as I can easily submix 
already finished tracks.

There are of course exceptions. If you have to record many
high-quality tracks simultaniously, interleaving is the 
way to go. 

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav

From - Fri Oct  8 15:05:46 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA26793
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 13:16:56 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA07919 for linux-audio-dev-list; Fri, 8 Oct 1999 12:35:01 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA07916 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 12:34:54 -0400
Received: from linuxhost.localdomain (IDENT:root@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id SAA24907
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 18:30:05 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id UAA01360
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 20:30:45 +0200
From: Benno Senoner <sbenno@gardena.net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] low-latency patches getting into kernel 2.4 , seems official !
Date: Fri, 8 Oct 1999 20:17:00 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <99100820304502.00774@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 3465cc5df0f4fbaf7ce4615d7904ec02

Hello folks, good news:

today I sent the following mail to Ingo Molnar:  ( look at the reply at the
bottom)

-----------------------------------------------------------------
After I set up my low-latency page, there was a lot of interest in this topic,
I monitored the logs and the page gets about 100-300 hits per day , and
analyzing the logs, many request seems to come from multimedia-interested
companies. (set top boxes, DSP) , or linux-interested companies like
intel,ibm,hp , philips research labs etc etc.
The patch was downloaded about 300 times, which is sign
of lot of interest in this topic.
I received several mails from people about their happynes about
the latest scheduler developments.
One researcher at a german university told me he will even  use his linux alpha
box for doing highperf DSP stuff instead of dedicated hardware ! 

Actually many people asked me about when/if the low-latency features will get
folded into the kernel.

Maybe it would be very nice if one of you could give us some offcial statement
when/if the patches get included in the next release of the kernel or not.
I'm aware of the 2.3.18 feature freeze by Linus, does this mean that there is 
no chance to get the low-latency features into 2.4 ?
Does someone know how Linus stands to this ?

Many people are expecting the next linux kernel to be able to deal
with todays multimedia tasks on the desktop.
Especially Corel with their distro is pushing linux on desktop quite a bit.
I think Ingo's work is one of the keys which will enable highperf multimedia
on the Linux box, and if we have to wait for linux 2.6, we will miss a lot
of possibilities. (highperf multimedia software/hardware manufacturers are
already closely monitoring Linux, and with the patches Linux actually performs
much better than Win/Mac, and can deliver even comparable realtime performance
to BeOS.
And Yodaiken benchmarked the low-latency kernel and found no slowdown
compared to a stock kernel, as Ingo already claimed. 

 If you can make some offcial statement, please post it to linux-kernel
and CC me so that I can forward it to various webpages and mailinglist. 
---------------------------------------------------------------------

Ingos reply:
----------
On Fri, 08 Oct 1999, Ingo Molnar wrote:
> dont worry, i'll integrate the patch into 2.3. It's not a problem.
> 
> 	Ingo

-----------

Folks, seems that high performance  multimedia will be available  to EVERY
Linuxer with the release of kernel 2.4 in a couple of months.

Combine this with the release of easy-to-use desktop Linux-distros,
like Corel Linux etc. ,  and you get the most powerful free multimedia platform.

Isn't that exciting ?

For next year , I foresee very very much trouble for other desktop/multimedia
OSes.
:-)

regards,
Benno.

From - Sat Oct  9 02:52:50 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA14074
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 19:37:02 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA08566 for linux-audio-dev-list; Fri, 8 Oct 1999 19:07:22 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA08563 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 19:07:19 -0400
Received: from localhost.localdomain (d212-151-86-46.swipnet.se [212.151.86.46]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA20912; 
          Sat, 9 Oct 1999 01:02:40 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway
Date: Sat, 9 Oct 1999 00:14:11 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199910080150.VAA03039@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99100901092808.00442@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id BAA20912
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA14074
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3e4fed465c863851d3a9c269602caecf

On Fri, 08 Oct 1999, Paul Barton-Davis wrote:
> [ ... MIDI-based automation with the ALSA sequencer ... ]	
> 
> >The same can be done with an engine using a plug-in API with my event
> >system.  A sequencer could be either a plug-in or a client
> >application, and it could record anything that goes on in the
> >system. (That's the routing functionality that's one of all things I
> >worry about when trying to design an efficient even t system...) No
> >need for a special automated mixer (although one would be very nice
> >as a GUI) and *anything* could be automated. And it would be sample
> >accurate...
> 
> actually, i don't think this is quite true unless you're talking about
> RTLinux or special audio apps. userspace processes have a fundamental
> timing limit of 1/HZ seconds, unless they (1) run at RT priority and
> use the RTC to kick them periodically or (2) continually drive +
> monitor the status of a DAC of some kind.
> 
> the beauty of the ALSA sequencer is that it offers an extremely
> generic event router with a timing limit that is not subject to the
> same limits. Alas, this is a theoretical possibility right now, since
> even the kernel doesn't check the timer queue more than HZ times a
> second. However, add the UTIME patch, and the kernel can do flexibly
> scheduled stuff with microsecond resolution.

Of course there's no way to get kernel space real time performance with a user
space engine... As the ALSA sequencer is in kernel space, so would any other
solution have to be, at least if it's about *latency* - accuracy is completely
different, unless you're controlling something that doesn't support
timestamps...

But what would the ALSA sequencer automate then? In what way does it't timing
accuracy help? External MIDI devices won't benefit from better than ms accuracy.

> also, note that my point about automation was not that one would have
> a "specially automated mixer" - in fact, I meant *exactly* the
> opposite: an application can take the simple step of writing a
> Standard MIDI file as a record of all automation messages.

You could automate *both* MIDI devices and <insert the name we still
don't have here> plug-ins using the event system. Of course, unless the engine
is in kernel space, it would have to delegate the MIDI conversion out to some
other system - like the ALSA sequencer.

> why MIDI ?
> why not some more "evolved" event specification ?  99% of all
> available control surfaces use MIDI to do their thing. if you're doing
> this stuff with any seriousness, US$300 for a PC1600X is a fairly
> minimal investment in 16 physical faders. 

Using some other protocol internally in some areas of the system doesn't make
MIDI I/O impossible, does it...? :-)

> once you've got the MIDI file, the existence of MIDI playback tools
> *and* the ALSA sequencer allow anything to become automated *without*
> any special code: you just add the relevant sequencer port to the list
> of MIDI ports you select(2) on, and it all works like magic.

That's pretty cool, and it's already there, more or less. :-)

> yes, you could instead come up with a new event API and record the
> "happenings" in the application with it, and then arrange for a way to
> play it back. while you code it, we'll get on with using the ALSA
> sequencer :)

Well, I thought we were actually to *use* the plug-in API... One of the *BIG*
points with a buffered event system, IMO, is to use it for more than the
engine<->plug-in communication.

Besides, MIDI automation won't do for non-destructive hard disk editing, and if
there's one thing I hate, it's multiple similar systems that are supposed to
cooperate. (Reminds me of M$ style design... ;-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Oct  9 02:52:53 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA16610
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 19:59:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA08613 for linux-audio-dev-list; Fri, 8 Oct 1999 19:26:22 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA08610 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 19:26:20 -0400
Received: from someip.ppp.op.net (d-bm2-03.ppp.op.net [209.152.194.35]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id TAA24336 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 19:21:48 -0400 (EDT)
Message-Id: <199910082321.TAA24336@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: ALSA sequencer & PC1600X 
In-reply-to: Your message of "Fri, 08 Oct 1999 07:44:29 PDT."
             <19991008144429.25579.qmail@hyperreal.org> 
Date: Fri, 08 Oct 1999 19:22:03 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 3012d4040ecfaf8ceda1ca307f569c13

  [ Peavey PC1600X ]

>Ooooh!  I found this on the Peavey site..must have.  Any
>recommendations as to where to purchase it?  Also, do you know of any
>configuration gotchas like requiring Windows/Mac software for
>configuration?  As long as its all midi and documented I'll be happy.

its completely self-contained, completely documented and really,
really nice to work with. it took me 10 minutes to set it up to
substitute for the 16 MIDI-generating knobs on my K5000S, and most of
that was just the gruntwork of using a jog wheel for name entry. i'd
prefer a different font for the logos, but other than that, its great!
my next control surface will be a Mackie HUI, which is about 10x the
cost, and from what i read, the PC1600X will still have a role to
play. Make sure you check out jlcooper.com as well - they also have
some fairly nice MIDI control surfaces. They have a PDF brochure
there. actually, i think that synthzone.com has a whole page on MIDI
controllers - if this stuff interests you make sure to see the I-Cube:
this is, and here my age will show, "da bomb".

--p

From - Sat Oct  9 02:52:54 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA17842
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 20:09:07 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA08639 for linux-audio-dev-list; Fri, 8 Oct 1999 19:39:33 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA08636 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 19:39:31 -0400
Received: from someip.ppp.op.net (d-bm2-03.ppp.op.net [209.152.194.35]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id TAA25056 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 19:34:59 -0400 (EDT)
Message-Id: <199910082334.TAA25056@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway 
In-reply-to: Your message of "Sat, 09 Oct 1999 00:14:11 +0200."
             <99100901092808.00442@localhost.localdomain> 
Date: Fri, 08 Oct 1999 19:35:14 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3f210f345dcf35ba0807def093354c19

>Of course there's no way to get kernel space real time performance
>with a user space engine... As the ALSA sequencer is in kernel space,
>so would any other solution have to be, at least if it's about
>*latency* - accuracy is completely different, unless you're
>controlling something that doesn't support timestamps...

>But what would the ALSA sequencer automate then? In what way does
>it't timing accuracy help? External MIDI devices won't benefit from
>better than ms accuracy.

the scenario in which the sequencer helps is simple: suppose that
you're a program that is *not* currently generating samples and *not*
using the RTC, but basically asleep, doing a select(2) or poll(2) on a
whole set of various file descriptors. Our automation recording wants
us to wake up at a certain point and do something.

Currently, you can only get 20ms or so accuracy on this from user
space in the scenario I describe. If the ALSA sequencer can do
flexible time scheduling, then you can ensure that you will be woken
up at exactly the right moment.

What kind of program does this ? Well, certainly most audio applications
don't need this, because they have the DAC to provide a time sync
source. But pure MIDI apps don't have this, and so the sequencer is
very useful for them. Programs that typically don't continuously
output samples would also benefit from it.

Even something like the hdr mixer I'm working on, not having to think
about accurate timing but instead relying on the source of automation
info to ensure that I am delivered events at the right time makes the
code a lot simpler.

>Well, I thought we were actually to *use* the plug-in API... One of the *BIG*

I was jesting :)

>Besides, MIDI automation won't do for non-destructive hard disk
>editing, 

tell that to Mackie&Digidesign: the HUI and ProTools collaborate in
exactly this way (well, i don't know how exactly, because I don't know
whether ProTools stores the automation events as MIDI data or using
its own event format).
	  
>and if there's one thing I hate, it's multiple similar
>systems that are supposed to cooperate. (Reminds me of M$ style
>design... ;-)

agreed.

From - Sat Oct  9 02:52:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA18393
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 20:13:42 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA08657 for linux-audio-dev-list; Fri, 8 Oct 1999 19:42:29 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA08654 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 19:42:27 -0400
Received: from someip.ppp.op.net (d-bm2-03.ppp.op.net [209.152.194.35]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id TAA25354 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 19:37:56 -0400 (EDT)
Message-Id: <199910082337.TAA25354@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] multi-track audio files - what format ? 
In-reply-to: Your message of "Fri, 08 Oct 1999 20:40:42 EDT."
             <37FE8F0A.C33C0A3@alphalink.com.au> 
Date: Fri, 08 Oct 1999 19:38:11 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 632502157ef44a5b9c94978252dd1a2a

>There was talk of supporting this on linux-fsdevel.  They were going to
>make it so you can read() and write() a directory, like a normal file.
>Ted T'so called them "albods", from memory.
>I don't know what came of this.

over on linux-kernel, many people hate albods. the hate was so
profound that my reading of the debate was that they would die before
even being born.

>> I'm a little confused.  Actually a lot confused.  Isn't the default and
>> most often used case to read and write all tracks at once?
>
>Depends.  In a studio, each track is usually recorded separately, while
>all of the previously recorded tracks are played to the performer, to
>keep everything in sync.

Precisely. Or as a variant, one track is re-recorded, while leaving
all others untouched (and played back to the performer).

Remember: we're not talking about editing here - thats an entirely
different process. This is multitrack *recording*.

I think that Juhana has convinced me that separate files are the way
to go. I think that perhaps even multiple channels in any one file
might be a mistake too.

--p

From - Sat Oct  9 02:52:57 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA18568
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 20:15:04 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA08712 for linux-audio-dev-list; Fri, 8 Oct 1999 19:56:55 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA08709 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 19:56:53 -0400
Received: from someip.ppp.op.net (d-bm2-03.ppp.op.net [209.152.194.35]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id TAA26300 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 19:52:21 -0400 (EDT)
Message-Id: <199910082352.TAA26300@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc.
In-reply-to: Your message of "Fri, 08 Oct 1999 11:46:39 EDT."
             <37FE11DF.AE120910@cygnus.com> 
Date: Fri, 08 Oct 1999 19:52:36 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: cdbf38debbcbc160c7644cd48f47e912

>Yes, initially I thought I could do this w/ a user space client talking to
>ALSA, interfacing w/ the legacy app thru a pipe, since the pipe would appear
>as a device file to the app. Unfortunately, most of the apps I'm interested
>in both read and write to the raw midi interface.

First, any program that only does I/O to /dev/midi should be shot at
dawn. If it uses a user-selectable one of /dev/midiNN, it can live. 

In the meantime:

% su
Password: 
# cd /dev
# for devnum in 00 01 02 03
# do
#     mv midi${devnum} mididev${devnum}
#     mkfifo midififo${devnum}
#     ln -s midififo${devnum} midi${devnum}
# done
# rm midi
# ln -s midi midififo${yourchoice}
# ^D
%

To get back to the default state of affairs: then you just need a
small midirouting daemon that runs in the background, holds all
/dev/mididev* device files open, and forwards data to and from
/dev/midififo*. Note the inherent similarity to OMS here. I even wrote
such a small daemon last year, but I rarely use it anymore. It even
did channel splitting across ports, and I once had plans to do note
splits across ports as well (i.e. if (noteNum > N) send_to (portA)
else send_to (portB)). Fun stuff.

To get beyond the default state, create some more fifos, link them to 
/dev/midiNN, and leave it at that. Programs can open /dev/midi09, and
actually be talking to a pipe.

Alas, FIFO's don't work exactly like files, devices or sockets. If you
do the open...read and open...write sequences in the wrong order
and/or without the correct logic, you will get errors instead of
blocking. 

Also, the beauty of this kind of scheme is one of the things I have
against the ALSA lib API for raw MIDI devices. Anything that tries to
obscure or complicate the fact that a MIDI "port" is just a byte sink
and source is evil :) Thats why I never use the ALSA lib API for MIDI,
but just stick to regular Unix open/close/read/write on /dev/snd/midiCxxDyy

Seriously though, I doubt the success of Linux for MIDI until the kind
of facilities that OMS provides on the Mac exist *in the
kernel*. There are people (myself included) who feel uncomfortable
about having two context switches necessary to send MIDI data, have it
delivered, and then get on with what I'm doing. Its not clear to me if
the ALSA Sequencer can do all this, but it would be great if it could.

--p

From - Sat Oct  9 02:53:01 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA01356
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 22:27:48 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA08978 for linux-audio-dev-list; Fri, 8 Oct 1999 22:04:56 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA08972 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 22:04:53 -0400
Received: from localhost.localdomain (d212-151-38-133.swipnet.se [212.151.38.133]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id EAA25152; 
          Sat, 9 Oct 1999 04:00:18 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Jrn Nettingsmeier <nettings@folkwang.uni-essen.de>,
        linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] multi-track audio files - what format ?
Date: Sat, 9 Oct 1999 02:36:24 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <37FE04E7.11C4CA2C@folkwang.uni-essen.de>
MIME-Version: 1.0
Message-Id: <99100902473200.00599@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id EAA25152
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id WAA01356
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5e93811aa02ed581ea50b9bf6eee2c8a

On Fri, 08 Oct 1999, Jrn Nettingsmeier wrote:
> one file per track:
>  + easy offsetting, just add zeros at the beginning
>  + easy to move parts around
>  + tracks can be spread over different disks, thus speeding up disk
>     i/o.
>  - tracks will be read at differrent speeds depending on disk
>     geometry and other fs related things, so i'd expect this needs
>     larger buffers than interleaved files, thus greater latency. 
>     (does that make sense ?)

It does to some extent; N files means N head seeks/set of read buffers. That
is, you have to use bigger buffers (ie read more from each file at a time) to
keep seek overhead low.

However, you can *not* assume that the buffer size becomes irrelevant with a
single file. There is a low limit that depends on the file system, the drive
and other things. I'd guess you need some 3-6 tracks or so before the
difference justifies using bigger buffers than you'll need for reliability
anyway.

> it seems that the first way is more elegant to read from/write to in
> real time, while the latter is nicer for editing purposes.

That's about it, I guess. There's no such thing as a perfect solution...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Oct  9 02:52:46 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA28599
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 17:16:14 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA08371 for linux-audio-dev-list; Fri, 8 Oct 1999 16:47:50 -0400
Received: from mail.alphalink.com.au (mail.alphalink.com.au [203.24.205.7]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA08368 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 16:47:38 -0400
Received: from alphalink.com.au (IDENT:andrew@d03-as20-mel.alphalink.com.au [202.161.99.34]) by mail.alphalink.com.au (8.9.3/8.6.9) with ESMTP id GAA04914; Sat, 9 Oct 1999 06:42:56 +1000
Message-ID: <37FE8F0A.C33C0A3@alphalink.com.au>
Date: Fri, 08 Oct 1999 20:40:42 -0400
From: Andrew Clausen <clausen@alphalink.com.au>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.10 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: David Slomin <dgslomin@CS.Princeton.EDU>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] multi-track audio files - what format ?
References: <Pine.GSO.4.10.9910081024430.21000-100000@ux02.CS.Princeton.EDU>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 8cbef69c66bbedc6bff80bee1cf9b644

David Slomin wrote: 
> On NeXTStep, there was this convention, the name of which I forget, that a
> directory could be treated as a single file.  You'd name the directory
> with a file extension (ie: "multi-track-song1.mts") and each file in that
> directory would be equivalent to a chunk in an IFF file.  For the
> application that needed the multiple chunks, you'd enter the directory and
> access them like normal files, but for file management and distribution,
> you'd move the directory around as a whole.  I'd love to see that on
> Linux, as it would solve this problem and many others very cleanly.  The
> only required code changes would be in file managers (kfm, gmc, etc).

There was talk of supporting this on linux-fsdevel.  They were going to
make it so you can read() and write() a directory, like a normal file.
Ted T'so called them "albods", from memory.
I don't know what came of this.
 
> I'm a little confused.  Actually a lot confused.  Isn't the default and
> most often used case to read and write all tracks at once?

Depends.  In a studio, each track is usually recorded separately, while
all of the previously recorded tracks are played to the performer, to
keep everything in sync.

Andrew Clausen

From - Sat Oct  9 02:53:05 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA01335
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 22:27:42 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA08980 for linux-audio-dev-list; Fri, 8 Oct 1999 22:04:58 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA08976 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 22:04:55 -0400
Received: from localhost.localdomain (d212-151-38-133.swipnet.se [212.151.38.133]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id EAA25167; 
          Sat, 9 Oct 1999 04:00:20 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway
Date: Sat, 9 Oct 1999 02:52:23 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199910081437.KAA03841@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99100903213901.00599@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id EAA25167
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id WAA01335
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2a1b75eb9e3ce7c47f54cddc07f35cf4

On Fri, 08 Oct 1999, Paul Barton-Davis wrote:
> scrolling screens matter. if i want 64 channels. there is no way to
> *ever* fit them on the screen.

I don't think scrolling is the way to do it. Cakewalk is really getting on my
nerves at mixdown time for that very reason. (Well, then there's the
DirectKplode problem, but that's another story...) 30-50 tracks is just plain
h*ll to navigate that way, as you lose orientation as soon as you touch the
scroll bar. And scrolling any other way takes too long.

I have two ideas...

1) Add a "bird's eye" view, that clearly shows where on the virtual
   mixer you are. Problem: Would it actually help much? (The bird's eye
   view would be very small...)

2) Organize the mixer in groups, and actually *split* the mixer into
   one console for each group. It's now up to the user if he/she wants
   to simulate "the big console orientation problem" (making it worse
   through scrolling), or take advantage of the fact that the mixer is
   virtual.


> >KDE has already this kind of multitrack recorder.
> 
> well, thats an area i stay away from. the whole Qt thing just leaves a
> bizarre taste in my mouth,

Same here... I still use the desktop, though, as it's rather stable, and still
provides a better integrated desktop than GNOME currently does. GNOME is nice,
but it still has too many little problems that make me fire up a console to use
good ol' bash, and of course, mc. :-) (I still use mc. Have yet to see a
GUI/mouse based fm that doesn't just get in the way when doing more than two
operations in sequence...)

> and the idea that every application is part
> of this "big thing" leaves an even funnier taste.

Yeah... The desktop tools (file manager, some basic document viewers...) do
benefit a lot from the solid integration, but it should probably end there.
However, one of the reasons that I don't use GNOME for now, is that it has
problems with some applications + clipboard. KDE isn't perfect either, but it
currently works a lot better. One not very nice side effect of "freedom of
choice"... Oh, well.

> note that this is
> not even a GNOME application, just a Gtk-- one.
> 
> what is is called ? just so i can take a look :)


KHDRec, if it's the same one we're thinking of.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Oct  9 02:53:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA01340
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 22:27:45 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA08990 for linux-audio-dev-list; Fri, 8 Oct 1999 22:05:04 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA08984 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 22:05:00 -0400
Received: from localhost.localdomain (d212-151-38-133.swipnet.se [212.151.38.133]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id EAA25187; 
          Sat, 9 Oct 1999 04:00:21 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: David Slomin <dgslomin@CS.Princeton.EDU>, thudson@cygnus.com
Subject: Re: [linux-audio-dev] a new application underway
Date: Sat, 9 Oct 1999 03:26:49 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
References: <Pine.GSO.4.10.9910081058030.21000-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Message-Id: <99100903363302.00599@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id EAA25187
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id WAA01340
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2d5194a77b03e12326e7adcab163f227

On Fri, 08 Oct 1999, David Slomin wrote:
> If this happier view of the world is impractical to add to ALSA at this
> point, we could write an ALSA midi port driver (once, so we'll not have to
> deal with the pain of driver programming again) similar to the "MIDI Thru"
> drivers available for Windows MME.  These screwy drivers act like fifos
> which other MIDI apps (not drivers) can access the way I described for
> NetMIDI.  Once you had this, you wouldn't write your softsynth as a
> driver, but as a regular app that listened on the Thru driver's port. The
> drawback here is that you have a strictly limited number of Thru "cables".

Here I come again! *hehe*

*THIS* is about what I want to do with the event system of the plug-in API.
Plug-ins as well as clients (applications) would use the same low level protocol
for the event handling. The "central engine" in the most basic form, would
just handle the event and stream connections, and not host plug-ins. That part
should be in the kernel, obviously, as that makes better real time performance
and less expensive IPC possible.

The whole point is using the *same* API parts everywhere. That makes it easier
to move code around, and it eliminates expensive translation between
incompatible protocols.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Oct  9 02:52:59 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA01334
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 22:27:42 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA09008 for linux-audio-dev-list; Fri, 8 Oct 1999 22:05:16 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA09005 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 22:05:12 -0400
Received: from localhost.localdomain (d212-151-38-133.swipnet.se [212.151.38.133]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id EAA25209; 
          Sat, 9 Oct 1999 04:00:23 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Andrew Clausen <clausen@alphalink.com.au>,
        David Slomin <dgslomin@CS.Princeton.EDU>
Subject: Re: [linux-audio-dev] multi-track audio files - what format ?
Date: Sat, 9 Oct 1999 03:44:26 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <37FE8F0A.C33C0A3@alphalink.com.au>
MIME-Version: 1.0
Message-Id: <99100903500903.00599@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id EAA25209
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id WAA01334
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7b4a7e53b2e53c1dcb57ab695def5ff3

On Sat, 09 Oct 1999, Andrew Clausen wrote:
> > I'm a little confused.  Actually a lot confused.  Isn't the default and
> > most often used case to read and write all tracks at once?
> 
> Depends.  In a studio, each track is usually recorded separately, while
> all of the previously recorded tracks are played to the performer, to
> keep everything in sync.

That's what I do most of the time in my home studio as well... Except when
recording the sequenced MIDI tracks for the final mixdown - then the playback
can be disabled to decrease the hard drive stress.

However, percussion comes into mind... That can be quite a few mics, and of
course, you want them on separate tracks for maximum control.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Oct  9 02:53:03 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA01362
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 22:27:49 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA08989 for linux-audio-dev-list; Fri, 8 Oct 1999 22:05:03 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA08982 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 22:04:59 -0400
Received: from localhost.localdomain (d212-151-38-133.swipnet.se [212.151.38.133]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id EAA25215; 
          Sat, 9 Oct 1999 04:00:24 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway
Date: Sat, 9 Oct 1999 03:53:38 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199910082334.TAA25056@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99100904061704.00599@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id EAA25215
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id WAA01362
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ce7a1b9eead341d49ce0dead931d1db4

On Sat, 09 Oct 1999, Paul Barton-Davis wrote:
[...ALSA sequencer...]
> What kind of program does this ? Well, certainly most audio applications
> don't need this, because they have the DAC to provide a time sync
> source. But pure MIDI apps don't have this, and so the sequencer is
> very useful for them. Programs that typically don't continuously
> output samples would also benefit from it.

Ok, very valid point. (I keep forgetting that you're having trouble waking up
in time out there... :-)

[...]
> >Besides, MIDI automation won't do for non-destructive hard disk
> >editing, 
> 
> tell that to Mackie&Digidesign: the HUI and ProTools collaborate in
> exactly this way (well, i don't know how exactly, because I don't know
> whether ProTools stores the automation events as MIDI data or using
> its own event format).

AFAIK, they use other means of triggering audio clips and non-destructive
editing stuff that needs to be sample accurate... I don't like that
distinction. *Every* event should be possible to automate with sample accuracy,
or the design has a restriction that will cause trouble sooner or later. Users
find new tricks, and I see no reason forcing them to become hackers and hack
their own plug-ins just to get around that kind of limitations.

Do Mackie and Digidesign have The Ultimate Solution? Is Microsoft The OS
design authority...?


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Oct  9 02:53:07 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA06432
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 23:13:47 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA09178 for linux-audio-dev-list; Fri, 8 Oct 1999 22:53:28 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA09175 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 22:53:25 -0400
Received: from someip.ppp.op.net (d-bm2-03.ppp.op.net [209.152.194.35]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id WAA06901 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 22:48:53 -0400 (EDT)
Message-Id: <199910090248.WAA06901@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway 
In-reply-to: Your message of "Sat, 09 Oct 1999 02:52:23 +0200."
             <99100903213901.00599@localhost.localdomain> 
Date: Fri, 08 Oct 1999 22:49:10 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1bca441dab1db62b63de435f8e71b661

	[ ... arranging mixers ... ]

Creamware went for a good solution I think, that is similar to your
(2). They effectively use a "tab notebook" (though it doesn't have
that appearance), and group things into:

     2 sets of 8 channel strips
     1 sets of 16 busses
     2 sets of 8 "mixes" - don't know what these are

Then the aux send/returns and the master out controls are always
visible on the right hand side. For each combination, everything that
should be visible is always visible.

This is my plan too. I think its very simple to do this with
GTK. Right now, I have tabbed folders for Strips and Buses - I just
have to dynamically create new ones as the number of strips or busses
gets to large (and reset the labels to indicate the actual range).

--p

From - Sat Oct  9 02:53:08 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA07767
	for <slinkp@ulster.net>; Fri, 8 Oct 1999 23:26:17 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA09220 for linux-audio-dev-list; Fri, 8 Oct 1999 23:06:25 -0400
Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA09217 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 8 Oct 1999 23:06:21 -0400
Received: from hendrix (scratchy77.zip.com.au [61.8.12.205])
	by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id MAA10429
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 12:45:36 +1000 (EST)
Message-ID: <37FEB012.2E557589@zip.com.au>
Date: Sat, 09 Oct 1999 13:01:45 +1000
From: Erik de Castro Lopo <erikd@zip.com.au>
Organization: Indonesian murders out of East Timor NOW!
X-Mailer: Mozilla 3.04Gold (X11; I; Linux 2.2.12 i586)
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] multi-track audio files - what format ?
References: <199910082337.TAA25354@renoir.op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4eabca5dcb5678d0c65ac2dc7c27e7b2

Paul Barton-Davis wrote:

<snip>

> Precisely. Or as a variant, one track is re-recorded, while leaving
> all others untouched (and played back to the performer).
> 
> Remember: we're not talking about editing here - thats an entirely
> different process. This is multitrack *recording*.
> 
> I think that Juhana has convinced me that separate files are the way
> to go. I think that perhaps even multiple channels in any one file
> might be a mistake too.

I have a little knowledge of one very high-end disk recorder the 
Fairlight MFX3+. This is a machine which is capable of simulataneous
24 track playback and record. All editing is non-destructive until
it is "committed".

It keeps all tracks (currently up to 24) and edit list information in 
one file. The file has a header followed by chunks of single track 
audio. These chunks are of the order of 128k and are read off disk into
the playback hardware in the same 128k chunks. 

I anyone is interested in this kind of disk recorder performance they
should look at how the Fairlight does it as they had this capability 
in 1994 when disks and processors were a lot slower.

Erik
-- 
+-------------------------------------------------+
     Erik de Castro Lopo     erikd@zip.com.au
+-------------------------------------------------+
"Two hands working can do more than a thousand clasped in prayer." 
-- anonymous

From - Sat Oct  9 05:13:24 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id EAA24948
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 04:25:05 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id EAA13618 for linux-audio-dev-list; Sat, 9 Oct 1999 04:05:37 -0400
Received: from bashir.belgium.eu.net (bashir.Belgium.EU.net [193.74.208.147]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA13615 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 04:05:34 -0400
Received: from (adial088.liege.eunet.be [195.207.174.88])
	by bashir.belgium.eu.net  with SMTP id KAA08715 
	for <linux-audio-dev@ginette.musique.umontreal.ca>;
	Sat, 9 Oct 1999 10:00:57 +0200 (MET DST)
Subject: [linux-audio-dev] non-destructive editing
From: Benjamin GOLINVAUX <golinvaux@benjamin.net>
Reply-To: Benjamin GOLINVAUX <golinvaux@benjamin.net>
Message-ID: <0003566e187af433_mailit@relay.eunet.be>
Date: Sat, 09 Oct 1999 09:56:27 +0200
X-Mailer: BeatWare Mail-It 2.0.3
X-BeOS-Platform: Intel or clone
X-Priority: 3 (Normal)
To: linux-audio-dev@ginette.musique.umontreal.ca
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: be0fd01ccd9deca6dc804c16b0f1d041

Hi,

I want to implement a non-destructive editing app (basic operations : cut, 
copy, paste, process) and
I thought of keeping consecutive editing chunks in different files, in order 
to be able to undo any number
of actions. Then, I read that Fairlight MFX3, which is a rather old (1994) 
machine, uses chunks of 128K inside a _single_ file...

Furthermore, I would like to be able to MOVE parts of one sound to another, 
possibly on another track,
which makes the non-destructive stuff complex (I certainly don't wanna 
duplicate data until necessary).

What's your opinion on the tradeoffs and advantages of both methods ? I don't 
wanna start with something I could regret later...

Thanks.



Benjamin-
(linuxalsaingospatchrulez)









From - Sun Oct 10 22:31:22 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA31079
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 06:55:54 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA13757 for linux-audio-dev-list; Sat, 9 Oct 1999 06:18:02 -0400
Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA13754 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 06:17:58 -0400
Received: from hendrix (scratchy76.zip.com.au [61.8.12.204])
	by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id TAA22189
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 19:57:08 +1000 (EST)
Message-ID: <37FF153D.191A4A03@zip.com.au>
Date: Sat, 09 Oct 1999 10:13:17 +0000
From: Erik de Castro Lopo <erikd@zip.com.au>
Organization: Indonesian murders out of East Timor NOW!
X-Mailer: Mozilla 3.04Gold (X11; I; Linux 2.2.12 i586)
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] non-destructive editing
References: <0003566e187af433_mailit@relay.eunet.be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 70121b8c45f3d415c9af7ce0079b7ca4

Benjamin GOLINVAUX wrote:
> 
> Hi,
> 
> I want to implement a non-destructive editing app (basic operations : cut,
> copy, paste, process) and
> I thought of keeping consecutive editing chunks in different files, in order
> to be able to undo any number
> of actions. Then, I read that Fairlight MFX3, which is a rather old (1994)
> machine, uses chunks of 128K inside a _single_ file...
> 
> Furthermore, I would like to be able to MOVE parts of one sound to another,
> possibly on another track,
> which makes the non-destructive stuff complex (I certainly don't wanna
> duplicate data until necessary).
> 
> What's your opinion on the tradeoffs and advantages of both methods ? I don't
> wanna start with something I could regret later...

The only advice I can give is to design an programming interface that you
feel comfortable with, make it a library and the mess with the implementation
behind the programming interface until it works to your satisfaction.

Erik
-- 
+-------------------------------------------------+
     Erik de Castro Lopo     erikd@zip.com.au
+-------------------------------------------------+
Windows NT : An evolutionary dead end.

From - Sun Oct 10 22:31:24 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA31598
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 07:08:06 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA13796 for linux-audio-dev-list; Sat, 9 Oct 1999 06:43:07 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA13792 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 06:43:04 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46901AbPJIKiG>; Sat, 9 Oct 1999 13:38:06 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <0003566e187af433_mailit@relay.eunet.be> (message from Benjamin
	GOLINVAUX on Sat, 09 Oct 1999 09:56:27 +0200)
Subject: Re: [linux-audio-dev] non-destructive editing
Message-Id: <19991009103813Z46901-563+87@nic.funet.fi>
Date:   Sat, 9 Oct 1999 13:38:06 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c4c50b8bd67e32d9d4baf7fe35add133

>From:   Benjamin GOLINVAUX <golinvaux@benjamin.net>
>
>I thought of keeping consecutive editing chunks in different files, in order 

Yep, that is the way my system is doing it: each time a new audio segment
is needed to store the result of effect, we create a new file.

>of actions. Then, I read that Fairlight MFX3, which is a rather old (1994) 
>machine, uses chunks of 128K inside a _single_ file...

I'm really waiting a full explanation about it. It might be that Fairlight
has only some layer over the disk which has nothing to do with audiofiles.

Maybe Fairlight uses some specially formatted disk. By the way, what really
happens when we seek and replace data on a file? Will the new data be written
to the same physical location on the disk? If so, Fairlight maybe wants
to know always where the new data will be located.

I think we should really forget the one audiofile unless it is proven to be
useful. If data is physically rewritten to the same place on the disk,
then we may use the Lucasfilm's system to order requests with respect to the
shortests path through the disk surface. (I scanned the paper only for
educational/research purposes: "http://www.funet.fi/~kouhia/abbott.tar".)

>Furthermore, I would like to be able to MOVE parts of one sound to another, 
>possibly on another track, which makes the non-destructive stuff complex

You change the editlist/playlist only. No audio data is duplicated or moved.
(The complexity comes from elsewhere :-)

>What's your opinion on the tradeoffs and advantages of both methods?

You're comparing apples and oranges. Editlist is for fast non-destructive
editing. Disk files are for storing the audio data. If we keep all
audio data in one file, we have to come up with our own "file system"
for sure.

Yours,

Juhana

From - Sun Oct 10 22:31:27 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id IAA05466
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 08:40:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA13927 for linux-audio-dev-list; Sat, 9 Oct 1999 08:20:40 -0400
Received: from sculpcave (ppp-15.wakkanet.fi [194.157.35.223]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA13924 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 08:20:35 -0400
Received: from localhost (localhost [127.0.0.1])
	by sculpcave (Postfix) with ESMTP
	id B6C6534D3D; Sat,  9 Oct 1999 14:49:38 +0300 (EEST)
Date: Sat, 9 Oct 1999 14:49:38 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
X-Sender: root@sculpcave.localdomain
To: Paul Barton-Davis <pbd@Op.Net>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway 
In-Reply-To: <199910090248.WAA06901@renoir.op.net>
Message-ID: <Pine.LNX.4.10.9910091429480.733-100000@sculpcave.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 665cd7dfa0310d4a4a55c7ed86022053

On Fri, 8 Oct 1999, Paul Barton-Davis wrote:

> Creamware went for a good solution I think, that is similar to your
> (2). They effectively use a "tab notebook" (though it doesn't have
> that appearance), and group things into:
[...] 
>      2 sets of 8 channel strips
>      1 sets of 16 busses
>      2 sets of 8 "mixes" - don't know what these are

I understand that to get Windows/Mac audio people interested in 
Linux we need to have similar (looking) programs. Still, am I 
the only one who thinks imitating hw-mixer interfaces is not
the best way to go? 

In theory, virtual mixers are easy to use, as all audio people 
know how hw-mixers work. But in reality, if you don't have 
a full-blown MIDI-console controlling your virtual mixer, 
these interfaces are really cumbersome.

I personally find it easier to edit my mix-setup with emacs
than to use these GUI-mixers. ;)

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav

From - Sun Oct 10 22:31:28 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA17623
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 10:50:43 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA14205 for linux-audio-dev-list; Sat, 9 Oct 1999 10:27:36 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA14202 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 10:27:34 -0400
Received: from someip.ppp.op.net (d-bm3-07.ppp.op.net [209.152.194.71]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id KAA05235 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 10:22:59 -0400 (EDT)
Message-Id: <199910091422.KAA05235@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway 
In-reply-to: Your message of "Sat, 09 Oct 1999 14:49:38 +0300."
             <Pine.LNX.4.10.9910091429480.733-100000@sculpcave.localdomain> 
Date: Sat, 09 Oct 1999 10:23:22 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f861dd3aaead8490e80c2da5ea8ce4c2

>I understand that to get Windows/Mac audio people interested in 
>Linux we need to have similar (looking) programs. Still, am I 
>the only one who thinks imitating hw-mixer interfaces is not
>the best way to go? 
>
>In theory, virtual mixers are easy to use, as all audio people 
>know how hw-mixers work. But in reality, if you don't have 
>a full-blown MIDI-console controlling your virtual mixer, 
>these interfaces are really cumbersome.
>
>I personally find it easier to edit my mix-setup with emacs
>than to use these GUI-mixers. ;)

software under Linux gets written because someone wants to scratch an
itch. I have an itch: a better live multitrack HDR system. I also have
a PC1600X with 16 physical faders+16 buttons. Therefore, I am quite
happy to develop something that utilizes them, even if its not the
best solution for everyone.

the same observation about the UI metaphors has been made about the
patch cords in Quasimodo. I would be happy to come up with something
else if someone could point to me the appropriate metaphor(s). But I
haven't seen it yet, and so I am going with a set of metaphors (fader
strips, buses, inserts, etc. for hdr; patch cords, racks, sockets for
quasimodo) that work very well in the physical realm.

note that hdr doesn't do anything to alter your mix-setup. it doesn't
touch the hardware mixers in your system. if you use a cmdline utility
or some emacs mode to do that, please continue to do so. i just don't
happen to think that the tasks of dealing with inserts, bus routing,
signal level display, input/output routing, pan control etc. are
particularly appropriate for a non-GUI system, and importantly, none
of these apply when dealing with the majority of h/w mixers on current
soundcards.

however, just like quasimodo, hdr has a complete firewall between the
mixing engine and the interface. you could easily build a text-based
UI for it, if you had a particular metaphor in mind.

--p

From - Sun Oct 10 22:31:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA18948
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 11:03:27 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA14234 for linux-audio-dev-list; Sat, 9 Oct 1999 10:44:27 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA14231 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 10:44:25 -0400
Received: from someip.ppp.op.net (d-bm3-07.ppp.op.net [209.152.194.71]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id KAA06060 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 10:39:51 -0400 (EDT)
Message-Id: <199910091439.KAA06060@renoir.op.net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] API design again [code] 
In-reply-to: Your message of "Fri, 08 Oct 1999 01:58:24 +0200."
             <99100803052505.00471@localhost.localdomain> 
Date: Sat, 09 Oct 1999 10:40:15 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 16676b2f7077b8a470e7f432f3c186fb

>typedef unsigned int event_code_t;
>#define EV_CLASS_MASK    0xff000000 /* EVC_SYSTEM, EVC_CONTROL,... */
>#define EV_FLAGS_MASK    0x00ff0000 /* EVF_REQUEST, EVF_REPLY... */
>#define EV_KIND_MASK     0x0000ffff /* Exactly what event is this? */
>
>struct event_t;
>
>struct event_port_t {
>	qm_heap_t		*heap;		/* For dynamic allocation */
>	event_t			*events;	/* First event */
>};
>
>struct event_t {
>	event_t			*next;
>	event_time_t		time;
>	event_code_t		code;		/* What is this? */
>	int			size;		/* Number of data bytes */
>};

>Nice, simple, and perhaps the extra copying doesn't make much
>difference, considering the added complexity when trying to avoid it?
>After all, events ar e supposed to be pretty small most of the
>time... And moving pointers around is data copying as well.

i think you're going to be missing something pretty critical, and
something much more expensive that any of this data
copying/conditional stuff you're worrying about.

where do the events come from ? that is to say, in a multi-threaded
system, what actually allocates, deallocates, and otherwise sets up
event_t's for their use in the API ?

if its the engine thread itself, how do you get events delivered to
it? i see two possibilities, both of them bad.

  1) you're imagining that, external "h/w" events (e.g. MIDI i/o, GUI
     events, etc) get handled by a plugin run by the engine thread. 
     In the case of MIDI-like stuff, this gets rid of sample accuracy,  
     since we can't notice the event till we execute the plugin, which
     happens once per control cycle. In the case of GUI stuff, its
     even worse, since at least one well known and widely utilized GUI 
     system (X Window) isn't (properly) multithreaded, and you will crash.

  2) h/w-driven events get noticed by other threads, and are then
     delivered to the engine thread somehow. this seems to imply some
     wholly different event-type-specific-API. seems like a bad idea,
     given that this event system is supposed to be generic.

So, it seems likely to me that we're going to need to be able get hold
of event_t's from multiple threads. In that case, how do you ensure
atomicity on the *next pointer, and on *heap ?

if qm_thread_t is actually as simple as you propose, you can't use
lock free queues, and likewise for the event_t *next pointer.

so somewhere in there you're going to have one or more locks that need
to be taken, and the cost of this will far outweigh the other stuff
you're worried about.

or have i missed something fundamental and obvious again ? :)

--p




From - Sun Oct 10 22:31:31 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA19657
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 11:10:19 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA14256 for linux-audio-dev-list; Sat, 9 Oct 1999 10:50:58 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA14252 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 10:50:56 -0400
Received: from someip.ppp.op.net (d-bm3-07.ppp.op.net [209.152.194.71]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id KAA06355 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 10:46:21 -0400 (EDT)
Message-Id: <199910091446.KAA06355@renoir.op.net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] API design again 
In-reply-to: Your message of "Thu, 07 Oct 1999 22:38:29 +0200."
             <99100723262600.00471@localhost.localdomain> 
Date: Sat, 09 Oct 1999 10:46:45 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d871e09269ceb19dd51161520e343bd9

>> Clearly, a plugin must still be able to handle state changes. But the
>> code to do that will, in most cases, simple be resetting variables,
>> setting flags, etc. This is quite distinct from the task done by
>> process(). If an event generates or actually contains data to be
>> processed, then it goes into the plugin via process(). If it merely
>> tells us about a state change ("MIDI NoteOn", "GUI says value shifted
>> to 0.92", etc.), then the plugin gets told via (we'll call it ...)
>> notify().
>
>...but how would that be done if events are to be processed by another
>callback? It's all or nothing here; no point in moving *some* events out of
>process().

a plugin will almost never be just a function call. it will have some
state that goes with it. the other callback "process_events()"
understands how to parse the events and manipulate the state data. 

one thing i prefer about this approach is that it enforces cleaner
conceptual thinking on the part of a plugin designer. the process()
call is responsible for generating data on the basis of the current
state and the amount of data called for; the process_events() call is
responsible for mapping from the event types floating around in the
system to the internal state of the plugin.

this seems like a big win to me. 

--p

From - Sun Oct 10 22:31:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA25643
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 12:13:05 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA14358 for linux-audio-dev-list; Sat, 9 Oct 1999 11:50:24 -0400
Received: from www.tomy.net (www.tomy.net [209.186.149.104]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA14355 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 11:50:22 -0400
From: thudson@cygnus.com
Received: from cygnus.com (IDENT:thudson@jimi.tomy.net [192.168.1.2])
	by www.tomy.net (8.9.3/8.9.3) with ESMTP id LAA32706;
	Sat, 9 Oct 1999 11:45:47 -0400
Message-ID: <37FF6367.5CD59C54@cygnus.com>
Date: Sat, 09 Oct 1999 11:46:47 -0400
Organization: Cygnus Solutions
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Barton-Davis <pbd@Op.Net>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc.
References: <199910082352.TAA26300@renoir.op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 31495d86eb94bd6f21cb94445dd287df

Paul Barton-Davis wrote:
>
> First, any program that only does I/O to /dev/midi should be shot at
> dawn. If it uses a user-selectable one of /dev/midiNN, it can live.
>
One specific app I had in mind was KeyKit. While it does allow you to
specify a device file, it expects to be able to read and write from
this single device.  Unless linux pipes are different from standard
unix ones, they can only be opened for read or write. It would be 
nice if apps let you specify a different device file for input and 
output, but the last time I looked at the KeyKit sources (it's been 
a while),  it would require some work to do this. 


> To get back to the default state of affairs: then you just need a
> small midirouting daemon that runs in the background, holds all
> /dev/mididev* device files open, and forwards data to and from
> /dev/midififo*. Note the inherent similarity to OMS here. I even wrote
> such a small daemon last year, but I rarely use it anymore. It even
> did channel splitting across ports, and I once had plans to do note
> splits across ports as well (i.e. if (noteNum > N) send_to (portA)
> else send_to (portB)). Fun stuff.
>
Something similar to this is a pet project for me. Rather than putting
the intelligence in every app to deal with ALSA details, I would like to
have an ALSA kernel client w/ a gui app as a controller that would allow
me to specify the routing between oblivious apps. However, I tend to 
think of more fine-grained routing than ports. From a users perspective
it would be nicer to specify:

External keybord => MidiAppegiator => MidiEcho => Sequencer:Track 1 =>
 External Synth (responding on channel 5)

External Drum Pad => KetKit => CSound

Rather than, let's see, my keyboard is set to channel one and is 
connected to the first port of my second Midi card. I need to set
my MidiArpeggiator,MidiEcho, and Sequencer Track one to receive on 
channel one and output on channel 5 of the third port of my first midi
card...

Applets like MidiArpegiator of MidiEcho would be simpler to write
if they completely ignored channels and relied on user routing.
The routing app would "know" that the keyboard was set to channel
one and attached to midiC1D0:channel 1, and my external synth was
attached to midiC0D2: channel 5.

Enhance this with a nice graphical app that had a icon tray that would
allow drag and drop onto a canvas (launching apps when necessary), with
routing specified similar to Quasimodo with cabling. I drag and drop the
keyboard icon, the MidiArpegiator icon, connect them, etc.

> Also, the beauty of this kind of scheme is one of the things I have
> against the ALSA lib API for raw MIDI devices. Anything that tries to
> obscure or complicate the fact that a MIDI "port" is just a byte sink
> and source is evil :) Thats why I never use the ALSA lib API for MIDI,
> but just stick to regular Unix open/close/read/write on /dev/snd/midiCxxDyy
> 
> Seriously though, I doubt the success of Linux for MIDI until the kind
> of facilities that OMS provides on the Mac exist *in the
> kernel*. There are people (myself included) who feel uncomfortable
> about having two context switches necessary to send MIDI data, have it
> delivered, and then get on with what I'm doing. Its not clear to me if
> the ALSA Sequencer can do all this, but it would be great if it could.
> 
Yes. In my above scheme, MidiArpegiator and MidiEcho are simple plugin
applets. I just wonder about debugging such applets if I made them
alsa kernel clients. However, if I could find a nice abstraction for the 
building blocks of things like arpegiator and echo, perhaps a limited
set of primitives could be written and debugged once, and be combined
in unlimited ways by the user.

Thomas

From - Sun Oct 10 22:31:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA26934
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 12:22:52 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA14371 for linux-audio-dev-list; Sat, 9 Oct 1999 11:59:11 -0400
Received: from www.tomy.net (www.tomy.net [209.186.149.104]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA14368 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 11:59:08 -0400
From: thudson@cygnus.com
Received: from cygnus.com (IDENT:thudson@jimi.tomy.net [192.168.1.2])
	by www.tomy.net (8.9.3/8.9.3) with ESMTP id LAA32717;
	Sat, 9 Oct 1999 11:54:31 -0400
Message-ID: <37FF6573.2290BA63@cygnus.com>
Date: Sat, 09 Oct 1999 11:55:31 -0400
Organization: Cygnus Solutions
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: David Olofson <audiality@swipnet.se>
CC: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway
References: <199910081437.KAA03841@renoir.op.net> <99100903213901.00599@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2b7aa50c881995018c6c7297140ff468

David Olofson wrote:
> 
> On Fri, 08 Oct 1999, Paul Barton-Davis wrote:
> > scrolling screens matter. if i want 64 channels. there is no way to
> > *ever* fit them on the screen.
> 
> I don't think scrolling is the way to do it. Cakewalk is really getting on my
> nerves at mixdown time for that very reason. (Well, then there's the
> DirectKplode problem, but that's another story...) 30-50 tracks is just plain
> h*ll to navigate that way, as you lose orientation as soon as you touch the
> scroll bar. And scrolling any other way takes too long.
> 
There was an interesting file manager on the SGI that had a slider that
allowed one to zoom in and out of the view. I think the now defunct
Fresco allowed similar transformations of widgets. They widgets were
still active and usable in their shrunken state. There was an example
of a scaled and rotated copy of a drawing program pasted in another
copy of itself. The pasted copy was still fully functional.

Thomas

From - Sun Oct 10 22:31:43 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA28622
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 12:41:08 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA14425 for linux-audio-dev-list; Sat, 9 Oct 1999 12:21:15 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA14422 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 12:21:13 -0400
Received: from someip.ppp.op.net (d-bm3-07.ppp.op.net [209.152.194.71]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id MAA10749; Sat, 9 Oct 1999 12:16:32 -0400 (EDT)
Message-Id: <199910091616.MAA10749@renoir.op.net>
To: thudson@cygnus.com
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc. 
In-reply-to: Your message of "Sat, 09 Oct 1999 11:46:47 EDT."
             <37FF6367.5CD59C54@cygnus.com> 
Date: Sat, 09 Oct 1999 12:16:56 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 27b415d0f70bbddc4db1e07db468f49c

>One specific app I had in mind was KeyKit. While it does allow you to
>specify a device file, it expects to be able to read and write from
>this single device.  Unless linux pipes are different from standard
>unix ones, they can only be opened for read or write. It would be 
>nice if apps let you specify a different device file for input and 
>output, but the last time I looked at the KeyKit sources (it's been 
>a while),  it would require some work to do this. 

You general point is well taken - pipes are not the same as a file.

OTOH, If you want my patches to fix KeyKit to use different devices
for input and output, let me know. I did them a year and half back
precisely to support the use of FIFO's. I can't remember if I ever
sent them to Tim, but I should.

--p

From - Sun Oct 10 22:31:47 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA31302
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 13:08:11 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA14533 for linux-audio-dev-list; Sat, 9 Oct 1999 12:48:35 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA14530 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 12:48:33 -0400
Received: from someip.ppp.op.net (d-bm3-07.ppp.op.net [209.152.194.71]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id MAA12205 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 12:43:58 -0400 (EDT)
Message-Id: <199910091643.MAA12205@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: timing issues in a client/server enviroment 
In-reply-to: Your message of "Sat, 09 Oct 1999 19:55:04 +0200."
             <99100920201100.00807@linuxhost.localdomain> 
Date: Sat, 09 Oct 1999 12:44:23 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: e57aac4c49b4329382d688c900b322ec

>Are there any valid reasons to NOT adopt my proposed audio
>client/server model ?  By using sharedmen / efficient IPC, we could
>even run many low-latency apps simultaneously with only little
>overhead.

As long as its clearly understood that this is not going to work like
Windoze, where the engine is part of the OS, then I think this is
fine. What I mean by this is that I don't want to see a system like
esd created, where its author(s) believe that its going to run all the
time and that all applications should use it. Instead, I want a system
set up in which *any* application might potentially be the "engine"
addressed by the API. That means some kind of registration system, but
if we use shmem, then using a well-known key for the shmem segment
will take care of that.

Specifically, I want people to be able to use a variety of different
applications that might provide the services advertised by the API;
the situation with GNOME and KDE where there is "standard" not just in
terms of an API (and runtime library) but also the actual applications
that must be running is something I don't wish to support. It might be
useful for people who need handholding with their desktop, and want
their "you have mail" messages playing back while they listen to a
real audio clip. But its not OK for those of us who want to do more
dedicated and serious audio work.

So yes, I think the development of a standard API, a library, and one
or more sample implementations is a great idea, but please don't
anyone go off and think they are writing "the Linux Sound System".

>I think kernel space belongs mainly to PCM/Midi driver, and maybe
>some eventrouter which has to be well tested and crashproof.

Agreed.

--p

From - Sun Oct 10 22:31:48 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA31305
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 13:08:12 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA14548 for linux-audio-dev-list; Sat, 9 Oct 1999 12:50:26 -0400
Received: from www.tomy.net (www.tomy.net [209.186.149.104]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA14545 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 12:50:24 -0400
From: thudson@cygnus.com
Received: from cygnus.com (IDENT:thudson@jimi.tomy.net [192.168.1.2])
	by www.tomy.net (8.9.3/8.9.3) with ESMTP id MAA00345;
	Sat, 9 Oct 1999 12:45:50 -0400
Message-ID: <37FF717A.4C31BF72@cygnus.com>
Date: Sat, 09 Oct 1999 12:46:50 -0400
Organization: Cygnus Solutions
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Barton-Davis <pbd@Op.Net>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc.
References: <199910091616.MAA10749@renoir.op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4e09460f863801c6483b3087beba6962

Paul Barton-Davis wrote:

> OTOH, If you want my patches to fix KeyKit to use different devices
> for input and output, let me know. I did them a year and half back
> precisely to support the use of FIFO's. I can't remember if I ever
> sent them to Tim, but I should.
> 
Yes. Thanks, that would be great.

Thomas

From - Sun Oct 10 22:31:50 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA00807
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 13:29:01 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA14607 for linux-audio-dev-list; Sat, 9 Oct 1999 13:08:20 -0400
Received: from gate.suse.cz (perex.cb.cesnet.cz [194.212.165.105]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA14603 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 13:08:16 -0400
Received: from localhost (perex@localhost)
	by gate.suse.cz (8.8.8/8.8.8) with ESMTP id TAA10097;
	Sat, 9 Oct 1999 19:03:02 +0200
X-Authentication-Warning: gate.suse.cz: perex owned process doing -bs
Date: Sat, 9 Oct 1999 19:03:02 +0200 (MEST)
From: Jaroslav Kysela <perex@suse.cz>
To: thudson@cygnus.com
cc: Paul Barton-Davis <pbd@Op.Net>,
        Linux Audio Development Mailing list <linux-audio-dev@ginette.musique.umontreal.ca>,
        ALSA development <alsa-devel@alsa-project.org>
Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc.
In-Reply-To: <37FF6367.5CD59C54@cygnus.com>
Message-ID: <Pine.LNX.4.05.9910091841010.9771-100000@gate.suse.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 9c23225a8364323adc796eb1c9fa8258

On Sat, 9 Oct 1999 thudson@cygnus.com wrote:

> > To get back to the default state of affairs: then you just need a
> > small midirouting daemon that runs in the background, holds all
> > /dev/mididev* device files open, and forwards data to and from
> > /dev/midififo*. Note the inherent similarity to OMS here. I even wrote
> > such a small daemon last year, but I rarely use it anymore. It even
> > did channel splitting across ports, and I once had plans to do note
> > splits across ports as well (i.e. if (noteNum > N) send_to (portA)
> > else send_to (portB)). Fun stuff.
> >
> Something similar to this is a pet project for me. Rather than putting
> the intelligence in every app to deal with ALSA details, I would like to
> have an ALSA kernel client w/ a gui app as a controller that would allow
> me to specify the routing between oblivious apps. However, I tend to 
> think of more fine-grained routing than ports. From a users perspective
> it would be nicer to specify:
> 
> External keybord => MidiAppegiator => MidiEcho => Sequencer:Track 1 =>
>  External Synth (responding on channel 5)
> 
> External Drum Pad => KetKit => CSound
> 
> Rather than, let's see, my keyboard is set to channel one and is 
> connected to the first port of my second Midi card. I need to set
> my MidiArpeggiator,MidiEcho, and Sequencer Track one to receive on 
> channel one and output on channel 5 of the third port of my first midi
> card...

The ALSA sequencer can create a connections between ports from third
(non-participient) client. 

It seems that many things are already implemented (event router - ALSA
sequencer for example) or they are in my TODO list in my head for the
ALSA (next example: I need to finish some plugin PCM interface for
alsa-lib, because the new lowlevel PCM drivers doesn't do sample
conversions itself).

I have also an another impressive idea: The alsa-lib routes commands
over network. An user types 'export SOUND=sound.perex.cz:0' and everything
will be redirected through an network to an ALSA server daemon without
any change inside an application. It would be probably slow on 10Mbit/s
networks, but imagine 100Mbit/s or 1000Mbit/s networks.

I would like to see, if we join our efforts to one background sound  
project and create good universal sound API for Linux, because there is
really only few active Linux audio developers around.

I'm going to be more and more tired, because the feedbacks and comments
for ALSA API in most cases reach me too late (and I have to recode
everything).

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA project  http://www.alsa-project.org


From - Sun Oct 10 22:31:52 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA05896
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 14:23:31 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA14723 for linux-audio-dev-list; Sat, 9 Oct 1999 14:05:31 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA14720 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 14:05:28 -0400
Received: from localhost.localdomain (d212-151-109-148.swipnet.se [212.151.109.148]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id UAA15443; 
          Sat, 9 Oct 1999 20:00:42 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Benno Senoner <sbenno@gardena.net>, Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: a new application underway ... timing issues in a client/server enviroment
Date: Sat, 9 Oct 1999 19:34:52 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910082334.TAA25056@renoir.op.net> <99100920201100.00807@linuxhost.localdomain>
In-Reply-To: <99100920201100.00807@linuxhost.localdomain>
MIME-Version: 1.0
Message-Id: <99100920073200.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id UAA15443
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id OAA05896
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: f2e1f43b4e8a6ddf99f4a4055094dc4d

On Sat, 09 Oct 1999, Benno Senoner wrote:
[...]
> Of course one could choose to run the audioserver in kernelspace
> to provide even better timing (actually there is little proof that we will
> really get better timing during high system load),

Exactly. With SCHED_FIFO and the low latency patch, the peak latency seems to
be about the same as in kernel space. True, you have less flexibility than in
kernel space, but with a module providing some useful services (like the ALSA
sequencer, or our Multimedia Communication Core or whatever it will be), that's
a non-issue.

> but I'm strongly against of this, since there will be many buggy plugins
> around, which could take our linux box down.
> (see DirectX on windoze).

Agree. (Wonder what effect the new DirectX filter architecture will have on
Windows' stability, BTW. Filters execute in kernel context... A new dimension
in crashability? ;-) Only RTLinux performance can justify running plug-ins in
the kernel, and that is if you really need it. (Protected memory for RTL would
change things a bit, though.)

> Are there any valid reasons to NOT adopt my proposed audio client/server
> model ?
> By using sharedmen / efficient IPC, we could even run many 
> low-latency apps simultaneously with only little overhead.

Well, the minimum "direct" latency that applications can get will depend a
little on how many applications are running. And starting a new thread with
higher priority would increase the lowest reliable latency for the ones
currently running.

I'd suggest that the server provides an API that lets clients ask what the
minimum latency is for a given priority. The server could also notify
applications when things are about to change. This would require some thought,
and it still can't stop applications from being rude and ignoring the system.
But it's certainly a lot better than no *possibility* to cooperate at all.

> I think kernel space belongs mainly to PCM/Midi driver,
> and maybe some eventrouter which has to be well tested and crashproof.

A basic Multimedia Communication Service that connects audio and event ports,
and encapsulates the device drivers as "built-in" clients... You could hook up a
central engine (user space or RTLinux), but applicatins that prefer hosting
plug-ins locally don't have to care, and can run without the engine.

Sounds a bit like ALSA on steroids...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:31:45 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA29169
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 12:47:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA14444 for linux-audio-dev-list; Sat, 9 Oct 1999 12:24:25 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA14441 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 12:24:21 -0400
Received: from linuxhost.localdomain (IDENT:root@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id SAA09994;
	Sat, 9 Oct 1999 18:19:33 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id UAA01221;
	Sat, 9 Oct 1999 20:20:11 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re:  a new application underway  ... timing issues in a client/server enviroment
Date: Sat, 9 Oct 1999 19:55:04 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: David Olofson <audiality@swipnet.se>
References: <199910082334.TAA25056@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99100920201100.00807@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: f6da411818ca6a05ecf84c3e11d40a20

On Sat, 09 Oct 1999, Paul Barton-Davis wrote:
> 
> 
> the scenario in which the sequencer helps is simple: suppose that
> you're a program that is *not* currently generating samples and *not*
> using the RTC, but basically asleep, doing a select(2) or poll(2) on a
> whole set of various file descriptors. Our automation recording wants
> us to wake up at a certain point and do something.
> 
> Currently, you can only get 20ms or so accuracy on this from user
> space in the scenario I describe. If the ALSA sequencer can do
> flexible time scheduling, then you can ensure that you will be woken
> up at exactly the right moment.
> 
> What kind of program does this ? Well, certainly most audio applications
> don't need this, because they have the DAC to provide a time sync
> source. But pure MIDI apps don't have this, and so the sequencer is
> very useful for them. Programs that typically don't continuously
> output samples would also benefit from it.

Agreed,
but I think that the linux audio framework
(now that it seems official that low-latency will get into kernel 2.4),
assuming that the Audiality project (or call it like you want) will succeed,
 will converge to a audio client/server model, where you will even be able
to run the audio server as an userspace app so that all non RTLinux using
linuxers, will get high audio performance.

That means legacy apps will comunicate to the audioserver through a 
/dev/dsp , /dev/midi etc. emulation (like esddsp for example).
and new apps will usee our API.
That means since the PCM device is under the server's control,
there is no problem to provide a timer for the clients.
Just let the clients wait on a fifo,message queue or semaphore,
and let the server wakeup the client at the right moment.
Using the PCM interface with 32 samples fragments, we can get a timer 
with a precision down to 700usec, and if we need more we can let the
server use the RTC device.
But as usual when system load increases the scheduling jitter could 
add 500-1000usecs.

Of course one could choose to run the audioserver in kernelspace
to provide even better timing (actually there is little proof that we will
really get better timing during high system load),
but I'm strongly against of this, since there will be many buggy plugins
around, which could take our linux box down.
(see DirectX on windoze).

Are there any valid reasons to NOT adopt my proposed audio client/server
model ?
By using sharedmen / efficient IPC, we could even run many 
low-latency apps simultaneously with only little overhead. 

I think kernel space belongs mainly to PCM/Midi driver,
and maybe some eventrouter which has to be well tested and crashproof.

comments ?

regards,
Benno.

From - Sun Oct 10 22:32:15 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA21011
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 17:16:27 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA14816 for linux-audio-dev-list; Sat, 9 Oct 1999 14:54:50 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA14813 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 14:54:47 -0400
Received: from localhost.localdomain (d212-151-109-148.swipnet.se [212.151.109.148]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id UAA06598; 
          Sat, 9 Oct 1999 20:50:08 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Benjamin GOLINVAUX <golinvaux@benjamin.net>,
        Benjamin GOLINVAUX <golinvaux@benjamin.net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] non-destructive editing
Date: Sat, 9 Oct 1999 20:17:18 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <0003566e187af433_mailit@relay.eunet.be>
In-Reply-To: <0003566e187af433_mailit@relay.eunet.be>
MIME-Version: 1.0
Message-Id: <99100920565801.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id UAA06598
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id RAA21011
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 33dff79bec064183c6a45a364cd6a0b4

On Sat, 09 Oct 1999, Benjamin GOLINVAUX wrote:
> Hi,
> 
> I want to implement a non-destructive editing app (basic operations : cut, 
> copy, paste, process) and
> I thought of keeping consecutive editing chunks in different files, in order 
> to be able to undo any number
> of actions. Then, I read that Fairlight MFX3, which is a rather old (1994) 
> machine, uses chunks of 128K inside a _single_ file...
> 
> Furthermore, I would like to be able to MOVE parts of one sound to another, 
> possibly on another track,
> which makes the non-destructive stuff complex (I certainly don't wanna 
> duplicate data until necessary).
> 
> What's your opinion on the tradeoffs and advantages of both methods ? I don't 
> wanna start with something I could regret later...
> 
> Thanks.

I'd split the problem into multiple layers (in order of dependancy):

1) Playlist interpretation

   First (execution time), you have to decied what to play, and when,
   so that you know what data to stream. I'd use some form of playlist
   that contains entries looking something like this:

	struct playlist_entry_t {
		int	time;	/* Samples */
		clip_t	*clip;
		int	track;	/* for virtual mixer routing */
		float	level;
		float	pan;
	};

   clip_t is used by the editor to keep track of clips (parts of audio
   files, or entire files) in a structured way:

	struct clip {
		char	*name;
		int	file_id;	/* ...or handle */
		int	offset;		/* start in file */
		int	length;		/* # of samples */
	};

   (file_id could be used instead of directly using the file handle,
   as that would allow the disk I/O code to avoid reading the same
   data multiple times in some cases.)

2) Data streaming

   Here you need to make sure you can reliably deliver and record data.
   Basically, you turn playlist entries into read requests, and feed
   them to this layer. A similar scheme can be used for writing data.

   Buffering will always be needed, and if you want to do processing
   with less latency than this buffering means, you have to run this
   part as a separate thread.

3) Mixing

   This layer reads the playlist, and mixes the data from layer (2)
   into a master output mix. It shouldn't care about the interaction
   between layer (1) and (2), but just make sure the mix is correct,
   and expect layer (2) to do it's job correctly. (If the data is
   late, you're screwed anyway...)


There are many possible variants on this theme, but I think separate files is
the way to go in this case. The seek overhead reduction that a single,
interleaved file design means, would have the exact opposite effect as soon as
you move something more than that a delay in the mixer could handle it.

Note: A file with large chunks is *not* the same thing. Actually, it has about
the same effect as using mulitple files WRT physical positioning of data on the
disk. The difference is that it gets rather messy to remove unused data with a
single file design...

BTW, does anyone know of a fs that allows removing blocks in the middle of
files? (It's possible to do, but I'm not sure I would want to see the
resulting mess... :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:32:28 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA25864
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 18:14:38 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA15133 for linux-audio-dev-list; Sat, 9 Oct 1999 17:26:52 -0400
Received: from sculpcave (cvx-2-314.dyn.nic.fi [62.236.195.60]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA15124 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 17:26:45 -0400
Received: from localhost (localhost [127.0.0.1])
	by sculpcave (Postfix) with ESMTP
	id D642734D3A; Sat,  9 Oct 1999 21:24:44 +0300 (EEST)
Date: Sat, 9 Oct 1999 21:24:44 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
X-Sender: root@sculpcave.localdomain
To: Paul Barton-Davis <pbd@Op.Net>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway 
In-Reply-To: <199910091422.KAA05235@renoir.op.net>
Message-ID: <Pine.LNX.4.10.9910092016430.5477-100000@sculpcave.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 806eac5146101e34547dcf456e34c956

On Sat, 9 Oct 1999, Paul Barton-Davis wrote:

> software under Linux gets written because someone wants to scratch an
> itch. I have an itch: a better live multitrack HDR system. I also have
> a PC1600X with 16 physical faders+16 buttons. Therefore, I am quite
> happy to develop something that utilizes them, even if its not the
> best solution for everyone.

I understand this and I'm not saying that you should change your design. 
Obviously, a lot of people must like hardware-like interfaces. And
if you do have a flexible MIDI-controller, these interfaces are
usable.

Still, I don't think this is the only way to do it. I'm not saying 
I know the answer, I'm only trying raise discussion. Some specific
things about virtual mixers:

- why hard-code effects to the interface (EQs, panning, amplify)?
- why separate these hard-coded effects from other effects 
  (--> effect loops)
- why concentrate on inputs?

With hw-mixers, it's obvious why these design-choices are made.
But with computer programs, you don't have to worry about hardware 
limitations and physical environment (at least not so much).

> the same observation about the UI metaphors has been made about the
> patch cords in Quasimodo. I would be happy to come up with something
> else if someone could point to me the appropriate metaphor(s). But I
> haven't seen it yet, and so I am going with a set of metaphors (fader

Of course, whether imitating physical interfaces is a good way to 
design computer software, is not a yes-no question. Sometimes it's 
the right way to go, sometimes it isn't. IMHO, modular synths are 
quite similar to computer software. You connect (=pointers) 
modules (=abstract objects) to each other.

> note that hdr doesn't do anything to alter your mix-setup. it doesn't
> touch the hardware mixers in your system. if you use a cmdline utility
[...]
> of these apply when dealing with the majority of h/w mixers on current
> soundcards.

No, no, I wasn't talking about soundcard's hw-mixers. 

> however, just like quasimodo, hdr has a complete firewall between the
> mixing engine and the interface. you could easily build a text-based
> UI for it, if you had a particular metaphor in mind.

Same here. ;) If someone want's to code a virtual mixer interface to
ecasound, just go ahead.

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav

From - Sun Oct 10 22:32:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA24642
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 17:57:30 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA15132 for linux-audio-dev-list; Sat, 9 Oct 1999 17:26:51 -0400
Received: from sculpcave (cvx-2-314.dyn.nic.fi [62.236.195.60]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA15123 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 17:26:45 -0400
Received: from localhost (localhost [127.0.0.1])
	by sculpcave (Postfix) with ESMTP
	id 3B77834D3B; Sat,  9 Oct 1999 21:44:30 +0300 (EEST)
Date: Sat, 9 Oct 1999 21:44:30 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
X-Sender: root@sculpcave.localdomain
To: LAD <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] linux audio apps/authors behind open-plugin-whatever
Message-ID: <Pine.LNX.4.10.9910092125210.5477-100000@sculpcave.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by nerf.ulster.net id RAA24642
Status: U
X-Mozilla-Status: 8003
X-Mozilla-Status2: 00000000
X-UIDL: 2a8d3315adbcb89185e0f6d47c0532cf

No answer, so let's ask again...

So far:

- Audiality 
- Quasimodo 
- oolaboola (?)
- ecasound 

Other list actives, are you working on some project?

- Paul Winkler
- David Slomin
- Benno Senoner
- Mt Rcz (reactor)
- Juhana Sadeharju
- Eli Brandt

Some projects that I'd like see on this list...

- xmms
- alsaplayer
- SoundTracker
- SLab
- aRts
- jMax
- Brahms
- gAlan
- ...

Of course there's a lot of software out there, but I know these
projects are active and have a wide userbase. Dave Phillips 
might know more about this...

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav





  






From - Sun Oct 10 22:32:17 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA21191
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 17:18:17 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA14829 for linux-audio-dev-list; Sat, 9 Oct 1999 15:00:28 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA14826 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 15:00:25 -0400
Received: from localhost.localdomain (d212-151-109-148.swipnet.se [212.151.109.148]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id UAA18388; 
          Sat, 9 Oct 1999 20:55:43 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Kai Vehmanen <kaiv@wakkanet.fi>,
        Jrn Nettingsmeier <nettings@folkwang.uni-essen.de>
Subject: Re: [linux-audio-dev] multi-track audio files - what format ?
Date: Sat, 9 Oct 1999 20:57:15 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
References: <Pine.LNX.4.10.9910081756280.663-100000@sculpcave.localdomain>
In-Reply-To: <Pine.LNX.4.10.9910081756280.663-100000@sculpcave.localdomain>
MIME-Version: 1.0
Message-Id: <99100921023302.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id UAA18388
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id RAA21191
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 745ec3ca8ea89c00e2d49c767643c6c5

On Fri, 08 Oct 1999, Kai Vehmanen wrote:
> There are of course exceptions. If you have to record many
> high-quality tracks simultaniously, interleaving is the 
> way to go. 

I don't agree... Unless you can't use sufficient buffering, there's no excuse
for interleaving in this case. If the data is in the (huge) record buffer,
it's accessible if someone needs to read it before it's on the disk, so latency
is a non-issue here. (As opposed to playback, where some kinds of edit
operations will be bound to the disk->output latency.)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:31:53 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA15046
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 16:07:25 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA14906 for linux-audio-dev-list; Sat, 9 Oct 1999 15:48:19 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA14903 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 15:48:14 -0400
Received: from localhost.localdomain (d212-151-109-148.swipnet.se [212.151.109.148]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id VAA19991; 
          Sat, 9 Oct 1999 21:43:31 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] API design again [code]
Date: Sat, 9 Oct 1999 21:11:16 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910091439.KAA06060@renoir.op.net>
In-Reply-To: <199910091439.KAA06060@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99100921502103.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id VAA19991
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id QAA15046
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 686626c13d5776b36bddf8202a3d505e

On Sat, 09 Oct 1999, Paul Barton-Davis wrote:
[...]
> where do the events come from ?

Always from within the same thread.

> that is to say, in a multi-threaded
> system, what actually allocates, deallocates, and otherwise sets up
> event_t's for their use in the API ?

This low level part of the API is only intended for building the event buffers
to pass on to other threads. (As opposed to transmitting events one at a time.)

> if its the engine thread itself, how do you get events delivered to
> it? i see two possibilities, both of them bad.
> 
>   1) you're imagining that, external "h/w" events (e.g. MIDI i/o, GUI
>      events, etc) get handled by a plugin run by the engine thread. 
>      In the case of MIDI-like stuff, this gets rid of sample accuracy,  
>      since we can't notice the event till we execute the plugin, which
>      happens once per control cycle.

Implementation flaw. You will always need an IRQ handler or a separate thread
to add timing info, if the hardware doesn't.

>      In the case of GUI stuff, its
>      even worse, since at least one well known and widely utilized GUI 
>      system (X Window) isn't (properly) multithreaded, and you will crash.

Same rule applies. It's up to the GUI system or the application's GUI code to
grab timing infromation.

>   2) h/w-driven events get noticed by other threads, and are then
>      delivered to the engine thread somehow. this seems to imply some
>      wholly different event-type-specific-API. seems like a bad idea,
>      given that this event system is supposed to be generic.

This is closer to my solution. However, the physical event_port_t instance you
see from your thread is not the same one as the actual destination. (Unless the
destination is running in the same thread.) It's a "shadow port" that's only
used to hide the fact that you're working on your own, in your own context, all
the time until you're done with all work related to the current cycle. It's not
until then that the event buffers will be sent off to their real destinations.

> So, it seems likely to me that we're going to need to be able get hold
> of event_t's from multiple threads. In that case, how do you ensure
> atomicity on the *next pointer, and on *heap ?

(See above.)

> if qm_thread_t is actually as simple as you propose, you can't use
> lock free queues, and likewise for the event_t *next pointer.

There *is* one related problem here. In cases where the sender and
destination is sharing physical memory, the qm_new_buffer() function (that gets
called when some qm_heap_t runs out of buffer space) needs to get new buffers
from the global (shared) heap.

One solution would be to have individual "global" heaps for the threads that
need to get buffers from a certain shared memory block, and then have some kind
of "daemon" to move buffers around to keep the system in balance. However, that
gets a little unreliable when low on memory.

The clean and simple solution is to have the qm_new_buffer() function in kernel
context, as an ioctl() of the Multimedia Communication Core, and protect the
global memory heap with a spinlock.

> so somewhere in there you're going to have one or more locks that need
> to be taken, and the cost of this will far outweigh the other stuff
> you're worried about.

There will be a spinlock for the operation of the Multimedia Communication Core
grabbing all new buffers for merging and/or passing to the local (real)
destination ports. It will contend for the duration of a few instructions when
an application is so late finnishing it's cycle that it hits the lock just
when the engine is about to gather the input for the next cycle... (That's an
overload condition.)

> or have i missed something fundamental and obvious again ? :)

Fundamental, but not obvious. :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:32:23 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA24052
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 17:49:41 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA15129 for linux-audio-dev-list; Sat, 9 Oct 1999 17:26:50 -0400
Received: from sculpcave (cvx-2-314.dyn.nic.fi [62.236.195.60]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA15122 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 17:26:45 -0400
Received: from localhost (localhost [127.0.0.1])
	by sculpcave (Postfix) with ESMTP
	id 9D3F434D3C; Sat,  9 Oct 1999 22:23:19 +0300 (EEST)
Date: Sat, 9 Oct 1999 22:23:19 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
X-Sender: root@sculpcave.localdomain
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] plugin questions
Message-ID: <Pine.LNX.4.10.9910092145410.5477-100000@sculpcave.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 3b0e60fe1469f039ec02a5850ba7f13b

Ok, we have a event system where something creates events,
events are sent to plugin-instances, plugins parse the 
events (?) and act accordingly, someone triggers plugin
processing (by sending the actual data).

Then to the question... when I load a plugin, how/where do I get info
on what kind of events this plugin accepts, how many parameters it
accepts and what they control, what are valid values, etc.?

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav




From - Sun Oct 10 22:31:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA15359
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 16:11:34 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA14913 for linux-audio-dev-list; Sat, 9 Oct 1999 15:53:17 -0400
Received: from kaybee.org (kaybee.resnet.gatech.edu [128.61.15.250]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA14910 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 15:53:14 -0400
Received: from localhost (rob@localhost)
	by kaybee.org (8.8.7/8.8.7) with ESMTP id PAA30571;
	Sat, 9 Oct 1999 15:48:36 -0400
Date: Sat, 9 Oct 1999 15:48:36 -0400 (EDT)
From: rob <rob@kaybee.org>
To: David Olofson <audiality@swipnet.se>
cc: Benjamin GOLINVAUX <golinvaux@benjamin.net>,
        Benjamin GOLINVAUX <golinvaux@benjamin.net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] non-destructive editing
In-Reply-To: <99100920565801.00456@localhost.localdomain>
Message-ID: <Pine.LNX.4.10.9910091544480.30537-100000@kaybee.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: a65ba0c644b3ea1c9d5ca2d1c405fe57

On Sat, 9 Oct 1999, David Olofson wrote:

> BTW, does anyone know of a fs that allows removing blocks in the middle of
> files? (It's possible to do, but I'm not sure I would want to see the
> resulting mess... :-)

	i would expect that most filesystems that use linked-list/tree
based file allocation schemes would allow it, although the api might not
support it directly.  the only thing you'd have to deal with beside fixing
up inodes, is dealing with the leftovers that weren't deleted from the
same block. 

				rob
----
Rob Melby
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
Internet: rob@kaybee.org, gt4255a@prism.gatech.edu

From - Sun Oct 10 22:31:59 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA16494
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 16:25:40 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA14938 for linux-audio-dev-list; Sat, 9 Oct 1999 16:02:22 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA14935 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 16:02:18 -0400
Received: from localhost.localdomain (d212-151-109-148.swipnet.se [212.151.109.148]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id VAA19547; 
          Sat, 9 Oct 1999 21:57:35 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] API design again
Date: Sat, 9 Oct 1999 21:52:12 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910091446.KAA06355@renoir.op.net>
In-Reply-To: <199910091446.KAA06355@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99100922042504.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id VAA19547
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id QAA16494
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 9caeb439309b3e5eacf9ac9097525d42

On Sat, 09 Oct 1999, Paul Barton-Davis wrote:
[...]
> a plugin will almost never be just a function call. it will have some
> state that goes with it. the other callback "process_events()"
> understands how to parse the events and manipulate the state data. 

Ok. Still two function calls for every single bunch of "simultaneous" events,
as opposed to one call for a fixed number of samples.

> one thing i prefer about this approach is that it enforces cleaner
> conceptual thinking on the part of a plugin designer.

Enforcing a certain way of thinking 1) upsets many developers and 2) still
doesn't keep sloppy programmers from hacking bad code. Hopefully, it improves
things a bit in some cases, but "evil" programmers tend to work around the
implied style anyway for various reasons...

> the process()
> call is responsible for generating data on the basis of the current
> state and the amount of data called for; the process_events() call is
> responsible for mapping from the event types floating around in the
> system to the internal state of the plugin.
> 
> this seems like a big win to me. 

It is, but what's the big difference from making the real_process() function an
inline and "call" it yourself from within the process_with_events() function's
decoding loop?

All you have to do is check the time stamps... (Or don't, if you don't care
about sub-buffer size accuracy. Or quantize to 4 samples, if that fits your
real_process() better.)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:32:12 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA20895
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 17:15:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA15039 for linux-audio-dev-list; Sat, 9 Oct 1999 16:52:40 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA15036 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 16:52:36 -0400
Received: from localhost.localdomain (d212-151-109-148.swipnet.se [212.151.109.148]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id WAA00840; 
          Sat, 9 Oct 1999 22:47:42 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Jaroslav Kysela <perex@suse.cz>, thudson@cygnus.com
Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc.
Date: Sat, 9 Oct 1999 22:13:45 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: Paul Barton-Davis <pbd@Op.Net>,
        Linux Audio Development Mailing list <linux-audio-dev@ginette.musique.umontreal.ca>,
        ALSA development <alsa-devel@alsa-project.org>
References: <Pine.LNX.4.05.9910091841010.9771-100000@gate.suse.cz>
In-Reply-To: <Pine.LNX.4.05.9910091841010.9771-100000@gate.suse.cz>
MIME-Version: 1.0
Message-Id: <99100922543205.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id WAA00840
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id RAA20895
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7036df783e1e168501411293dab97201

On Sat, 09 Oct 1999, Jaroslav Kysela wrote:
[...]
> I would like to see, if we join our efforts to one background sound  
> project and create good universal sound API for Linux, because there is
> really only few active Linux audio developers around.

So would I. I think a universal "IPC" API for multimedia would help things a
lot when integrating applications and engines into The multimedia system. I'm
not sure exactly how this fits with the ALSA API, but it seems like the
concepts are rather similar in many ways.

The question is, where does the new API fit in?

IMO, there should be a Multimedia Communication System (or whatever)
that lives in kernel space and provides

1) A transparent shared memory based IPC protocol, tailored for real
   time streaming and communication. This should be a client/server
   style system where kernel modules, drivers and user space
   applications and engines can register, to provide and/or use real
   time services. (My idea is that this shouldn't really be directly
   multimedia oriented.)

2) An API layer that implements a flexible buffered event system, and
   data format independent streaming capabilities on top of that IPC
   protocol. (Most of the frequently used stuff, like event handling,
   should be done in inline code for performance.)

3) A plug-in API that interfaces nicely with the API layer, so that
   plug-in hosts don't have to do lots of translation.

Plug-ins and clients should work in very similar ways - as seen from other
clients - in order to support low level integration of the whole system. There
shouldn't be a need for special protocols in order to get applications to
cooperate in useful ways.

This is what I currently have in mind for the plug-in API in planning, and I
have a rather clear idea about how to implement most of it.

Please, keep trying to shoot my design ideas down! :-) It's very helpful and
inspiring, and makes me see better and cleaner solutions sooner. And tips on
solutions found in existing systems are always welcome, as I just don't have
the time to read all code there is myself...


It's all happening on linux-audio-dev@ginette.musique.umontreal.ca, for
those who don't hang around there (yet).


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:32:02 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA18478
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 16:46:57 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA14992 for linux-audio-dev-list; Sat, 9 Oct 1999 16:26:33 -0400
Received: from chekov.Belgium.EU.net (chekov.belgium.eu.net [193.74.208.161]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA14988 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 16:26:30 -0400
Received: from (adial068.liege.eunet.be [195.207.174.68])
	by chekov.Belgium.EU.net  with SMTP id WAA24569 
	for <linux-audio-dev@ginette.musique.umontreal.ca>;
	Sat, 9 Oct 1999 22:21:51 +0200 (MET DST)
Subject: Re: [linux-audio-dev] non-destructive editing
From: Benjamin GOLINVAUX <golinvaux@benjamin.net>
Reply-To: Benjamin GOLINVAUX <golinvaux@benjamin.net>
In-Reply-To: <99100920565801.00456@localhost.localdomain>
Message-ID: <00035678729b8eb7_mailit@relay.eunet.be>
References: <0003566e187af433_mailit@relay.eunet.be> <99100920565801.00456@localhost.localdomain>
Date: Sat, 09 Oct 1999 22:17:28 +0200
X-Mailer: BeatWare Mail-It 2.0.3
X-BeOS-Platform: Intel or clone
X-Priority: 3 (Normal)
To: linux-audio-dev@ginette.musique.umontreal.ca
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 22ccbba006db633cd765dc1bd5b352e1

>There are many possible variants on this theme, but I think separate files 
is
>the way to go in this case. The seek overhead reduction that a single,
>interleaved file design means, would have the exact opposite effect as soon 
>as you move something more than that a delay in the mixer could handle it.

Thanks... I won't hesitate any longer.

The little complexity (unrelated to single file/multiple file choice) is the 
buffering
modification when number of tracks/average file swith per minute increases...

I'd like to provide users with a benchmarking system in order to tune the app
first... but building a robust and elegant auto-tuning system is not an easy 
task...

>BTW, does anyone know of a fs that allows removing blocks in the middle of
>files? (It's possible to do, but I'm not sure I would want to see the
>resulting mess... :-)

That must be the kind of fs Fairlight uses...

BTW, I know they were running OS/9 or something like that which seems to be
some kind of UNIX-like OS... Can someone provide details on it just for the 
fun ?
(there might be some kind of Ingo's patch for Fairlight OS that must have 
been 
devised back in the eighties ;-)

Benjamin-

From - Sun Oct 10 22:32:01 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA18414
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 16:46:21 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA14983 for linux-audio-dev-list; Sat, 9 Oct 1999 16:24:56 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA14980 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 16:24:54 -0400
Received: from someip.ppp.op.net (d-bm3-07.ppp.op.net [209.152.194.71]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id QAA23220; Sat, 9 Oct 1999 16:20:11 -0400 (EDT)
Message-Id: <199910092020.QAA23220@renoir.op.net>
To: David Olofson <audiality@swipnet.se>
cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] API design again [code] 
In-reply-to: Your message of "Sat, 09 Oct 1999 21:11:16 +0200."
             <99100921502103.00456@localhost.localdomain> 
Date: Sat, 09 Oct 1999 16:20:38 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 05984367c2a3ab83255f7a7def1a14df

>>   2) h/w-driven events get noticed by other threads, and are then
>>      delivered to the engine thread somehow. this seems to imply some
>>      wholly different event-type-specific-API. seems like a bad idea,
>>      given that this event system is supposed to be generic.

>This is closer to my solution. However, the physical event_port_t
>instance you see from your thread is not the same one as the actual
>destination. (Unless the destination is running in the same thread.)

it can't be, by my very definition: the engine thread is where plugins
run, and other threads are what wakeup from select(2) in order to
generate an event_t.

>It's a "shadow port" that's only used to hide the fact that you're
>working on your own, in your own context, all the time until you're
>done with all work related to the current cycle. It's not until then
>that the event buffers will be sent off to their real destinations.

this still seems unclear to me. suppose i am a MIDI input thread, and
I wake up from select(2). i read the available data. what do i do now?
how do I generate an event_t that can be inserted into the relevant 
queues passed to plugins ? 

Turning to the first approach, you commented:

>>   1) you're imagining that, external "h/w" events (e.g. MIDI i/o, GUI
>>      events, etc) get handled by a plugin run by the engine thread.
>>      In the case of MIDI-like stuff, this gets rid of sample accuracy,
>>      since we can't notice the event till we execute the plugin, which
>>      happens once per control cycle.

>Implementation flaw. You will always need an IRQ handler or a separate thread
>to add timing info, if the hardware doesn't.

but add it to what ? what is the data structure that the timing
information gets marked in ? device drivers that manage byte streams
don't read/write structures, so it can't be part of the data stream
from the driver. it can't be an event_t, since the thread that handles
the h/w event can't allocate event_t's without a lock. so what it is
that gets timestamped ? 

From - Sun Oct 10 22:32:03 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA19070
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 16:53:14 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA15009 for linux-audio-dev-list; Sat, 9 Oct 1999 16:34:21 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA15006 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 16:34:19 -0400
Received: from someip.ppp.op.net (d-bm3-07.ppp.op.net [209.152.194.71]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id QAA23708 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 16:29:43 -0400 (EDT)
Message-Id: <199910092029.QAA23708@renoir.op.net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] API design again 
In-reply-to: Your message of "Sat, 09 Oct 1999 21:52:12 +0200."
             <99100922042504.00456@localhost.localdomain> 
Date: Sat, 09 Oct 1999 16:30:11 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 96c1a20bef6d93e3bbbf27304e093ee2

>> the process()
>> call is responsible for generating data on the basis of the current
>> state and the amount of data called for; the process_events() call is
>> responsible for mapping from the event types floating around in the
>> system to the internal state of the plugin.
>> 
>> this seems like a big win to me. 

>It is, but what's the big difference from making the real_process()
>function an inline and "call" it yourself from within the
>process_with_events() function's decoding loop?

its extremely unlikely to be coded inline except by the truly
fanatical writers of the smallest plugin imaginable. if compiled with
-fomit-frame-pointer, the cost of a function call pails compared to
the register optimization possibilities that open up for the compiler
as a result of it having its own frame.

>All you have to do is check the time stamps... (Or don't, if you
>don't care about sub-buffer size accuracy. Or quantize to 4 samples,
>if that fits your real_process() better.)

i think i am persuaded. this changes the "model" of what the core
plugin function call does so that event processing is the core task,
and data processing/generation is the secondary one. subtle, but
possibly important.

we still need to clear up the thread issues in my previous email.

--p

ps. if you use emacs, could you set your fill-column to something
around 70-74 ? your mail invariably ends up with lines longer than 80
chars when its gets quoted even once, and i end up reformatting it
every time. thanks.

From - Sun Oct 10 22:32:18 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA21558
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 17:22:49 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA15061 for linux-audio-dev-list; Sat, 9 Oct 1999 16:59:24 -0400
Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA15058 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 16:59:20 -0400
Received: from hendrix (barbrady104.zip.com.au [61.8.20.104])
	by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id GAA05643
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 06:38:25 +1000 (EST)
Message-ID: <37FFAB90.BC7BBE1@zip.com.au>
Date: Sat, 09 Oct 1999 20:54:40 +0000
From: Erik de Castro Lopo <erikd@zip.com.au>
Organization: Indonesian murders out of East Timor NOW!
X-Mailer: Mozilla 3.04Gold (X11; I; Linux 2.2.12 i586)
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] non-destructive editing
References: <0003566e187af433_mailit@relay.eunet.be> <99100920565801.00456@localhost.localdomain> <00035678729b8eb7_mailit@relay.eunet.be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2bdc42c5b021c3c6949b333771ad956e

Benjamin GOLINVAUX wrote:
> 
<snip>

> >BTW, does anyone know of a fs that allows removing blocks in the middle of
> >files? (It's possible to do, but I'm not sure I would want to see the
> >resulting mess... :-)
> 
> That must be the kind of fs Fairlight uses...

No the Fairlight uses the standard OS-9 fs. All edits are
non-destructive. If
you record new audio over a section of an existing track it does not
destroy
the old track. On playback it just seeks between the required sections.

> BTW, I know they were running OS/9 or something like that which seems to be
> some kind of UNIX-like OS... Can someone provide details on it just for the
> fun ?

http://www.microware.com/

> (there might be some kind of Ingo's patch for Fairlight OS that must have
> been devised back in the eighties ;-)

No, OS-9 runs on the part of the machine that does the graphics and
disk handling. The hard real-time part runs on a very small proprietary 
RTOS written in 68k assembler.

Erik
-- 
+-------------------------------------------------+
     Erik de Castro Lopo     erikd@zip.com.au
+-------------------------------------------------+
Linux: Because rebooting is for adding new hardware

From - Sun Oct 10 22:32:05 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA20831
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 17:14:41 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA15046 for linux-audio-dev-list; Sat, 9 Oct 1999 16:55:24 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA15043 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 16:55:20 -0400
Received: from localhost.localdomain (d212-151-109-148.swipnet.se [212.151.109.148]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id WAA26933; 
          Sat, 9 Oct 1999 22:50:26 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: rob <rob@kaybee.org>
Subject: Re: [linux-audio-dev] non-destructive editing
Date: Sat, 9 Oct 1999 22:55:21 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: Benjamin GOLINVAUX <golinvaux@benjamin.net>,
        Benjamin GOLINVAUX <golinvaux@benjamin.net>,
        linux-audio-dev@ginette.musique.umontreal.ca
References: <Pine.LNX.4.10.9910091544480.30537-100000@kaybee.org>
In-Reply-To: <Pine.LNX.4.10.9910091544480.30537-100000@kaybee.org>
MIME-Version: 1.0
Message-Id: <99100922571606.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id WAA26933
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id RAA20831
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ee6a2d67292217885ecb7ec542770455

On Sat, 09 Oct 1999, rob wrote:
> On Sat, 9 Oct 1999, David Olofson wrote:
> 
> > BTW, does anyone know of a fs that allows removing blocks in the middle of
> > files? (It's possible to do, but I'm not sure I would want to see the
> > resulting mess... :-)
> 
> 	i would expect that most filesystems that use linked-list/tree
> based file allocation schemes would allow it, although the api might not
> support it directly.

Not very different from truncating files, actually.

> the only thing you'd have to deal with beside fixing
> up inodes, is dealing with the leftovers that weren't deleted from the
> same block. 

Exactly. "Micro fragmentation"...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:32:34 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA27324
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 18:32:35 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA15171 for linux-audio-dev-list; Sat, 9 Oct 1999 17:37:39 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA15168 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 17:37:35 -0400
Received: from localhost.localdomain (d212-151-109-148.swipnet.se [212.151.109.148]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id XAA29860; 
          Sat, 9 Oct 1999 23:32:51 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>
Subject: Re: [linux-audio-dev] API design again [code]
Date: Sat, 9 Oct 1999 23:00:04 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
References: <199910092020.QAA23220@renoir.op.net>
In-Reply-To: <199910092020.QAA23220@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99100923393207.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id XAA29860
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA27324
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3bc997c8de518dbb9fdcf667d61591b9

On Sat, 09 Oct 1999, Paul Barton-Davis wrote:
> >>   2) h/w-driven events get noticed by other threads, and are then
> >>      delivered to the engine thread somehow. this seems to imply some
> >>      wholly different event-type-specific-API. seems like a bad idea,
> >>      given that this event system is supposed to be generic.
> 
> >This is closer to my solution. However, the physical event_port_t
> >instance you see from your thread is not the same one as the actual
> >destination. (Unless the destination is running in the same thread.)
> 
> it can't be, by my very definition: the engine thread is where plugins
> run, and other threads are what wakeup from select(2) in order to
> generate an event_t.

"h/w-driven events get noticed by other threads, and are then delivered to the
engine thread somehow." is what I was thinking about... This is what happens
with my system, only you're not passing the events one by one between threads.

> >It's a "shadow port" that's only used to hide the fact that you're
> >working on your own, in your own context, all the time until you're
> >done with all work related to the current cycle. It's not until then
> >that the event buffers will be sent off to their real destinations.
> 
> this still seems unclear to me. suppose i am a MIDI input thread, and
> I wake up from select(2). i read the available data. what do i do now?
> how do I generate an event_t that can be inserted into the relevant 
> queues passed to plugins ? 

You qm_malloc() some memory for your new event (will be from shared memory if
the destination is on the same machine), you fill it in and "send" it to your
local event port.

As your MIDI thread has no notion of cycle times, it would preferably use some
other time base; perhaps the total sample count (as opposed to samples from the
current buffer) of the target port's context. The translation is done when the
events are passed to the real destination.

Regarding the flushing of the heap buffers you use: As you don't have cycles,
there will be no natural interval for sending the current buffer off to the
garbage collector for the context of the event port. What will happen is just
that the buffers will be left around, and you'll implicitly pass them to the
garbage collector when they're full.

(Note: "Sending to the garbage collector" is a bit simplified. A buffer will
first move to the "queue of buffers to be used" of the real destination event
port. From there, the buffer is returned to the global heap when it's been
parsed by the destination plug-in or client, and is no longer needed.)

> Turning to the first approach, you commented:
> 
> >>   1) you're imagining that, external "h/w" events (e.g. MIDI i/o, GUI
> >>      events, etc) get handled by a plugin run by the engine thread.
> >>      In the case of MIDI-like stuff, this gets rid of sample accuracy,
> >>      since we can't notice the event till we execute the plugin, which
> >>      happens once per control cycle.
> 
> >Implementation flaw. You will always need an IRQ handler or a separate thread
> >to add timing info, if the hardware doesn't.
> 
> but add it to what ? what is the data structure that the timing
> information gets marked in ?

That's what you use qm_malloc() on your local (in this case; shadow) event port
for.

> device drivers that manage byte streams
> don't read/write structures, so it can't be part of the data stream
> from the driver.

Sending events through streams is a different matter, and means that you need
to call a function that encodes (basically removes pointers) and writes the
events to the device. This can be done rather nicely as well, but it's not the
way it's intended to be done in the normal case. Shared memory is what I've
been talking about so far...

> it can't be an event_t, since the thread that handles
> the h/w event can't allocate event_t's without a lock.

It can, as it owns the local shadow port, and hence the heap that qm_malloc()
will allocate from. (qm_new_buffer() could be seen as transfering ownership of
a nem buffer from the global heap to the heap that requests it.)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:32:21 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA23595
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 17:45:47 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA15110 for linux-audio-dev-list; Sat, 9 Oct 1999 17:22:10 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA15107 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 17:22:08 -0400
Received: from someip.ppp.op.net (d-bm3-07.ppp.op.net [209.152.194.71]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id RAA26235 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 17:17:32 -0400 (EDT)
Message-Id: <199910092117.RAA26235@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc. 
In-reply-to: Your message of "Sun, 10 Oct 1999 00:26:08 +0200."
             <99101000345100.00676@linuxhost.localdomain> 
Date: Sat, 09 Oct 1999 17:18:00 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: dfa1bd388c650ca7f576f0d9db3e0b16

>Does anyone know if there is a way to make for example  /dev/dsp wrapper
>which works in read/write mode ?
>maybe by letting the wrapper close the fifo filehandle, and reassign to this
>filedescriptor a unix socket using dup2() ?

just include read(2) and write(2) front-ends in the LD_PRELOAD
wrapper, and redirect the relevant file descriptors to the right
place:

	write (int fd, ...) {
		if (fd == read_pipe) {
		      fd = write_pipe;
		}

		/* do normal stuff */
        }

	read (int fd, ...) {
		if (fd == write_pipe) {
		      fd = read_pipe;
		}

		/* do normal stuff */
        }

From - Sun Oct 10 22:32:42 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA01631
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 19:51:42 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA15157 for linux-audio-dev-list; Sat, 9 Oct 1999 17:31:35 -0400
Received: from gate.suse.cz (perex.cb.cesnet.cz [194.212.165.105]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA15154 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 17:31:32 -0400
Received: from localhost (perex@localhost)
	by gate.suse.cz (8.8.8/8.8.8) with ESMTP id XAA11388;
	Sat, 9 Oct 1999 23:26:24 +0200
X-Authentication-Warning: gate.suse.cz: perex owned process doing -bs
Date: Sat, 9 Oct 1999 23:26:24 +0200 (MEST)
From: Jaroslav Kysela <perex@suse.cz>
To: David Olofson <audiality@swipnet.se>
cc: thudson@cygnus.com, Paul Barton-Davis <pbd@Op.Net>,
        Linux Audio Development Mailing list <linux-audio-dev@ginette.musique.umontreal.ca>,
        ALSA development <alsa-devel@alsa-project.org>
Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc.
In-Reply-To: <99100922543205.00456@localhost.localdomain>
Message-ID: <Pine.LNX.4.05.9910092259380.9771-100000@gate.suse.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 52f34de1c1c7f2100c978b3484c501e7

On Sat, 9 Oct 1999, David Olofson wrote:

> On Sat, 09 Oct 1999, Jaroslav Kysela wrote:
> [...]
> > I would like to see, if we join our efforts to one background sound  
> > project and create good universal sound API for Linux, because there is
> > really only few active Linux audio developers around.
> 
> So would I. I think a universal "IPC" API for multimedia would help things a
> lot when integrating applications and engines into The multimedia system. I'm
> not sure exactly how this fits with the ALSA API, but it seems like the
> concepts are rather similar in many ways.
> 
> The question is, where does the new API fit in?
> 
> IMO, there should be a Multimedia Communication System (or whatever)
> that lives in kernel space and provides
> 
> 1) A transparent shared memory based IPC protocol, tailored for real
>    time streaming and communication. This should be a client/server
>    style system where kernel modules, drivers and user space
>    applications and engines can register, to provide and/or use real
>    time services. (My idea is that this shouldn't really be directly
>    multimedia oriented.)

You described already implemented ALSA sequencer :-) If we separate audio
things from the sequencer concept and add support for shared memory
(accessible from both kernel and user space simultaneously) - IPC shared
memory probably can't be directly accessed from kernel space, we can use
the current code for any applications as a general event router.

I think that the big problem will be with the memory allocation, because
the allocation must be done inside kernel (use mmap from the user space?).
It's problem #1 and we should solve it firstly.

> 2) An API layer that implements a flexible buffered event system, and
>    data format independent streaming capabilities on top of that IPC
>    protocol. (Most of the frequently used stuff, like event handling,
>    should be done in inline code for performance.)

Yes, this sounds good.

> 3) A plug-in API that interfaces nicely with the API layer, so that
>    plug-in hosts don't have to do lots of translation.

This also sounds good. I would be very happy, if I'll work only on clients
(lowlevel drivers) for some realtime event system. I must do some other
thoughs for all sound APIs (mixer, digital audio streaming, MIDI).

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA project  http://www.alsa-project.org

From - Sun Oct 10 22:32:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA26287
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 18:20:26 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA15197 for linux-audio-dev-list; Sat, 9 Oct 1999 17:52:51 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA15194 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 17:52:47 -0400
Received: from localhost.localdomain (d212-151-109-148.swipnet.se [212.151.109.148]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id XAA17383; 
          Sat, 9 Oct 1999 23:48:02 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Benjamin GOLINVAUX <golinvaux@benjamin.net>,
        Benjamin GOLINVAUX <golinvaux@benjamin.net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] non-destructive editing
Date: Sat, 9 Oct 1999 23:40:56 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <0003566e187af433_mailit@relay.eunet.be> <99100920565801.00456@localhost.localdomain> <00035678729b8eb7_mailit@relay.eunet.be>
In-Reply-To: <00035678729b8eb7_mailit@relay.eunet.be>
MIME-Version: 1.0
Message-Id: <99100923545108.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id XAA17383
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA26287
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 583b349e9d0a9a0dbc2c382e799a6e74

On Sat, 09 Oct 1999, Benjamin GOLINVAUX wrote:
[...]
> The little complexity (unrelated to single file/multiple file choice) is the 
> buffering
> modification when number of tracks/average file swith per minute increases...
> 
> I'd like to provide users with a benchmarking system in order to tune the app
> first... but building a robust and elegant auto-tuning system is not an easy 
> task...

You can measure average seek time and sustained transfer rate individually, and
then calculate the buffer size as a function of the number of tracks, and the
data rate/track.

Keep in mind that the shorter the benchmark is, the greater the risk that
you're measuring the average rather than the worst case. And only the worst
case is relevant if you need high reliability...

> >BTW, does anyone know of a fs that allows removing blocks in the middle of
> >files? (It's possible to do, but I'm not sure I would want to see the
> >resulting mess... :-)
> 
> That must be the kind of fs Fairlight uses...

Probably, but it's possible that they put it inside files on a simpler fs, much
like tar, but with huge blocks and this special feature...

> BTW, I know they were running OS/9 or something like that which seems to be
> some kind of UNIX-like OS... Can someone provide details on it just for the 
> fun ?
> (there might be some kind of Ingo's patch for Fairlight OS that must have 
> been 
> devised back in the eighties ;-)

QNX is another example of an OS used for that kind of stuff. They're dedicated
real time operating systems from the ground up, and don't need patches to get
that kind of performance.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:32:31 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA26531
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 18:23:14 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA15205 for linux-audio-dev-list; Sat, 9 Oct 1999 17:59:44 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA15202 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 17:59:42 -0400
Received: from someip.ppp.op.net (d-bm3-07.ppp.op.net [209.152.194.71]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id RAA28017; Sat, 9 Oct 1999 17:55:03 -0400 (EDT)
Message-Id: <199910092155.RAA28017@renoir.op.net>
To: David Olofson <audiality@swipnet.se>
cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] API design again [code] 
In-reply-to: Your message of "Sat, 09 Oct 1999 23:00:04 +0200."
             <99100923393207.00456@localhost.localdomain> 
Date: Sat, 09 Oct 1999 17:55:32 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4378510f9aad5380ca8822c7b0e0df86

>> this still seems unclear to me. suppose i am a MIDI input thread, and
>> I wake up from select(2). i read the available data. what do i do now?
>> how do I generate an event_t that can be inserted into the relevant 
>> queues passed to plugins ? 
>
>You qm_malloc() some memory for your new event (will be from shared memory if
>the destination is on the same machine), you fill it in and "send" it to your
>local event port.

OK, now we're getting somewhere. Not very far though :)

So the event is now queued in my local event port. What causes it to
become available to the engine, and thus get delivered to the plugins?

As for "shared memory" - you bet its in shared memory - thats why I'm
talking "thread", not "process".

>Regarding the flushing of the heap buffers you use: As you don't have cycles,
>there will be no natural interval for sending the current buffer off to the
>garbage collector for the context of the event port. What will happen is just
>that the buffers will be left around, and you'll implicitly pass them to the
>garbage collector when they're full.

>(Note: "Sending to the garbage collector" is a bit simplified. A buffer will
>first move to the "queue of buffers to be used" of the real destination event
>port. From there, the buffer is returned to the global heap when it's been
>parsed by the destination plug-in or client, and is no longer needed.)

ah. now we get more complex still ... how can the plugin or client
possibly do this without a spinlock ? 

--p

From - Sun Oct 10 22:32:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA26919
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 18:27:28 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA15253 for linux-audio-dev-list; Sat, 9 Oct 1999 18:07:23 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA15250 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 18:07:19 -0400
Received: from localhost.localdomain (d212-151-109-148.swipnet.se [212.151.109.148]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA15928; 
          Sun, 10 Oct 1999 00:02:38 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] API design again
Date: Sun, 10 Oct 1999 00:02:24 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910092029.QAA23708@renoir.op.net>
In-Reply-To: <199910092029.QAA23708@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101000092809.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id AAA15928
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA26919
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 789cb007f49772ef23b3f8a54d576ca0

On Sat, 09 Oct 1999, Paul Barton-Davis wrote:
> >It is, but what's the big difference from making the real_process()
> >function an inline and "call" it yourself from within the
> >process_with_events() function's decoding loop?
> 
> its extremely unlikely to be coded inline except by the truly
> fanatical writers of the smallest plugin imaginable. if compiled with
> -fomit-frame-pointer, the cost of a function call pails compared to
> the register optimization possibilities that open up for the compiler
> as a result of it having its own frame.

inline real_process(...)
{
	...
};

was what I had in mind, actually... But you're right; you don't even
have to do that with a decent compiler.

> >All you have to do is check the time stamps... (Or don't, if you
> >don't care about sub-buffer size accuracy. Or quantize to 4 samples,
> >if that fits your real_process() better.)
> 
> i think i am persuaded. this changes the "model" of what the core
> plugin function call does so that event processing is the core task,
> and data processing/generation is the secondary one. subtle, but
> possibly important.

Yes. It gives you more control, without the need for API support. :-)

> we still need to clear up the thread issues in my previous email.

Yes, and we'll probably find other interesting problems to solve as
well. I think I have a rather clear picture of most of the system
now, though. Remains to see if some unclear corner is hiding some
nasty, unpleasant surprise...

> ps. if you use emacs, could you set your fill-column to something
> around 70-74 ? your mail invariably ends up with lines longer than 80
> chars when its gets quoted even once, and i end up reformatting it
> every time. thanks.

Done. (I use Kmail, and the wrapping was set to 80 by default, for
some strange reason...)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:32:49 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA05198
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 20:28:05 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA15476 for linux-audio-dev-list; Sat, 9 Oct 1999 20:09:36 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA15473 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 20:09:30 -0400
Received: from localhost.localdomain (d212-151-58-181.swipnet.se [212.151.58.181]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA06422; 
          Sun, 10 Oct 1999 02:04:52 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Kai Vehmanen <kaiv@wakkanet.fi>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] plugin questions
Date: Sun, 10 Oct 1999 00:24:20 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <Pine.LNX.4.10.9910092145410.5477-100000@sculpcave.localdomain>
In-Reply-To: <Pine.LNX.4.10.9910092145410.5477-100000@sculpcave.localdomain>
MIME-Version: 1.0
Message-Id: <9910100210190A.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id CAA06422
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA05198
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 71fc569e63bf7ded4f47e914c74a0b97

On Sat, 09 Oct 1999, Kai Vehmanen wrote:
> Ok, we have a event system where something creates events,
> events are sent to plugin-instances, plugins parse the 
> events (?) and act accordingly, someone triggers plugin
> processing (by sending the actual data).
> 
> Then to the question... when I load a plugin, how/where do I get info
> on what kind of events this plugin accepts, how many parameters it
> accepts and what they control, what are valid values, etc.?

Next level: "What is the event system used for?"

A while back, I got the idea of adding an init() callback function to
the plug-in. The intention was that it should eliminate the need for
a structure with hardcoded info entries, or a set of callbacks. As
the same API could be used for that, and for the real time event
system, there would be nothing more than a few event IDs to keep
track of.

As a result, binary compatibility accross versions is made easy, and
plug-ins don't need a single line of code for features they don't
care about. (Hold it, C++ freaks! What does the compiler actually
make out of inherited members that you don't override?) The same
init protocol also maps nicely to the client/server API, which
further reduces the difference between plug-ins and clients. Less
boring API stuff for hackers to learn, and more flexibility for users.


I still think this is the way to go, but all details aren't worked
out yet... When the rest of the plug-in API stabilises a bit, I'll
hack some plug-in instantiation and client/server init code to see
what it actualy looks like.


The big job here is to define the events to use for this, and specify
strict rules for their use, ie which ones do you *have* to specify;
do they have to be sent in a specific order; what are the defaults;
how to resolve engine/plug-in/client/server requirement conflicts and
so on...

Something to start with:

1) Init events can be sent in any order (from the client/plug-in),
   and will be treated according to well defined dependency rules.
   (As opposed to OSS ioctls(), where order *does* matter, and
   weird things can happen if you break the rules.)

2) An init (or re-init, when someone wants to change something)
   sequence can involve groups of events that may have
   dependencies, and should therefore be handled as a homogenous
   transaction.

   For plug-ins, this is automatically guaranteed, as each group
   of events is constructed during a callback from the host.

   For clients that communicate through shared memory, it gets
   more complicated. Unless the actual transfer of queued events
   is controlled through a "commit" action from the client, it's
   possible that the server gets an incomplete set of init
   events. I propose a "commit" method for event ports, as this
   can simplify other things as well. (This does not apply to
   plug-ins, as they issue an implicit "commit" operation when
   the process() callback returns.)

3) Buffer size requirements and similar things should be handled
   through request/reply sequences. (The host/server requests a
   certain value, and the plug-in/client replies with the
   closest value it supports.) This is probably one of the most
   complex parts to get right...

4) Parameters (applies to clients, engines and servers, as well
   as plug-ins!) should use standard control event classes
   (which implies that the range, unit and behaviour adheres to
   the standard) as far as possible.

5) The actual representation of parameter values is determined
   by the control event class (4), but some tunable properties
   allow better control of the visual appearance and control
   behaviour, when the parameter isn't controlled by a custom
   UI element.

6) Parameters that do not fit in a standard class will have to
   go into a custom class. The properties of these events must
   be defined during the init sequence. Custom events should be
   *avoided* as far as possible, as they effectively eliminate
   the usefullnes of the event system. (How do you automate
   a parameter that you don't understand?)


IMO, this is where the API gets *audio* specific. Similar sets of
init events can be defined for video and other formats, without
affecting binary compatibility. That is, an engine could host both
audio and video plug-ins without understanding the data formats
involved. The only requirement is that it can handle the low level
routing of data and events, and that it supports the client/server
API, so that the plug-ins can be connected to some data sources and
device driver interfaces. (Of course, such an engine wouldn't allow
much optimization, which is why the client/server API is important.
Use one dedicated engine for each format - your favourite automation
application will still be able to control everything.)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:32:07 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA20867
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 17:15:05 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA15032 for linux-audio-dev-list; Sat, 9 Oct 1999 16:51:51 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA15029 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 16:51:46 -0400
Received: from linuxhost.localdomain (IDENT:benno@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id WAA12980;
	Sat, 9 Oct 1999 22:46:56 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id AAA00769;
	Sun, 10 Oct 1999 00:34:51 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Paul Barton-Davis <pbd@Op.Net>, thudson@cygnus.com
Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc.
Date: Sun, 10 Oct 1999 00:26:08 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <199910091616.MAA10749@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101000345100.00676@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 76c00d106b049a377ab3f5acafc75ba9

On Sat, 09 Oct 1999, Paul Barton-Davis wrote:
> >One specific app I had in mind was KeyKit. While it does allow you to
> >specify a device file, it expects to be able to read and write from
> >this single device.  Unless linux pipes are different from standard
> >unix ones, they can only be opened for read or write. It would be 
> >nice if apps let you specify a different device file for input and 
> >output, but the last time I looked at the KeyKit sources (it's been 
> >a while),  it would require some work to do this. 
> 
> You general point is well taken - pipes are not the same as a file.
> 
> OTOH, If you want my patches to fix KeyKit to use different devices
> for input and output, let me know. I did them a year and half back
> precisely to support the use of FIFO's. I can't remember if I ever
> sent them to Tim, but I should.
> 
> --p
--


Indeed, pipes are unidirectional, I'm just curious how the /dev/dsp wrapper
of esd ( esddsp ) handles fullduplex.
Alternatively we could use UNIX domain sockets, there is no socket flag
in mknod to create a "named socket".

Does anyone know if there is a way to make for example  /dev/dsp wrapper
which works in read/write mode ?
maybe by letting the wrapper close the fifo filehandle, and reassign to this
filedescriptor a unix socket using dup2() ?

regards,
Benno.

From - Sun Oct 10 22:32:24 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA24387
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 17:53:47 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA15144 for linux-audio-dev-list; Sat, 9 Oct 1999 17:29:54 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA15141 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 17:29:49 -0400
Received: from linuxhost.localdomain (IDENT:root@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id XAA13348;
	Sat, 9 Oct 1999 23:24:56 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id BAA00935;
	Sun, 10 Oct 1999 01:25:37 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: timing issues in a client/server enviroment
Date: Sun, 10 Oct 1999 01:02:03 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: David Olofson <audiality@swipnet.se>
References: <199910091643.MAA12205@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101001253701.00676@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7bf720570f2bb5ad3ea78096d3edf20e

On Sat, 09 Oct 1999, Paul Barton-Davis wrote:

> 
> Specifically, I want people to be able to use a variety of different
> applications that might provide the services advertised by the API;
> the situation with GNOME and KDE where there is "standard" not just in
> terms of an API (and runtime library) but also the actual applications
> that must be running is something I don't wish to support. It might be
> useful for people who need handholding with their desktop, and want
> their "you have mail" messages playing back while they listen to a
> real audio clip. But its not OK for those of us who want to do more
> dedicated and serious audio work.
> 
> So yes, I think the development of a standard API, a library, and one
> or more sample implementations is a great idea, but please don't
> anyone go off and think they are writing "the Linux Sound System".

I agree on the fact that apps should be able to do their own pugin hosting,
but sooner or later we will need some engine which allows routing and
integration of simultaneously running audio apps, 
or audio software software vendors will not be very motivated to port
their apps to linux and audio software users will not switch to linux
for serious audio work.
What do you say when users will begin asking:
"why am I unable to record the gigasampler pcm output in my cubase
or drive the reaktor synth from my preferred sequencer, and recording
the result on my HD recorder ?
sooner or later we will need "the linux soundsystem".
An app can choose to not use our api by using legacy /dev/dsp , /dev/midi,
but it will be feed through our engine.
If you don't run the engine, legacy apps wouls still function.

An OS that provides only PCM and MIDI drivers is not suitable
to provide a powerful and flexible DAW enviroment.

Quasimodo is a nice app with many functions, but it's still a monolithic app,
and my foobar wave editor can't use your 24db lowpass filter with a simple 
API call.

My idea is an engine ( userspace or RTLinux) , which handles the whole thing.
It could be similar to quasimodo, but in form of an engine, with flexible
routing, sample accurate evet processing, syncing etc.
Quasimodo would become a client to the engine, and it would open up
infinite possibilities, (driving quasimodo from sequencers, feed quasimodo's
output to HD recorders etc.)
Maybe you can get some of these features by using appropriate hacks
but then you end up as in the windoze case.
"you can't run A+B while C is running etc)


If we create a good audio API, well designed , with no (or as little as
possible) conceptual flaws , I'm very confident people will begin to use it,
and especially audio software vendors will be much more motivated to
port their software to linux if they know that linux provides 
an enviroment with excellent intergration features.
Paul the keyword is "integration", and I think many people are not very
satisfied with windozes integration between audio apps,
(see for example Seer Reality monopolizes the DirectX PCM audio,
that means if you want to play your mp3 on your 2nd soundcard, you can't)
and if we are able to come up with a good standard,
I'm sure that many will have valid reasons to switch.

regards,
Benno.

From - Sun Oct 10 22:32:37 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA01004
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 19:45:12 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA15371 for linux-audio-dev-list; Sat, 9 Oct 1999 19:15:45 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA15368 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 19:15:42 -0400
Received: from someip.ppp.op.net (d-bm2-05.ppp.op.net [209.152.194.37]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id TAA01929; Sat, 9 Oct 1999 19:10:58 -0400 (EDT)
Message-Id: <199910092310.TAA01929@renoir.op.net>
To: Benno Senoner <sbenno@gardena.net>
cc: linux-audio-dev@ginette.musique.umontreal.ca,
        David Olofson <audiality@swipnet.se>
Subject: Re: [linux-audio-dev] Re: timing issues in a client/server enviroment 
In-reply-to: Your message of "Sun, 10 Oct 1999 01:02:03 +0200."
             <99101001253701.00676@linuxhost.localdomain> 
Date: Sat, 09 Oct 1999 19:11:27 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 413dd5a8bf379162f904e062c660399a

>I agree on the fact that apps should be able to do their own pugin hosting,
>but sooner or later we will need some engine which allows routing and
>integration of simultaneously running audio apps, 
>or audio software software vendors will not be very motivated to port
>their apps to linux and audio software users will not switch to linux
>for serious audio work.
>What do you say when users will begin asking:
>"why am I unable to record the gigasampler pcm output in my cubase
>or drive the reaktor synth from my preferred sequencer, and recording
>the result on my HD recorder ?
>sooner or later we will need "the linux soundsystem".
>An app can choose to not use our api by using legacy /dev/dsp , /dev/midi,
>but it will be feed through our engine.
>If you don't run the engine, legacy apps wouls still function.

thats fine. 

>An OS that provides only PCM and MIDI drivers is not suitable
>to provide a powerful and flexible DAW enviroment.

yes it is. in fact, its precisely why Paris, ProTools and the rest all
work under Windows :) oh, ok, these are not flexible enough. i
agree. but this has to do with inter-app communication, not
*necessarily* access to the device drivers. 

>Quasimodo is a nice app with many functions, but it's still a monolithic app,
>and my foobar wave editor can't use your 24db lowpass filter with a simple 
>API call.

thats right. it should use my 24db lowpass filter *plugin*, which
would happen to be the same one that Quasimodo would use, in some
future version where Csound compatibility is no longer the crux of the matter.

>Paul the keyword is "integration", and I think many people are not very
>satisfied with windozes integration between audio apps,

Thats true for people who want lots of apps that all talk to the h/w
at the same time.

Thats not true, as far as I can tell, for people who use well-designed
audio environments.

>(see for example Seer Reality monopolizes the DirectX PCM audio,
>that means if you want to play your mp3 on your 2nd soundcard, you can't)

part of that problem is just braindead design. Seer are not alone in
this - even the wonderful Bill Schottstaedt wrote his sndlib() code to
open /dev/dsp when the library initializes, even though it will likely
not use it!

>and if we are able to come up with a good standard,
>I'm sure that many will have valid reasons to switch.

i agree entirely. i just don't want the model of Linux audio to push
the existence of "direct access" to the PCM and MIDI ports out of the
picture, because for some, this is the right model.

two context switches per delivery of data is just silly, for some things.

i would rather have a defined method by which any application can talk
to any other application, and either of them might actually own the
device nodes. you could start up a DAW, and *it* would be the engine,
accepting data from other sources, or you could start up a replacement
for esd, and *it* would do the same thing, etc. i don't want to force
programs into using something other than the Unix file interface if
they believe they want to use it.

--p

From - Sun Oct 10 22:32:27 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA24782
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 17:59:06 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA15177 for linux-audio-dev-list; Sat, 9 Oct 1999 17:40:09 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA15174 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 17:40:05 -0400
Received: from linuxhost.localdomain (IDENT:root@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id XAA13475;
	Sat, 9 Oct 1999 23:35:16 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id BAA00946;
	Sun, 10 Oct 1999 01:35:57 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Benjamin GOLINVAUX <golinvaux@benjamin.net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] non-destructive editing
Date: Sun, 10 Oct 1999 01:28:35 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <00035678729b8eb7_mailit@relay.eunet.be>
MIME-Version: 1.0
Message-Id: <99101001355702.00676@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5f1d7645c61bafec5fd057a74fc4188a

On Sat, 09 Oct 1999, Benjamin GOLINVAUX wrote:

> Thanks... I won't hesitate any longer.
> 
> The little complexity (unrelated to single file/multiple file choice) is the 
> buffering
> modification when number of tracks/average file swith per minute increases...
> 
> I'd like to provide users with a benchmarking system in order to tune the app
> first... but building a robust and elegant auto-tuning system is not an easy 
> task...

yea, I played with this sort of benchmarking, but the main problem is 
when the user uses the disk for audio AND for the regular files.
There is no guarantee that the kernel will deliver the requested disk
bandwidth to your hd recorder.
Of course for serious work you need a dedicated disk for audio,
but joe average users still want to do some hd recording (with lower number of
tracks) but in a reliable fashion. (windoze can't do there guarantees too)
Hopefully someday there will be available a guaranteed gandwidth filesystem
for Linux.
Just for curiousity: does have BeOS such a feature ?

> 
> >BTW, does anyone know of a fs that allows removing blocks in the middle of
> >files? (It's possible to do, but I'm not sure I would want to see the
> >resulting mess... :-)
> 
> That must be the kind of fs Fairlight uses...
> 
> BTW, I know they were running OS/9 or something like that which seems to be
> some kind of UNIX-like OS... Can someone provide details on it just for the 
> fun ?
> (there might be some kind of Ingo's patch for Fairlight OS that must have 
> been 
> devised back in the eighties ;-)

If you run a dedicated DAW OS there are no such problems like on general purpose
OSes like an user which runs x11perf  , bonnie and the RC5 cracker while
playing back your multitracked song.
:-)
Therefore it's much easier to solve.

regards,
Benno.

From - Sun Oct 10 22:32:47 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA04795
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 20:24:21 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA15459 for linux-audio-dev-list; Sat, 9 Oct 1999 20:05:07 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id UAA15448 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 20:05:04 -0400
From: est@hyperreal.org
Received: (qmail 19695 invoked by uid 162); 10 Oct 1999 00:00:48 -0000
Message-ID: <19991010000048.19694.qmail@hyperreal.org>
Subject: [linux-audio-dev] fifos & unix domain sockets
In-Reply-To: <99101003222603.00676@linuxhost.localdomain> from Benno Senoner
 at "Oct 10, 1999 03:00:33 am"
To: Benno Senoner <sbenno@gardena.net>
Date: Sat, 9 Oct 1999 17:00:48 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: ae754c23b9f7f9d3470336c04c53736b

Benno Senoner discourseth:
> 
> Seems like the fifo uses one single fifo buffer and doesn't care who is the
> reader.

Correct. :)

> that means no reliable fullduplex communication.

Emphatically correct. :)

> I don't know almost nothing about the efficiency of unix domain sockets,
> and if they are implemented by using 2 ring buffers to implement

I tested their throughput a couple of months ago on Linux.  They were
about 1.55 times slower than pipes/fifos.  A tcp connection on the
same machine was 1.6 times slower still (i.e., 2.5 times slower than
pipes/fifos).

Eric

From - Sun Oct 10 22:32:54 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA06545
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 20:44:22 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA15499 for linux-audio-dev-list; Sat, 9 Oct 1999 20:24:50 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA15496 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 20:24:47 -0400
Received: from localhost.localdomain (d212-151-58-181.swipnet.se [212.151.58.181]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA15185; 
          Sun, 10 Oct 1999 02:20:05 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Benno Senoner <sbenno@gardena.net>, Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: timing issues in a client/server enviroment
Date: Sun, 10 Oct 1999 02:14:08 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910091643.MAA12205@renoir.op.net> <99101001253701.00676@linuxhost.localdomain>
In-Reply-To: <99101001253701.00676@linuxhost.localdomain>
MIME-Version: 1.0
Message-Id: <9910100226540B.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id CAA15185
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA06545
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 9e17e402f22c091a76a58cde574e9b8f

On Sun, 10 Oct 1999, Benno Senoner wrote:
[...]
> Quasimodo is a nice app with many functions, but it's still a
> monolithic app, and my foobar wave editor can't use your 24db
> lowpass filter with a simple API call.

Actually, it could with the client/server/plug-in API I'm trying to
describe, provided Quasimodo publishes it's plug-ins, accepts your
connection request. But latency would of course increase with the
number of client/server interface layers involved... And simple?

> My idea is an engine ( userspace or RTLinux) , which handles the whole thing.
> It could be similar to quasimodo, but in form of an engine, with flexible
> routing, sample accurate evet processing, syncing etc.

That can be done quite transparently through the API (client and
plug-ins are very similar), but as I said, latency...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:32:59 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA08346
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 21:04:29 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA15563 for linux-audio-dev-list; Sat, 9 Oct 1999 20:46:40 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA15560 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 20:46:37 -0400
Received: from localhost.localdomain (d212-151-58-181.swipnet.se [212.151.58.181]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA13575; 
          Sun, 10 Oct 1999 02:41:47 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Jaroslav Kysela <perex@suse.cz>
Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc.
Date: Sun, 10 Oct 1999 02:29:39 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: thudson@cygnus.com, Paul Barton-Davis <pbd@Op.Net>,
        Linux Audio Development Mailing list <linux-audio-dev@ginette.musique.umontreal.ca>,
        ALSA development <alsa-devel@alsa-project.org>
References: <Pine.LNX.4.05.9910092259380.9771-100000@gate.suse.cz>
In-Reply-To: <Pine.LNX.4.05.9910092259380.9771-100000@gate.suse.cz>
MIME-Version: 1.0
Message-Id: <9910100248370C.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id CAA13575
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA08346
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e9a5c3f2ed55a8a9501b029de5bb9060

On Sat, 09 Oct 1999, Jaroslav Kysela wrote:
> > 1) A transparent shared memory based IPC protocol, tailored for real
> >    time streaming and communication. This should be a client/server
> >    style system where kernel modules, drivers and user space
> >    applications and engines can register, to provide and/or use real
> >    time services. (My idea is that this shouldn't really be directly
> >    multimedia oriented.)
> 
> You described already implemented ALSA sequencer :-) If we separate audio
> things from the sequencer concept and add support for shared memory
> (accessible from both kernel and user space simultaneously) - IPC shared
> memory probably can't be directly accessed from kernel space, we can use
> the current code for any applications as a general event router.

That sounds very interesting. :-)

> I think that the big problem will be with the memory allocation, because
> the allocation must be done inside kernel (use mmap from the user space?).
> It's problem #1 and we should solve it firstly.

There is a module called mbuff that's used with RTLinux for this
purpose. It's based on the "heavy wizardry" in bttv.c, and I think
the module should work w/o RTL... (Memory allocation from the
standard kernel heap can never be hard real time anyway.)

> > 3) A plug-in API that interfaces nicely with the API layer, so that
> >    plug-in hosts don't have to do lots of translation.
> 
> This also sounds good. I would be very happy, if I'll work only on clients
> (lowlevel drivers) for some realtime event system. I must do some other
> thoughs for all sound APIs (mixer, digital audio streaming, MIDI).

Your drivers become clients, and need only care about the hardware
and the API. As opposed to plug-ins (that are callback functions,
processing one full cycle [buffer] at a time), clients can decide for
themselves when their cycles end, so you kind of get both FIFO
functionality and shared memory performance with the same API.

I think we will have a preliminary spec of the low level part of the
API soon, but so far, most of the info is in the form of posts on
linux-audio-dev...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:32:58 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA07459
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 20:54:43 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA15531 for linux-audio-dev-list; Sat, 9 Oct 1999 20:36:12 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id UAA15528 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 20:36:09 -0400
From: est@hyperreal.org
Received: (qmail 2071 invoked by uid 162); 10 Oct 1999 00:31:53 -0000
Message-ID: <19991010003153.2070.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] linux audio apps/authors behind open-plugin-whatever
In-Reply-To: <Pine.LNX.4.10.9910092125210.5477-100000@sculpcave.localdomain>
 from Kai Vehmanen at "Oct 9, 1999 09:44:30 pm"
To: Kai Vehmanen <kaiv@wakkanet.fi>
Date: Sat, 9 Oct 1999 17:31:53 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 9992fe196a03392683107d4651a6fcc8

Kai Vehmanen discourseth:
> No answer, so let's ask again...
> 
> So far:
> 
[...]
> - oolaboola (?)

That would be me. :)

I suspect progress in this area will be made as people make resonably
concrete and complete proposals that are explcitly GLPLed (or at least
GPLed) so that others can improve them freely.  The devil's in the
details *and* their interaction in the whole.

So far, only Guenter has made such a proposal.

I may contribute one in a couple of months if it seems needed.  I'll
also continue to respond to those that are posted.

`Show me the code', I say. :)

> Some projects that I'd like see on this list...

freeamp people would bring good attention to portability concerns.

Eric

From - Sun Oct 10 22:33:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA16044
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 22:23:55 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA15676 for linux-audio-dev-list; Sat, 9 Oct 1999 21:58:38 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA15673 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 21:58:35 -0400
Received: from localhost.localdomain (d212-151-58-181.swipnet.se [212.151.58.181]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id DAA09714; 
          Sun, 10 Oct 1999 03:53:51 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>
Subject: Re: [linux-audio-dev] API design again [code]
Date: Sun, 10 Oct 1999 02:52:03 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
References: <199910092155.RAA28017@renoir.op.net>
In-Reply-To: <199910092155.RAA28017@renoir.op.net>
MIME-Version: 1.0
Message-Id: <9910100400410D.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id DAA09714
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id WAA16044
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0d5b8ff6c56c5aee3cb2f560a61d9058

On Sat, 09 Oct 1999, Paul Barton-Davis wrote:
[...]
> So the event is now queued in my local event port. What causes it to
> become available to the engine, and thus get delivered to the plugins?

The one sync point that your malicious example is trying to avoid! ;-)

At some point, you have to tell the engine to "grab" the new events,
and that will need to be a sync point of some kind... possibly a FIFO
where the address of the "news" (first event in a linked list, or
whatever it'll be in the end) is passed.

In the case of audio streaming, the natural sync point is the end of
the buffer cycle, and your thread will sleep there, or on the start
of the cycle, if the client gets data from the engine as well.

One possible solution is that your thread wakes up on the
client/server port as well (an ioctl or something - will be a part of
the API anyway), just to keep in sync with the engine's cycle time.
That way, you can get the lowest possible latency without having to
send events to the engine as soon as they come in.

> >Regarding the flushing of the heap buffers you use: As you don't have cycles,
> >there will be no natural interval for sending the current buffer off to the
> >garbage collector for the context of the event port. What will happen is just
> >that the buffers will be left around, and you'll implicitly pass them to the
> >garbage collector when they're full.
> 
> >(Note: "Sending to the garbage collector" is a bit simplified. A buffer will
> >first move to the "queue of buffers to be used" of the real destination event
> >port. From there, the buffer is returned to the global heap when it's been
> >parsed by the destination plug-in or client, and is no longer needed.)
> 
> ah. now we get more complex still ... how can the plugin or client
> possibly do this without a spinlock ?

There will be the global heap spinlock... Of course, some FIFO
approach could be taken, but I doubt it's worth the effort. (One
FIFO per thread; when out of buffers, qm_new_buffer() checks one
FIFO at a time until it finds some buffers...)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:32:44 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA01711
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 19:52:28 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA15386 for linux-audio-dev-list; Sat, 9 Oct 1999 19:26:38 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA15383 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 19:26:34 -0400
Received: from linuxhost.localdomain (IDENT:root@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id BAA14726;
	Sun, 10 Oct 1999 01:21:43 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id DAA01173;
	Sun, 10 Oct 1999 03:22:26 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc.
Date: Sun, 10 Oct 1999 03:00:33 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199910092117.RAA26235@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101003222603.00676@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: fb8e3732b25080f3c8d8f8de45195241

On Sat, 09 Oct 1999, Paul Barton-Davis wrote:
> >Does anyone know if there is a way to make for example  /dev/dsp wrapper
> >which works in read/write mode ?
> >maybe by letting the wrapper close the fifo filehandle, and reassign to this
> >filedescriptor a unix socket using dup2() ?
> 
> just include read(2) and write(2) front-ends in the LD_PRELOAD
> wrapper, and redirect the relevant file descriptors to the right
> place:
> 
> 	write (int fd, ...) {
> 		if (fd == read_pipe) {
> 		      fd = write_pipe;
> 		}
> 
> 		/* do normal stuff */
>         }
> 
> 	read (int fd, ...) {
> 		if (fd == write_pipe) {
> 		      fd = read_pipe;
> 		}
> 
> 		/* do normal stuff */
>         }

Hmm,
I just tried to open a named pipe ( mkfifo /tmp/fifo ) ,
and the behaviour is curious:

consider these 2 simple programs

program A
-----------------------
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>

main()
{
  int f,data,res;


f=open("/tmp/fifo10",O_RDWR);
if(f<0)
{
  perror("open");
  exit(1);
}
  data=10;

  res=write(f,&data,4);
  fsync(f);
  printf("write res=%d\n",res);
  data=-1;
  res=read(f,&data,4);
  printf("read res=%d\n",res);
  printf("data=%d\n",data);
}
-----------------------


program B
-----------------------
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>

main()
{
  int f,data,res;

  f=open("/tmp/fifo10",O_RDWR);
  if(f<0)
  {
    perror("open");
    exit(1);
  }

  res=read(f,&data,4);
  printf("read res=%d\n",res);
  printf("data=%d\n",data);

  data=20;
  res=write(f,&data,4);
  printf("write res=%d\n",res);
}
-----------------------

If you run A) alone
it reads back the data it wrote to the fifo.

if you run first B) and then A)
B waits for data,
A writes the data to the pipe
B reads the data and writes data to the pipe
A reads the data written by B.

BUT: sometime A reads back his own data, as you would run A alone.

Seems like the fifo uses one single fifo buffer and doesn't care who is the
reader.
that means no reliable fullduplex communication.

But I'm still curious if Paul's read() and write() wrapper is faster
than opening the fifo, and then remap the fifo to a unix domain socket via
dup2() ?

Maybe one could say: what if I issue many read()/write()s to other
filedescriptors ?
In this case the read()/write() wrapper would execute the 
if(fd == read_pipe) every time.
I don't know almost nothing about the efficiency of unix domain sockets,
and if they are implemented by using 2 ring buffers to implement
fullduplex communication ( SOCK_STREAM).

Any thoughts ?

regards,
Benno.

From - Sun Oct 10 22:32:51 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA06458
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 20:43:23 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA15494 for linux-audio-dev-list; Sat, 9 Oct 1999 20:24:46 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA15491 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 20:24:41 -0400
Received: from linuxhost.localdomain (IDENT:root@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id CAA15263;
	Sun, 10 Oct 1999 02:19:42 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id EAA01270;
	Sun, 10 Oct 1999 04:20:26 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Paul Barton-Davis <pbd@Op.Net>
Subject: Re: [linux-audio-dev] Re: timing issues in a client/server enviroment
Date: Sun, 10 Oct 1999 03:27:39 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca,
        David Olofson <audiality@swipnet.se>
References: <199910092310.TAA01929@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101004202604.00676@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: acfa7ec26b2e5e8dc8aec79a3f78f903

On Sun, 10 Oct 1999, Paul Barton-Davis wrote:

> 
> >An OS that provides only PCM and MIDI drivers is not suitable
> >to provide a powerful and flexible DAW enviroment.
> 
> yes it is. in fact, its precisely why Paris, ProTools and the rest all
> work under Windows :) oh, ok, these are not flexible enough. i
> agree. but this has to do with inter-app communication, not
> *necessarily* access to the device drivers. 

Actually people are used to an all-in-one enviroment provided by
a specified hw/sw platform.
For some people the all-in-one hw/sw can provide enough
flexibility to perform the needed tasks.
But providing alll needed features for all possible users on
a single monolithic application is just impossible.
This is why I am for a  modular design.
In fact actually there is no OS providing this modular DAW enviroment
out of the box (I don't know if BeOS has some of these features).


> 
> >Quasimodo is a nice app with many functions, but it's still a monolithic app,
> >and my foobar wave editor can't use your 24db lowpass filter with a simple 
> >API call.
> 
> thats right. it should use my 24db lowpass filter *plugin*, which
> would happen to be the same one that Quasimodo would use, in some
> future version where Csound compatibility is no longer the crux of the matter.
> 
> >Paul the keyword is "integration", and I think many people are not very
> >satisfied with windozes integration between audio apps,
> 
> Thats true for people who want lots of apps that all talk to the h/w
> at the same time.

Yes but people are realizing that with the increase of CPU/disk power,
the hardware IS actually capable of running more apps simultaneously.

Just as you can run 10 instances of GIMP, you should be able to run
10 instances of Cubase, as long you do not overload the CPU,
since in the latter case there are realtime requirements.

> 
> Thats not true, as far as I can tell, for people who use well-designed
> audio environments.

Agreed, for example Pulsar/Scope could be thought as entirely self-contained,
(except that you need an additional MIDI sequencer app).
It's efficient, and while remaining in the Pulsar/Scope enviroment, very
flexible too.


> 
> >(see for example Seer Reality monopolizes the DirectX PCM audio,
> >that means if you want to play your mp3 on your 2nd soundcard, you can't)
> 
> part of that problem is just braindead design. Seer are not alone in
> this - even the wonderful Bill Schottstaedt wrote his sndlib() code to
> open /dev/dsp when the library initializes, even though it will likely
> not use it!

Yes, braindead design is one issue, but ofter the limiting factor is the
host's API, which doesn't make any assumption about concurrent execution
of several apps.

> 
> >and if we are able to come up with a good standard,
> >I'm sure that many will have valid reasons to switch.
> 
> i agree entirely. i just don't want the model of Linux audio to push
> the existence of "direct access" to the PCM and MIDI ports out of the
> picture, because for some, this is the right model.

Agreed, and with my proposed method it's very easy to do:
just tell the audioserver to release the device resources and let
the app doing his direct access.
I see no proble here.
I don't want to force audio apps to use our api,
I say only that IF the app uses our API then there are LOTS of benefits,
(routing, syncing, plugins etc.)

> 
> two context switches per delivery of data is just silly, for some things.

actually the number is much lower:
assume there are 5 apps (which uses our API via shmem) which do
PCM output and the audio server mixing together the audio streams
outputting the result to the DAC.


assume the server is just playing a fragment and blocks on the write().
-context switch 1
client1 does his DSP computations,then writes to shmem, and then
waits for an ACK from the server (via message queue or semaphore).
-context switch 2
client2 gets the CPU , same behaviour as in the client1 case
..
..
-context switch 5
client 5 gets the CPU
- context switch 6
  server wakes up because the write() of the audio fragment is done
  now the server wakes up all the clients by sending a message (or changing
the state of the semaphore) to each client
server mixex toghether the PCM data from the shared mem buffers and 
issues the write() to the PCM device.
now we are in the initial case again.

As you see:
5 clients running + 1 audioserver = 6 context switches, seems pretty ideal eh ?
:-)

I even thought about  the fullduplex case:
in one of my previous postings I proposed a solution where
there is only 1 sync point for the entire client/server cycle.
that means clients and server exchange input AND output buffers simultaneously.
that means if you run 5 fullduplex clients + 1 audio servers 
you get still only 6 context switches.

The only drawback is that the minimum latency is 3 fragments opposed to 2
fragments in a monolithic , non client/server app like:
while(1)
{
  read from ADC   (blocking)
  do_processing
   write to DAC    (blocking)
}   

But even in this case you have to take into account the scheduling jitter +
do_processing which consumes almost 100% of the CPU,
that means the minimum reliable latency is 3 fragments (input-to-output).


still not convinced ?
Do you remember when I benchmarked msgsnd()/msgrcv() ?
about 20-25usecs (on PII400) round-trip time between 2 threads.
(2 context switches (since msgsnd() is non blocking) + 2 msgsnd() + 2 msgrcv()
).

Assume: we run 5 soft-synths + audioserver with 1ms fragment granularity:
we need 6 context switches ( max 60-75usec).
Which is about 5-7% CPU overhead.
If you increase the fragment size to 3ms , the overhead goes down to 1%.
Davids sample accurate event system would still provide exact timing,
and at 3ms the latency would still be much better than on other OSes / hw-boxes.

Just as David said: if you need ultra-low-latency the CPU overhead is
unavoidable.

And I think having N fullduplex apps running with the need of only
N+1 context switches per DSP cycle isn't that bad.
(actually it's the theoretical minimum)
:-)

> 
> i would rather have a defined method by which any application can talk
> to any other application, and either of them might actually own the
> device nodes. you could start up a DAW, and *it* would be the engine,
> accepting data from other sources, or you could start up a replacement
> for esd, and *it* would do the same thing, etc. i don't want to force
> programs into using something other than the Unix file interface if
> they believe they want to use it.

With my model I don't make this enforcement, see above.

> 
> --p

Hmm, I partly disagree, because the DAW app has provide all the audio server
functionality.
there are 2 solutions:
1) the app implements his own "server" which is rather silly since you are
reinventing the wheel.

2) the app calls our audio server, but then we are in my proposed case.
:-)

regards,
Benno.

From - Sun Oct 10 22:33:05 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA17728
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 22:42:55 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA15733 for linux-audio-dev-list; Sat, 9 Oct 1999 22:21:21 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA15730 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 22:21:18 -0400
Received: from localhost.localdomain (d212-151-58-181.swipnet.se [212.151.58.181]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id EAA17160; 
          Sun, 10 Oct 1999 04:16:37 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Benno Senoner <sbenno@gardena.net>, Paul Barton-Davis <pbd@Op.Net>
Subject: Re: [linux-audio-dev] Re: timing issues in a client/server enviroment
Date: Sun, 10 Oct 1999 04:13:44 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <199910092310.TAA01929@renoir.op.net> <99101004202604.00676@linuxhost.localdomain>
In-Reply-To: <99101004202604.00676@linuxhost.localdomain>
MIME-Version: 1.0
Message-Id: <9910100423220E.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id EAA17160
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id WAA17728
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b194a3d610ccf68ec2be0bcafa66d28e

On Sun, 10 Oct 1999, Benno Senoner wrote:
[...]
> Hmm, I partly disagree, because the DAW app has provide all the audio server
> functionality.
> there are 2 solutions:
> 1) the app implements his own "server" which is rather silly since you are
> reinventing the wheel.

Actually, the idea is that serving clients shouldn't be all that
different from hosting plug-ins. (The communication is asyncronous,
at least to some extent, as opposed to done through a callback.) And
if you have the client/server port for communication anyway, it should
basically be a matter of implementing the init events that clients
will send when they want to use your services. Or; clients and
servers are pretty similar.

> 2) the app calls our audio server, but then we are in my proposed case.
> :-)

Well, there's the client side of the API, if you want to hack some
cool bonus features (read: server) in as well. :-)


//David


PS. This isn't looking complex, is it? ;-)


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:32:55 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA07053
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 20:50:03 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA15515 for linux-audio-dev-list; Sat, 9 Oct 1999 20:31:36 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA15512 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 20:31:33 -0400
Received: from linuxhost.localdomain (IDENT:root@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id CAA15351;
	Sun, 10 Oct 1999 02:26:41 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id EAA01384;
	Sun, 10 Oct 1999 04:27:25 +0200
From: Benno Senoner <sbenno@gardena.net>
To: est@hyperreal.org
Subject: [linux-audio-dev] Re: fifos & unix domain sockets
Date: Sun, 10 Oct 1999 04:21:05 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <19991010000048.19694.qmail@hyperreal.org>
MIME-Version: 1.0
Message-Id: <99101004272505.00676@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: bddacc0247b99c08adc20bf1d19c9534

On Sun, 10 Oct 1999, est@hyperreal.org wrote:
> Benno Senoner discourseth:
> > 
> > Seems like the fifo uses one single fifo buffer and doesn't care who is the
> > reader.
> 
> Correct. :)
> 
> > that means no reliable fullduplex communication.
> 
> Emphatically correct. :)
> 
> > I don't know almost nothing about the efficiency of unix domain sockets,
> > and if they are implemented by using 2 ring buffers to implement
> 
> I tested their throughput a couple of months ago on Linux.  They were
> about 1.55 times slower than pipes/fifos.  A tcp connection on the
> same machine was 1.6 times slower still (i.e., 2.5 times slower than
> pipes/fifos).
> 
> Eric

ah, good to know !
but how did you compare the fifos to unix sockets ?

make sure that you compare 2 FIFOs (for fullduplex)
to 1 socket.
Because fullduplex communication requires more context switches.

I think a fair comparison is run the following code
for FIFO performance testing:

process A:
while(1)
{
  write data to pipe1
  read data from pipe2
}

process B:
while(1)
{
  read data from pipe1
  write data to pipe2
}

and for the unix socket case you should run:

process A:
while(1)
{
  write data to socket
  read data from socket
}

process B:
while(1)
{
  read data from socket
  write data to socket
}


Am I missing something ?
naaahh 
:-)

regards,
Benno.

From - Sun Oct 10 22:33:07 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA19546
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 23:03:02 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA15763 for linux-audio-dev-list; Sat, 9 Oct 1999 22:42:51 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA15760 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 22:42:48 -0400
Received: from localhost.localdomain (d212-151-100-247.swipnet.se [212.151.100.247]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id EAA29275; 
          Sun, 10 Oct 1999 04:38:05 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Benno Senoner <sbenno@gardena.net>,
        Benjamin GOLINVAUX <golinvaux@benjamin.net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] non-destructive editing
Date: Sun, 10 Oct 1999 04:26:20 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <99100923545108.00456@localhost.localdomain> <99101004420106.00676@linuxhost.localdomain>
In-Reply-To: <99101004420106.00676@linuxhost.localdomain>
MIME-Version: 1.0
Message-Id: <9910100442160F.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id EAA29275
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id XAA19546
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c44f7271b810aa06e56b97efcb72e94d

On Sun, 10 Oct 1999, Benno Senoner wrote:
> On Sat, 09 Oct 1999, David Olofson wrote:
> 
> > 
> > You can measure average seek time and sustained transfer rate individually, and
> > then calculate the buffer size as a function of the number of tracks, and the
> > data rate/track.
> > 
> > Keep in mind that the shorter the benchmark is, the greater the risk that
> > you're measuring the average rather than the worst case. And only the worst
> > case is relevant if you need high reliability...
> 
> but worst case could be very very bad, if you take into account that the user
> could fire up netscape (from the same disk) during your recording session.
> :-)

But if he does that on a single HD system, he had it coming
anyway...! :-)

> > > BTW, I know they were running OS/9 or something like that which seems to be
> > > some kind of UNIX-like OS... Can someone provide details on it just for the 
> > > fun ?
> > > (there might be some kind of Ingo's patch for Fairlight OS that must have 
> > > been 
> > > devised back in the eighties ;-)
> > 
> > QNX is another example of an OS used for that kind of stuff. They're dedicated
> > real time operating systems from the ground up, and don't need patches to get
> > that kind of performance.
> 
> Ok QNX is a nice realtime OS, but actually I see no advantages by using it in
> a highperf multimedia enviroments, since if you get below the 32samples/fragment
> mark the inherent CPU overhead increases (OS can't help here) exponentially,
> not to mention that QNX has to perform a context switch (because it's
> a microkernel ) when you do some syscall() in your short dsp loop,
> and full context switches at >1kHz rates HURT A LOT !
> :-)

Yep, but in this case, I was just pointing out the very significant
difference between an RTOS and a non-RT OS...

> PS: the cygnus embedded linux (RTOS with selectable features at compile time) 
> seems to be very interesting, since you can leave out the uneeded stuff,
> and maybe get even better than QNX since it's not microkerneled.

Well, QNX has very fast context switches, but they're still full
context switches. RTL is on par with the fastest RTOSes around
AFAIK, BUT, many of those have protected memory, as opposed to RTL...

> Linux seems to hurt even  commercial RTOS vendors quite a bit these days.
> :-) 

Yes, appart from the excellent performance, it's truly Free/Open
Source, which is invaluable to companies that can't risk relying on a
single RTOS vendor, or need to hack special features into the kernel.
And of course, there's no $1500 per-copy royalty...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:33:01 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA08379
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 21:04:51 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA15557 for linux-audio-dev-list; Sat, 9 Oct 1999 20:46:13 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA15554 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 20:46:10 -0400
Received: from linuxhost.localdomain (IDENT:root@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id CAA15470;
	Sun, 10 Oct 1999 02:41:17 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id EAA01423;
	Sun, 10 Oct 1999 04:42:01 +0200
From: Benno Senoner <sbenno@gardena.net>
To: David Olofson <audiality@swipnet.se>,
        Benjamin GOLINVAUX <golinvaux@benjamin.net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] non-destructive editing
Date: Sun, 10 Oct 1999 04:31:00 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <99100923545108.00456@localhost.localdomain>
MIME-Version: 1.0
Message-Id: <99101004420106.00676@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b4d16c2af290874598beebc77054a617

On Sat, 09 Oct 1999, David Olofson wrote:

> 
> You can measure average seek time and sustained transfer rate individually, and
> then calculate the buffer size as a function of the number of tracks, and the
> data rate/track.
> 
> Keep in mind that the shorter the benchmark is, the greater the risk that
> you're measuring the average rather than the worst case. And only the worst
> case is relevant if you need high reliability...

but worst case could be very very bad, if you take into account that the user
could fire up netscape (from the same disk) during your recording session.
:-)

> 
> > BTW, I know they were running OS/9 or something like that which seems to be
> > some kind of UNIX-like OS... Can someone provide details on it just for the 
> > fun ?
> > (there might be some kind of Ingo's patch for Fairlight OS that must have 
> > been 
> > devised back in the eighties ;-)
> 
> QNX is another example of an OS used for that kind of stuff. They're dedicated
> real time operating systems from the ground up, and don't need patches to get
> that kind of performance.

Ok QNX is a nice realtime OS, but actually I see no advantages by using it in
a highperf multimedia enviroments, since if you get below the 32samples/fragment
mark the inherent CPU overhead increases (OS can't help here) exponentially,
not to mention that QNX has to perform a context switch (because it's
a microkernel ) when you do some syscall() in your short dsp loop,
and full context switches at >1kHz rates HURT A LOT !
:-)

PS: the cygnus embedded linux (RTOS with selectable features at compile time) 
seems to be very interesting, since you can leave out the uneeded stuff,
and maybe get even better than QNX since it's not microkerneled.

Linux seems to hurt even  commercial RTOS vendors quite a bit these days.
:-) 

regards,
Benno.

From - Sun Oct 10 22:33:02 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA08938
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 21:11:06 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA15576 for linux-audio-dev-list; Sat, 9 Oct 1999 20:52:47 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA15573 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 20:52:44 -0400
Received: from linuxhost.localdomain (IDENT:root@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id CAA15527;
	Sun, 10 Oct 1999 02:47:52 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id EAA01431;
	Sun, 10 Oct 1999 04:48:36 +0200
From: Benno Senoner <sbenno@gardena.net>
To: David Olofson <audiality@swipnet.se>, Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: timing issues in a client/server enviroment
Date: Sun, 10 Oct 1999 04:42:53 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <9910100226540B.00456@localhost.localdomain>
MIME-Version: 1.0
Message-Id: <99101004483607.00676@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 90f6aadcbc5c4792be63b2f2e4cc811f

On Sun, 10 Oct 1999, David Olofson wrote:
> On Sun, 10 Oct 1999, Benno Senoner wrote:
> [...]
> > Quasimodo is a nice app with many functions, but it's still a
> > monolithic app, and my foobar wave editor can't use your 24db
> > lowpass filter with a simple API call.
> 
> Actually, it could with the client/server/plug-in API I'm trying to
> describe, provided Quasimodo publishes it's plug-ins, accepts your
> connection request. But latency would of course increase with the
> number of client/server interface layers involved... And simple?
> 
> > My idea is an engine ( userspace or RTLinux) , which handles the whole thing.
> > It could be similar to quasimodo, but in form of an engine, with flexible
> > routing, sample accurate evet processing, syncing etc.
> 
> That can be done quite transparently through the API (client and
> plug-ins are very similar), but as I said, latency...
> 
> 

Seems that you are wrong about latency:
see my previous post ...
When I get some time I will implement my simple client/server model,
and run for example 5 clients which generate some audio (of course consuming
some CPU to simulate DSP computations) , with the server mixing together the
results. All with 2-3ms latency without dropouts (on the lowlatency kernel),
 WHILE you are surfing the web.
:-)

Ok there is a limt of the number of simultaneous clients,
but most of time you will run out of CPU power due to dsp computations,
rather than due to scheduling overhead.
5 clients with 1ms fragments = 6% overhead
5 clients with 2ms fragments = 3% overhead

regards,
Benno.

From - Sun Oct 10 22:33:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA20660
	for <slinkp@ulster.net>; Sat, 9 Oct 1999 23:16:17 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA15777 for linux-audio-dev-list; Sat, 9 Oct 1999 22:54:09 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA15774 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 9 Oct 1999 22:54:06 -0400
Received: from localhost.localdomain (d212-151-100-247.swipnet.se [212.151.100.247]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id EAA24826; 
          Sun, 10 Oct 1999 04:49:25 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Benno Senoner <sbenno@gardena.net>, Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: timing issues in a client/server enviroment
Date: Sun, 10 Oct 1999 04:45:55 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <9910100226540B.00456@localhost.localdomain> <99101004483607.00676@linuxhost.localdomain>
In-Reply-To: <99101004483607.00676@linuxhost.localdomain>
MIME-Version: 1.0
Message-Id: <9910100456150G.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id EAA24826
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id XAA20660
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 74b8e2cac63f450e4d04f9be36bc396b

On Sun, 10 Oct 1999, Benno Senoner wrote:
> On Sun, 10 Oct 1999, David Olofson wrote:
> > On Sun, 10 Oct 1999, Benno Senoner wrote:
> > [...]
> > > Quasimodo is a nice app with many functions, but it's still a
> > > monolithic app, and my foobar wave editor can't use your 24db
> > > lowpass filter with a simple API call.
> > 
> > Actually, it could with the client/server/plug-in API I'm trying to
> > describe, provided Quasimodo publishes it's plug-ins, accepts your
> > connection request. But latency would of course increase with the
> > number of client/server interface layers involved... And simple?
> > 
> > > My idea is an engine ( userspace or RTLinux) , which handles the whole thing.
> > > It could be similar to quasimodo, but in form of an engine, with flexible
> > > routing, sample accurate evet processing, syncing etc.
> > 
> > That can be done quite transparently through the API (client and
> > plug-ins are very similar), but as I said, latency...
> > 
> > 
> 
> Seems that you are wrong about latency:
> see my previous post ...
> When I get some time I will implement my simple client/server model,
> and run for example 5 clients which generate some audio (of course consuming
> some CPU to simulate DSP computations) , with the server mixing together the
> results. All with 2-3ms latency without dropouts (on the lowlatency kernel),
>  WHILE you are surfing the web.
> :-)

Ok, but in this case, you would be sitting in the middle, with
Quasimodo as an engine on one side, and the central audio engine on
the other... That is, two sync points instead of one.

Unless either you or Quasimodo actually *is* the central audio
engine, doing direct device access, or you delegate all audio
processing to Quasimodo or the audio engine. But the point was to
use a plug-in in one engine from another application, and I assumed
that both would be clients from the central audio engine's POV...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:33:12 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA25311
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 00:33:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA15868 for linux-audio-dev-list; Sun, 10 Oct 1999 00:11:10 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA15864 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 00:11:06 -0400
Received: from someip.ppp.op.net (d-bm3-1c.ppp.op.net [209.152.194.92]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id AAA15959 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 00:06:28 -0400 (EDT)
Message-Id: <199910100406.AAA15959@renoir.op.net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] API design again [MORE code] 
In-reply-to: Your message of "Sun, 10 Oct 1999 02:52:03 +0200."
             <9910100400410D.00456@localhost.localdomain> 
Date: Sun, 10 Oct 1999 00:07:00 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0169de4392edb2dfce6a9ace05cf086f

>[...]
>> So the event is now queued in my local event port. What causes it to
>> become available to the engine, and thus get delivered to the plugins?
>
>The one sync point that your malicious example is trying to avoid! ;-)
>
>At some point, you have to tell the engine to "grab" the new events,
>and that will need to be a sync point of some kind... possibly a FIFO
>where the address of the "news" (first event in a linked list, or
>whatever it'll be in the end) is passed.

>In the case of audio streaming, the natural sync point is the end of
>the buffer cycle, and your thread will sleep there, or on the start
>of the cycle, if the client gets data from the engine as well.

absolutely not! one thread sleeping on another's thread activity is
death for the kind of response we want. also, since neither select nor
poll unify file descriptors with either msgsend and/or user-space
condition variables, it makes programming much harder.

but thats OK, we can still do this.

So, lets try to clarify this. Since the MIDI input thread can't mess
with the engine thread's data structures, what has to happen, as far
as I can see, is that the MIDI input thread has to tell the engine
thread to listen to its event port. So far, so good, since this is
basically what you describe above.

Next step: the engine finishes a control cycle, and sets about
preparing events to deliver to plugins for the next cycle. Presumably
it iterates over some list of event ports or FIFO or whatever that it
has been told to listen to. So far, so good.

But wait - how is the engine thread going to safely copy or otherwise
use this data when the MIDI input thread (or any other h/w-driven
thread) could modify the port's event list at any time ?

this, it seems, is where we might be able to use a lock free queue. we
have exactly one writer and one reader per queue, making them OK for
the kind of logic that Eli Brandt outlined (which was thankfully not
a Herlihy-like compare-and-swap system). as Eli pointed out, this
does rely on pointer writes being atomic and surrounding writes not
being reordered, which we can probably ensure.

so, the MIDI input thread can *append* its own event queue (if tail is
beyond head), but it cannot do anything to it the engine thread can
*pop* items from the front of the queue if the head is behind the
tail, but it cannot do anything else to it.

---------------------------------------------------

so here's some pseudo code to summarize what i understand so far:

notice that the use of '<' and '>' to test for head/tail
relations are nominal, not actual C code. if we could use fixed size
arrays of event_t's, then we could actually use '<' and '>', but this
seems unlikely to satisfy us.

MIDI input thread:
=================

     while (1) {
     
         ... set up fd_set ...
	 select (...);

	 timestamp = engine->timestamp ();

	 if (ISSET(&readable_fds, midi_port_fd)) {

               read_midi_data_from (midi_port_fd);
	       ... parse data ...

	       foreach event to be generated from data {
 	            event_t *ev;

               	    ev = qm_alloc_event (my_event_port->heap, ...);
	            ev->timestamp = timestamp;
	            ... fill out rest of ev ...
	            if (my_event_port->events_tail > 
		        my_event_port->events_head)
  	                   my_event_port->events_tail->next = ev;
	            } else {
		      /* what ? */
		    }
	       }
         }
     }  

Engine thread:
=============

     while (1) {

           lock (listen_lock); /* prevent any new ports being added
	                          while we traverse the listen list.
			        */

           foreach event_port_t subscribed to {

	        event_t *current_tail;

		/* notice where the end of the event list for the port
		   is right now, so that all plugins get the same set
		   of events during this cycle.
		 */

		 current_tail = event_port->events_tail;

		 foreach port in event_port->subscriber_list
	            event_t *ev;
		      
		    ev = event_port->events_head;
	            while (ev < current_tail) {

		          /* hmm - can this ever be false ? and
			     what would we do if it was ?
			   */

		          if (port->events_tail > port->events_head) {
			         port->events_tail = ev;
		          }
		          ev = ev->next;
			  event_port->events_head = ev;
	            }
                }
         }

	 unlock (listen_lock);

	 foreach plugin {
	    plugin->process ();
	 }

	 ... remove all events from each plugin's delivery port ...
	 ... global buffer allocation stuff ...

     }

and thats it. 

out of this come some expanded data structures:

struct event_port_t {
       qm_heap_t *heap;                    /* how to allocate */
       event_port_t *engine_listen_next;   /* link to engine listen list */
       event_port_t *subscriber_head;      /* subscriber list */
       event_port_t *subscriber_tail;      /* subscriber list */
       event_t *event_head;
       event_t *event_tail;
}

struct event_t {
       qm_timestamp_t timestamp;
       .. whatever the hell you want ...
}

and the four functions that forces another thread to take a lock on an
engine data structure:

    event_port_t engine_listen_tail = 0;
    event_port_t engine_listen_head = 0;    

    engine_listen (event_port_t *port)

    {
	   lock (listen_lock);

	   /* possibly skip the conditional having "reserve"
	      element(s) as head (and tail?) of the listen_list.
	    */

	   if (listen_head == 0) {
	      engine_listen_head = port;
	   }
	   engine_listen_tail->next = port;
	   engine_listen_tail = port;
	   unlock (listen_lock);
    }

    engine_unlisten (event_port_t *port)

    {
            event_port_t *prev;
	    event_port_t *p;

	    lock (listen_lock);

	    for (prev = 0, p = engine_listen_head; p; prev = p, p = p->next) {
		if (p == port) {
		   ... remove port from engine_list_next ...
		}
            }

	    unlock (listen_lock);
    }

we also need:

    subscribe (event_port_t *target, event_port_t *subscriber)

    {
         /* the subscriber list is only ever read by the engine
	    thread while it holds the listen_lock. so take it
	    before playing with the subscriber list on the target
	    port. 
	  */

         lock (listen_lock);

         if (!target->subscriber_head) {
	      target->subscriber_tail = subscriber;
	 }

	 target->subscriber_tail = subscriber;

	 unlock (listen_lock);
    }		

    unsubscribe (event_port_t *target, event_port_t *desubscriber)

    {
	 lock (listen_lock);
	 ...
	 unlock (listen_lock);
    }


Final note: we should come up with a new name for things like the MIDI
input thread. They are not plugins, because they run independently of
the engine's control cycle. But they are also candidates for "adding"
to the engine, not necessarily at run time, but perhaps at startup,
and certainly during compilation. One can imagine threads that handle
h/w events from various strange devices (say, the serial port, or some
A-D data acquisition card) etc.

--p

From - Sun Oct 10 22:33:15 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA26294
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 00:52:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA15898 for linux-audio-dev-list; Sun, 10 Oct 1999 00:32:05 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA15895 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 00:32:03 -0400
Received: from someip.ppp.op.net (d-bm3-1c.ppp.op.net [209.152.194.92]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id AAA17069 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 00:27:25 -0400 (EDT)
Message-Id: <199910100427.AAA17069@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] plugin questions 
In-reply-to: Your message of "Sun, 10 Oct 1999 00:24:20 +0200."
             <9910100210190A.00456@localhost.localdomain> 
Date: Sun, 10 Oct 1999 00:27:57 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 71a2ee1b96d4d7163d9ae28e92e51e16

>A while back, I got the idea of adding an init() callback function to
>the plug-in. The intention was that it should eliminate the need for
>a structure with hardcoded info entries, or a set of callbacks. As
>the same API could be used for that, and for the real time event
>system, there would be nothing more than a few event IDs to keep
>track of.

actually, i had always assumed there would be an init() function to
get things set up. but from your later talk about init stuff, its not
clear what you think this function should do.

my model of "init()" would be something that does basic data
initialization on the plugin's own internal data structures. it
doesn't involve the event system at all. 

what do you have in mind ?

You didn't talk about a way to query the engine to see what
event_ports can be subscribed to by a plugin. e.g. "is there a MIDI
input port?"

>3) Buffer size requirements and similar things should be handled
>   through request/reply sequences. (The host/server requests a
>   certain value, and the plug-in/client replies with the
>   closest value it supports.) This is probably one of the most
>   complex parts to get right...

i don't think we should support this. plugins *must* handle any size
buffer. the buffer size should be controllable by the engine, either
once at startup, or during runtime if there is a good reason to do so.

why would allow them to do otherwise ?

>6) Parameters that do not fit in a standard class will have to
>   go into a custom class. The properties of these events must
>   be defined during the init sequence. Custom events should be
>   *avoided* as far as possible, as they effectively eliminate
>   the usefullnes of the event system. (How do you automate
>   a parameter that you don't understand?)

i have a feeling that you are thinking of things a little backwards to
the way i am. my model is that the events that get sent to a plugin
don't say "change parameter N to X". They say "something changed to
Y". Its up to the plugin to decide what that means.

take the ubiquitous cases of (1) an onscreen "knob" and (2) MIDI CC
values. what happens in both cases is:

	(1) the GUI thread sends and event when te knob is turned. It
	    says "this control element just changed its value to 0.345".
	    Any plugin subscribed to that port will get the event, and
	    can decide what to do with it. it might ignore it. it
	    might change its own parameter "foobar" to 0.345, or to
	    0.69, or to 12929209.23. it might post another event. who
	    knows ? who cares ? (one of my 5yr old daughter's favorite
	    lines!)

	(2) the MIDI case is identical, except that the event is generated
	    by the MIDI input thread "this control element just
	    changed its value to 127".

This is modelled, BTW, on the very nice system used by a
gtk_adjustment, and more generally on the purely and sublimely superb
libsigc++.

automation - ah, automation. the first level is not that hard: we just 
record the events in some file, and then play them back. this will
work fine for controlling the plugins. the GUI, which will
need to be controlled since we want the on-screen representation to
show us what the automation system is doing, is a lot more
work. whereas the plugins will get exactly the same kinds of messages
they always do, the GUI will be getting a set of messages that it
normally doesn't get at all. normally, it just reads stuff from (for
the sake of argument) the X server connection. but now, it has a whole
new event stream to deal with, and it has to map them back to its own
world of widgets, etc. 

still, it can be done, its just harder.

so, plugins don't need to publish parameters, or their
characteristics. they just subscribe to available ports, which the
engine must make available.

another optimization just occured to me. to prevent the engine from
having to traverse the entire list of subscribable ports during each
control cycle, there should be a way (preferably lock free, although i
doubt that it can be done) to push a port that is in the "available
for subscription list" into a "has events pending list". that way, for
the vast majority of control cycles, the list to traverse will be
empty!  big win.

--p

From - Sun Oct 10 22:33:17 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA26733
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 01:02:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA15911 for linux-audio-dev-list; Sun, 10 Oct 1999 00:42:13 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA15908 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 00:42:10 -0400
Received: from someip.ppp.op.net (d-bm3-1c.ppp.op.net [209.152.194.92]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id AAA17458 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 00:37:33 -0400 (EDT)
Message-Id: <199910100437.AAA17458@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: timing issues in a client/server enviroment 
In-reply-to: Your message of "Sun, 10 Oct 1999 03:27:39 +0200."
             <99101004202604.00676@linuxhost.localdomain> 
Date: Sun, 10 Oct 1999 00:38:05 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7fa8b234191b9bfa618cdbe0f109a1ed

>> yes it is. in fact, its precisely why Paris, ProTools and the rest all
>> work under Windows :) oh, ok, these are not flexible enough. i
>> agree. but this has to do with inter-app communication, not
>> *necessarily* access to the device drivers. 
>
>Actually people are used to an all-in-one enviroment provided by
>a specified hw/sw platform.
>For some people the all-in-one hw/sw can provide enough
>flexibility to perform the needed tasks.
>But providing alll needed features for all possible users on
>a single monolithic application is just impossible.
>This is why I am for a  modular design.
>In fact actually there is no OS providing this modular DAW enviroment
>out of the box (I don't know if BeOS has some of these features).

its the plugin API that makes this kind of issue go away, and its why
people working with the existing DAW systems don't mind - they feel as
if their system is *not* monolithic - it can run stuff from Waves, TC,
Antares and many others ... "yes, but its just one program" "we don't care!"

being able to add stuff to a program with a truly standard API makes
it non-monolithic. if the program does nothing without plugins, then
its pretty close to the server model you propose.

>Just as you can run 10 instances of GIMP, you should be able to run
>10 instances of Cubase, as long you do not overload the CPU,
>since in the latter case there are realtime requirements.

why would i want to do that ? why does anyone want to run 10 instances
of the GIMP, or even 2 for that matter ? its less efficient, its eats
CPU time, colormaps etc, and buys you *nothing* ! but perhaps i don't
use it enough ... yes, these observations are true for multi-user
hosts, but i don't think thats the context we're operating in.

>Yes, braindead design is one issue, but ofter the limiting factor is the
>host's API, which doesn't make any assumption about concurrent execution
>of several apps.

right, so we have to get the API right. 

>> two context switches per delivery of data is just silly, for some things.
>
>actually the number is much lower:

	  [ ... example elided ... ]

>As you see:
>5 clients running + 1 audioserver = 6 context switches, seems pretty ideal eh 
>?
>:-)

no! its true that your overall throughput is better, and the 
"audio data sent per context switch" is better, but: for any *given*
client, the situation is *much* worse than if it were managing the
device drivers itself.

>Assume: we run 5 soft-synths + audioserver with 1ms fragment granularity:
>we need 6 context switches ( max 60-75usec).
>Which is about 5-7% CPU overhead.
>If you increase the fragment size to 3ms , the overhead goes down to 1%.
>Davids sample accurate event system would still provide exact timing,
>and at 3ms the latency would still be much better than on other OSes / hw-boxe
>s.

if these numbers really turned out to be true, it would work for
me. but i have a feeling that it won't.

>there are 2 solutions:
>1) the app implements his own "server" which is rather silly since you are
>reinventing the wheel.
>
>2) the app calls our audio server, but then we are in my proposed case.

3) the audio server is a library, which any application can link to.
   then we have the best of all possible worlds!

--p

From - Sun Oct 10 22:33:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA26762
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 01:02:42 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA15916 for linux-audio-dev-list; Sun, 10 Oct 1999 00:43:29 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA15913 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 00:43:27 -0400
Received: from someip.ppp.op.net (d-bm3-1c.ppp.op.net [209.152.194.92]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id AAA17490 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 00:38:50 -0400 (EDT)
Message-Id: <199910100438.AAA17490@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc. 
In-reply-to: Your message of "Sun, 10 Oct 1999 03:00:33 +0200."
             <99101003222603.00676@linuxhost.localdomain> 
Date: Sun, 10 Oct 1999 00:39:22 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c023fb4f0453d59f070467737bd6cceb

>Maybe one could say: what if I issue many read()/write()s to other
>filedescriptors ?
>In this case the read()/write() wrapper would execute the 
>if(fd == read_pipe) every time.

you're about to make a system call, and you're worrying about the cost
of a conditional ?

--p

From - Sun Oct 10 22:33:21 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id CAA29656
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 02:09:58 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id BAA19785 for linux-audio-dev-list; Sun, 10 Oct 1999 01:39:32 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA19782 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 01:39:29 -0400
Received: from localhost.localdomain (d212-151-41-250.swipnet.se [212.151.41.250]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id HAA01180; 
          Sun, 10 Oct 1999 07:34:48 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] API design again [MORE code]
Date: Sun, 10 Oct 1999 06:42:56 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910100406.AAA15959@renoir.op.net>
In-Reply-To: <199910100406.AAA15959@renoir.op.net>
MIME-Version: 1.0
Message-Id: <9910100741370H.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id HAA01180
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id CAA29656
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 77734c31afb2172a2e950d36caa39dc2

On Sun, 10 Oct 1999, Paul Barton-Davis wrote:
[...]
> >In the case of audio streaming, the natural sync point is the end of
> >the buffer cycle, and your thread will sleep there, or on the start
> >of the cycle, if the client gets data from the engine as well.
> 
> absolutely not! one thread sleeping on another's thread activity is
> death for the kind of response we want. also, since neither select nor
> poll unify file descriptors with either msgsend and/or user-space
> condition variables, it makes programming much harder.

That's effectively what happens when a client communicates with a
server; it needs to sleep at some point, or it will hang the
system... :-) But the select/poll probleb is of course valid. The
system isn't really as flexible after all...

> but thats OK, we can still do this.
> 
> So, lets try to clarify this. Since the MIDI input thread can't mess
> with the engine thread's data structures, what has to happen, as far
> as I can see, is that the MIDI input thread has to tell the engine
> thread to listen to its event port. So far, so good, since this is
> basically what you describe above.

Yes. That's what happens when the Communication System sets up the
shadow port.

> Next step: the engine finishes a control cycle, and sets about
> preparing events to deliver to plugins for the next cycle. Presumably
> it iterates over some list of event ports or FIFO or whatever that it
> has been told to listen to. So far, so good.
> 
> But wait - how is the engine thread going to safely copy or otherwise
> use this data when the MIDI input thread (or any other h/w-driven
> thread) could modify the port's event list at any time ?

You don't do that. Once an event is "posted", it is considered
property of the destination context. And the event data is going
nowhere until the buffer is flushed. You allocate memory, fill in the
event_t, and add it to the list.

Actually, there's one more level; the transfer of the finished list
of events (for the cycle) to the destination port.

> this, it seems, is where we might be able to use a lock free queue. we
> have exactly one writer and one reader per queue, making them OK for
> the kind of logic that Eli Brandt outlined (which was thankfully not
> a Herlihy-like compare-and-swap system). as Eli pointed out, this
> does rely on pointer writes being atomic and surrounding writes not
> being reordered, which we can probably ensure.

Yep. I'd suggest that the "finish cycle" operation does something
like this:

1) Send the new events off through the lock free queue. From now
   on, it is strictly forbidden to modify the events.

2) Flush the event port. (That is, *not* the heap! The buffer
   that now holds the new events can safely be used for further
   allocation, as that will only result in the life time of the
   buffer being extended.)

The heap is still safe to use, but any new events we send to the
shadow port will be added to a new list, and won't affect the sent
events that happen to be in the buffer that still belongs to our
context.

> so, the MIDI input thread can *append* its own event queue (if tail is
> beyond head), but it cannot do anything to it the engine thread can
> *pop* items from the front of the queue if the head is behind the
> tail, but it cannot do anything else to it.

Well, that's the definition of a FIFO, I'd say...

> ---------------------------------------------------
> 
> so here's some pseudo code to summarize what i understand so far:
> 
> notice that the use of '<' and '>' to test for head/tail
> relations are nominal, not actual C code. if we could use fixed size
> arrays of event_t's, then we could actually use '<' and '>', but this
> seems unlikely to satisfy us.
> 
> MIDI input thread:
> =================
> 
>      while (1) {
>      
>          ... set up fd_set ...
> 	 select (...);
> 
> 	 timestamp = engine->timestamp ();
> 
> 	 if (ISSET(&readable_fds, midi_port_fd)) {
> 
>                read_midi_data_from (midi_port_fd);
> 	       ... parse data ...
> 
> 	       foreach event to be generated from data {
>  	            event_t *ev;
> 
>                	    ev = qm_alloc_event (my_event_port->heap, ...);
> 	            ev->timestamp = timestamp;
> 	            ... fill out rest of ev ...
> 	            if (my_event_port->events_tail > 
> 		        my_event_port->events_head)
>   	                   my_event_port->events_tail->next = ev;
> 	            } else {
> 		      /* what ? */
> 		    }

...or you can add all events to the list of the shadow event port, and
then just finish_cycle(my_event_port) to send the list off to the
engine. The engine will never see the shadow port at all - only the
code that gathers new events from the queues is aware of the fact
that the events actually come from a different thread.

What I proposed earlier was just to wake up the MIDI thread an extra
time to perform this operation once per engine cycle, rather than
doing finish_cycle() for every event, or every timestamp. With shared
memory and lock free queues it doesn't make much difference, but if
would in other settings...

[...engine thread...]
> and thats it. 

Yep, pretty much what I had in mind.

> out of this come some expanded data structures:
> 
> struct event_port_t {
>        qm_heap_t *heap;                    /* how to allocate */
>        event_port_t *engine_listen_next;   /* link to engine listen list */
>        event_port_t *subscriber_head;      /* subscriber list */
>        event_port_t *subscriber_tail;      /* subscriber list */
>        event_t *event_head;
>        event_t *event_tail;
> }

Hmmm... Maybe at least some of these should be hidden in the private
parts of the implementation. (They will probably look different for
non-shared memory connections and other weird things...)

> Final note: we should come up with a new name for things like the MIDI
> input thread. They are not plugins, because they run independently of
> the engine's control cycle. But they are also candidates for "adding"
> to the engine, not necessarily at run time, but perhaps at startup,
> and certainly during compilation. One can imagine threads that handle
> h/w events from various strange devices (say, the serial port, or some
> A-D data acquisition card) etc.

It fits my idea of a client... The most significant difference from a
plug-in is that it has it's own thread, and runs whenever it wants.
Same data structures but a different communication scheme.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:33:23 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id CAA31297
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 02:53:37 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id CAA19846 for linux-audio-dev-list; Sun, 10 Oct 1999 02:23:57 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA19843 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 02:23:54 -0400
Received: from localhost.localdomain (d212-151-41-250.swipnet.se [212.151.41.250]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id IAA16267; 
          Sun, 10 Oct 1999 08:19:09 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] plugin questions
Date: Sun, 10 Oct 1999 07:42:51 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910100427.AAA17069@renoir.op.net>
In-Reply-To: <199910100427.AAA17069@renoir.op.net>
MIME-Version: 1.0
Message-Id: <9910100825580I.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id IAA16267
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id CAA31297
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d9e8c8003e996aceb886458a7f72f6e9

On Sun, 10 Oct 1999, Paul Barton-Davis wrote:
> >A while back, I got the idea of adding an init() callback function to
> >the plug-in. The intention was that it should eliminate the need for
> >a structure with hardcoded info entries, or a set of callbacks. As
> >the same API could be used for that, and for the real time event
> >system, there would be nothing more than a few event IDs to keep
> >track of.
> 
> actually, i had always assumed there would be an init() function to
> get things set up. but from your later talk about init stuff, its not
> clear what you think this function should do.
> 
> my model of "init()" would be something that does basic data
> initialization on the plugin's own internal data structures. it
> doesn't involve the event system at all. 
> 
> what do you have in mind ?

It should do both. The event system is used instead of the
structures or callbacks that many other plug-in APIs use.

> You didn't talk about a way to query the engine to see what
> event_ports can be subscribed to by a plugin. e.g. "is there a MIDI
> input port?"

#ifdef	UNOFFICIAL
#define	MCS	"Multimedia Communication System"
#endif

That should be a part of the MCS, I think... That is, I want a
distinction here, as you should be able to run a system with no
engine at all. The MCS should provide a client/server API, *and* a
way for clients and servers to find each other in the system.

An engine that wants to make plug-ins accessible for external
automation, or a kernel driver package that wants to provide some
services, should act as a gateway, allowing their local plug-ins to
act as clients in the system.

I think that building the necessary protocols on top of the event
system will make this more flexible and useful, as it has an inherent
recursive nature.

> >3) Buffer size requirements and similar things should be handled
> >   through request/reply sequences. (The host/server requests a
> >   certain value, and the plug-in/client replies with the
> >   closest value it supports.) This is probably one of the most
> >   complex parts to get right...
> 
> i don't think we should support this. plugins *must* handle any size
> buffer. the buffer size should be controllable by the engine, either
> once at startup, or during runtime if there is a good reason to do so.
> 
> why would allow them to do otherwise ?

DSP code optimization. If the algorithm really *needs* a certain
buffer size granularity, and the engine don't give a damn, the plug-in
can only handle it by doing it's own internal buffering, which means
copying. The engine can just adjust the buffer size to the best
alternative that fist all plug-ins in the sub net, or put the plug-in
in a sub net of it's own. That means that the buffer size adaption
can be done without copying overhead, and without extra code and
buffers in the plug-in.

> >6) Parameters that do not fit in a standard class will have to
> >   go into a custom class. The properties of these events must
> >   be defined during the init sequence. Custom events should be
> >   *avoided* as far as possible, as they effectively eliminate
> >   the usefullnes of the event system. (How do you automate
> >   a parameter that you don't understand?)
> 
> i have a feeling that you are thinking of things a little backwards to
> the way i am. my model is that the events that get sent to a plugin
> don't say "change parameter N to X". They say "something changed to
> Y". Its up to the plugin to decide what that means.

The only difference is that my plug-ins actually tell you during
init what events they care about. We could actually do it like VST;
force every parameter to be a float between 0.0 and 1.0, and support
nothing else. That eliminates the need for control event classes.

> automation - ah, automation. the first level is not that hard: we just 
> record the events in some file, and then play them back. this will
> work fine for controlling the plugins. the GUI, which will
> need to be controlled since we want the on-screen representation to
> show us what the automation system is doing, is a lot more
> work. whereas the plugins will get exactly the same kinds of messages
> they always do, the GUI will be getting a set of messages that it
> normally doesn't get at all. normally, it just reads stuff from (for
> the sake of argument) the X server connection. but now, it has a whole
> new event stream to deal with, and it has to map them back to its own
> world of widgets, etc. 
> 
> still, it can be done, its just harder.

No way around that, not without getting 99% GUI dependent, I'm
afraid...

> so, plugins don't need to publish parameters, or their
> characteristics. they just subscribe to available ports, which the
> engine must make available.

I don't like that since I don't think connection management belongs
in the plug-in code, and I do think that it's a good idea to be able
to tell what a plug-in actually cares about. And the characteristics
*have* to be published one way or another, or you're forced to use
the plug-in's custom GUI for the values to make any sense.

> another optimization just occured to me. to prevent the engine from
> having to traverse the entire list of subscribable ports during each
> control cycle, there should be a way (preferably lock free, although i
> doubt that it can be done) to push a port that is in the "available
> for subscription list" into a "has events pending list". that way, for
> the vast majority of control cycles, the list to traverse will be
> empty!  big win.

It's possible. Push the address (or some handle) of the ports that
you write onto a single queue. Then the engine just looks there to
see what's happened since last time around. You still need to check
one queue per thread/thread connection, as the queues are single
writer. Still a lot better than checking every single event port
every time, though.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:33:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id EAA02638
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 04:44:34 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id EAA19961 for linux-audio-dev-list; Sun, 10 Oct 1999 04:18:25 -0400
Received: from mail.cid.net (cephyr.cid.net [195.35.45.193]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA19958 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 04:18:22 -0400
Received: from uucp by mail.cid.net (Exim 2.11) with local-bsmtp
	id 11aE70-0002u4-00; Sun, 10 Oct 1999 10:13:46 +0200
Received: from deneb.cygnus.argh.org ([192.168.1.2] ident=root)
	by cygnus.argh.org with esmtp (Exim 3.02 #1)
	id 11aDh7-0000TD-00; Sun, 10 Oct 1999 09:47:01 +0200
Received: from fw by deneb.cygnus.argh.org with local (Exim 3.02 #1)
	id 11aCDQ-0000fE-00; Sun, 10 Oct 1999 08:12:16 +0200
To: thudson@cygnus.com
Cc: David Olofson <audiality@swipnet.se>, Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway
References: <199910081437.KAA03841@renoir.op.net> <99100903213901.00599@localhost.localdomain> <37FF6573.2290BA63@cygnus.com>
From: Florian Weimer <fw@deneb.cygnus.argh.org>
Date: 10 Oct 1999 08:12:16 +0200
In-Reply-To: thudson@cygnus.com's message of "Sat, 09 Oct 1999 11:55:31 -0400"
Message-ID: <87puynrbgf.fsf@deneb.cygnus.argh.org>
Lines: 26
User-Agent: Gnus/5.07009701 (Pterodactyl Gnus v0.97.1) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: de7b3de358e78d7b0d2689bfd2f3262b

thudson@cygnus.com writes:

> There was an interesting file manager on the SGI that had a slider that
> allowed one to zoom in and out of the view. I think the now defunct
> Fresco allowed similar transformations of widgets. 

Yep.

> They widgets were still active and usable in their shrunken
> state. There was an example of a scaled and rotated copy of a
> drawing program pasted in another copy of itself. The pasted copy
> was still fully functional.

Although this was very nice, the basic concept of Fresco (everything
is built of flyweight objects to which any affine transformation can
be applied) resulted in rather slow GUI operation---even on today's
machines, scrolling seems to be somewhat sluggish, perhaps because
most optimizations normally used to speed up common operations don't
fit into this scheme.

BTW, the Berlin Project is employing some Fresco ideas, and InterViews
3.x (which featured the first implementation of the flyweight pattern
for GUIs, AFAIK) is still maintained (or some kind of successor to it).
InterViews is a lot faster than Fresco (it doesn't do the CORBA stuff,
the flywights are really extremly lightweight), but it is said to flood
the X server with pixmaps. :-/

From - Sun Oct 10 22:33:51 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA10909
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 12:43:56 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA20634 for linux-audio-dev-list; Sun, 10 Oct 1999 12:31:32 -0400
Received: from sculpcave (adm-3.wakkanet.fi [194.157.35.121]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA20619 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 12:31:23 -0400
Received: from localhost (localhost [127.0.0.1])
	by sculpcave (Postfix) with ESMTP
	id BB0FF34D3A; Sun, 10 Oct 1999 14:02:29 +0300 (EEST)
Date: Sun, 10 Oct 1999 14:02:29 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
X-Sender: root@sculpcave.localdomain
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway 
In-Reply-To: <199910092316.TAA02160@renoir.op.net>
Message-ID: <Pine.LNX.4.10.9910101322540.752-100000@sculpcave.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 90896ea0ad43e7dfb6f6a900b40cfe5a

On Sat, 9 Oct 1999, Paul Barton-Davis wrote:

>>- why hard-code effects to the interface (EQs, panning, amplify)?
> why not do the same for EQ and amplification ? Well, the only answer I
> can think of is that both of them are pretty well understood and
> simple effects. Not a very good answer for EQ, though perhaps adequate
> for amplification.

At least one good reason for making all effects optional is that it 
makes the user interface simpler. Less controllers -> easier to use. 
In hardware we can always add new knobs and sliders, but PCs rarely
have more than one controller device (=mouse). Keyboard isn't a very 
good (realtime) controller.

>>- why concentrate on inputs?
> not sure what you mean by this ? can you explain ?

Well, for instance in ecasound, I chose to concentrate all processing 
around chains. All chain operators (=effects), controllers, etc are 
connected to chains. Inputs and outputs are separate objects.
For simplicity (=performance), a chain can only have one input and
output, although one input/output can be connected to many chains. 

I'm still developing the concept, but it's already quite usable.
I don't need to use inserts, effect buses or any other "extra" 
concepts. When doing effect processing: "1 input -> n chains -> 1
output", mixing: "n inputs -> n chains -> 1 output", multitrack
recording: "n monitor-inputs -> n chains -> 1 monitor-output,
m recording-inputs -> m chains -> record-output", etc.

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav

From - Sun Oct 10 22:33:52 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA10997
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 12:45:08 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA20635 for linux-audio-dev-list; Sun, 10 Oct 1999 12:31:33 -0400
Received: from sculpcave (adm-3.wakkanet.fi [194.157.35.121]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA20629 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 12:31:28 -0400
Received: from localhost (localhost [127.0.0.1])
	by sculpcave (Postfix) with ESMTP
	id C312334D3B; Sun, 10 Oct 1999 14:24:40 +0300 (EEST)
Date: Sun, 10 Oct 1999 14:24:40 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
X-Sender: root@sculpcave.localdomain
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] linux audio apps/authors behind open-plugin-whatever
In-Reply-To: <19991010003153.2070.qmail@hyperreal.org>
Message-ID: <Pine.LNX.4.10.9910101402380.752-100000@sculpcave.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 9da01567bc58a928ac921aa3c8174596

On Sat, 9 Oct 1999 est@hyperreal.org wrote:

> I suspect progress in this area will be made as people make resonably
> concrete and complete proposals that are explcitly GLPLed (or at least
> GPLed) so that others can improve them freely.  The devil's in the
> details *and* their interaction in the whole.

But as we're talking about a plugin system, making changes afterwards 
will be difficult. This is why I think it's important to get other
linux-audio projects involved.

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav

From - Sun Oct 10 22:33:50 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA10864
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 12:43:35 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA20633 for linux-audio-dev-list; Sun, 10 Oct 1999 12:31:31 -0400
Received: from sculpcave (adm-3.wakkanet.fi [194.157.35.121]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA20620 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 12:31:23 -0400
Received: from localhost (localhost [127.0.0.1])
	by sculpcave (Postfix) with ESMTP
	id 5F85F34D3C; Sun, 10 Oct 1999 14:41:49 +0300 (EEST)
Date: Sun, 10 Oct 1999 14:41:49 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
X-Sender: root@sculpcave.localdomain
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: timing issues in a client/server enviroment
In-Reply-To: <99101001253701.00676@linuxhost.localdomain>
Message-ID: <Pine.LNX.4.10.9910101428060.752-100000@sculpcave.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 77d8bbe2df342d044a7ecb988c6bcfb3

On Sun, 10 Oct 1999, Benno Senoner wrote:

>> or more sample implementations is a great idea, but please don't
>> anyone go off and think they are writing "the Linux Sound System".
> I agree on the fact that apps should be able to do their own pugin hosting,
> but sooner or later we will need some engine which allows routing and
> integration of simultaneously running audio apps, 

I don't want to sound pessimistic, but it might be better to start 
with something simpler. For instance, I'm currently using ALSA's 
loopback device quite successfully for routing audio data between
audio apps. With a few improvements/additions, ALSA's flexible 
mixer design combined with ALSA-lib/driver functionality would serve a lot
of purposes. And what's important, these things exist and are ready
for use, now. 

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav

From - Sun Oct 10 22:33:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA31256
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 10:44:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA20426 for linux-audio-dev-list; Sun, 10 Oct 1999 10:27:04 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA20423 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 10:27:02 -0400
Received: from someip.ppp.op.net (d-bm2-15.ppp.op.net [209.152.194.53]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id KAA03973; Sun, 10 Oct 1999 10:21:59 -0400 (EDT)
Message-Id: <199910101421.KAA03973@renoir.op.net>
To: David Olofson <audiality@swipnet.se>
cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] API design again [MORE code] 
In-reply-to: Your message of "Sun, 10 Oct 1999 06:42:56 +0200."
             <9910100741370H.00456@localhost.localdomain> 
Date: Sun, 10 Oct 1999 10:22:37 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 6d5eecbfc81c6d7db344b6a60f3c7a64

>That's effectively what happens when a client communicates with a
>server; it needs to sleep at some point, or it will hang the
>system... :-) 

actually, it doesn't have to sleep. this is a problem i've dealt with
many times in the past. you basically divide the engine state into two
parts, one that is completely private to the engine thread, and one
that can be manipulated (with locks if necessary) by any other
thread.the engine thread periodically reassesses its public state. no
sleeping, unless two non-engine threads both want to mess with the
same part of the engine's public state at the same time. if the state
elements are simple and non-correlated, you can even use atomic_t and
avoid locks.

>> But wait - how is the engine thread going to safely copy or otherwise
>> use this data when the MIDI input thread (or any other h/w-driven
>> thread) could modify the port's event list at any time ?
>
>You don't do that. Once an event is "posted", it is considered
>property of the destination context. 

there is no destination context. one thread *cannot* write to another
thread's event_port_t. all that a sensor thread can do is to post a new
event to its port, and hope that the right people find it there. in
this case, the right people is the engine thread.
				      
>				      And the event data is going
>nowhere until the buffer is flushed. You allocate memory, fill in the
>event_t, and add it to the list.

Nope. I didn't say modify the events within the list, I said modify
the list. When the engine takes a look at the list, it needs to know
where it starts and where it finishes. we have to be very careful to
ensure that this can be done without locks.

>Actually, there's one more level; the transfer of the finished list
>of events (for the cycle) to the destination port.

this can't happen without locking. we don't want to do this.

You write of a "finish cycle operation"

>...or you can add all events to the list of the shadow event port, and
>then just finish_cycle(my_event_port) to send the list off to the
>engine. The engine will never see the shadow port at all - only the
>code that gathers new events from the queues is aware of the fact
>that the events actually come from a different thread.

sorry, this won't work. once again, a sensor thread is not going to
wait for a command to "finish the cycle". its working asynchronously
with respect to the engine.

then you provide two hints about non-shared-memory implementations:

>What I proposed earlier was just to wake up the MIDI thread an extra
>time to perform this operation once per engine cycle, rather than
>doing finish_cycle() for every event, or every timestamp. With shared
>memory and lock free queues it doesn't make much difference, but if
>would in other settings...

>> struct event_port_t {
>>        qm_heap_t *heap;                    /* how to allocate */
>>        event_port_t *engine_listen_next;   /* link to engine listen list */
>>        event_port_t *subscriber_head;      /* subscriber list */
>>        event_port_t *subscriber_tail;      /* subscriber list */
>>        event_t *event_head;
>>        event_t *event_tail;
>> }
>
>Hmmm... Maybe at least some of these should be hidden in the private
>parts of the implementation. (They will probably look different for
>non-shared memory connections and other weird things...)

1) in general, we should not be supporting non-shared memory
   directly. for example:

2) sensor threads make no sense for other settings. if you want to
   collect information across a network, for example, thats OK, but you
   still have a sensor thread that is responsible for collecting it in
   the same way as if it were MIDI data or whatever.

we can use this principle for any kind of connection that can't use
shared memory.

i don't care what set of sensor threads you might want to run, but I
don't want the core engine messed up by non-shared memory junk which
will slow it down and make it much more complex.

>It fits my idea of a client... The most significant difference from a
>plug-in is that it has it's own thread, and runs whenever it wants.

aha! you admit it: "runs whenever it wants". this is why the
"finish_cycle" operation idea won't work.

"client" is a word that suggests someone who gets something from a
"server". the sensor threads don't do that - in fact, they get almost
nothing from the server, and spend their life entirely in its
service. so "slave" might be a better term.

--p

From - Sun Oct 10 22:33:34 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA31852
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 10:50:57 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA20441 for linux-audio-dev-list; Sun, 10 Oct 1999 10:36:55 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA20438 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 10:36:53 -0400
Received: from someip.ppp.op.net (d-bm2-15.ppp.op.net [209.152.194.53]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id KAA04310; Sun, 10 Oct 1999 10:32:12 -0400 (EDT)
Message-Id: <199910101432.KAA04310@renoir.op.net>
To: David Olofson <audiality@swipnet.se>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] plugin questions 
In-reply-to: Your message of "Sun, 10 Oct 1999 07:42:51 +0200."
             <9910100825580I.00456@localhost.localdomain> 
Date: Sun, 10 Oct 1999 10:32:50 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 149ea6b86a42e606980e783ac39ff6a3

 [ ... init() ... ]

>> what do you have in mind ?
>
>It should do both. The event system is used instead of the
>structures or callbacks that many other plug-in APIs use.

sure, but you talk about it being called many times. thats not how i
think of an "init()" function.

[ .. buffer size stuff .. ]

OK, understood.

>> >6) Parameters that do not fit in a standard class will have to
>> >   go into a custom class. The properties of these events must
>> >   be defined during the init sequence. Custom events should be
>> >   *avoided* as far as possible, as they effectively eliminate
>> >   the usefullnes of the event system. (How do you automate
>> >   a parameter that you don't understand?)
>> 
>> i have a feeling that you are thinking of things a little backwards to
>> the way i am. my model is that the events that get sent to a plugin
>> don't say "change parameter N to X". They say "something changed to
>> Y". Its up to the plugin to decide what that means.
>
>The only difference is that my plug-ins actually tell you during
>init what events they care about. 

and later:

>> so, plugins don't need to publish parameters, or their
>> characteristics. they just subscribe to available ports, which the
>> engine must make available.
>
>I don't like that since I don't think connection management belongs
>in the plug-in code, and I do think that it's a good idea to be able
>to tell what a plug-in actually cares about. And the characteristics
>*have* to be published one way or another, or you're forced to use
>the plug-in's custom GUI for the values to make any sense.

What are you describing is not "telling you what events they care
about", but "telling us what events they accept". This is (subtly)
opposite, and i think that your version is a bad design pattern. the
linkage between a plugin that wants to receive events and another
source that sends them should be based on the event types of the
source, not the nature of the destination. 

there is simply no reason to publish any of the characteristics of the
plugin. this is completely private to it. if a plugin wants to use
MIDI CC 34 to control one of its internal parameters, then thats
fine. we don't care. other plugins have no business thinking that they
can directly request a state change in another plugin - they should
just be communicated how *they* see the world, and hope that everybody
else agrees with them.

this is all basic stuff from the design patterns world. its also, BTW,
the difference between web-based "push" and "pull" technology.

can you give an example that illustrates why it should be different ?

--p

From - Sun Oct 10 22:33:46 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA09384
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 12:29:15 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA20585 for linux-audio-dev-list; Sun, 10 Oct 1999 12:12:32 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA20582 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 12:12:27 -0400
Received: from localhost.localdomain (d212-151-32-33.swipnet.se [212.151.32.33]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id SAA07612; 
          Sun, 10 Oct 1999 18:07:41 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>
Subject: Re: [linux-audio-dev] API design again [MORE code]
Date: Sun, 10 Oct 1999 17:18:49 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
References: <199910101421.KAA03973@renoir.op.net>
In-Reply-To: <199910101421.KAA03973@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101018143300.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id SAA07612
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id MAA09384
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 03e8cef63945f34c33dc324c5f1fed1b

On Sun, 10 Oct 1999, Paul Barton-Davis wrote:
> >That's effectively what happens when a client communicates with a
> >server; it needs to sleep at some point, or it will hang the
> >system... :-) 
> 
> actually, it doesn't have to sleep. this is a problem i've dealt with
> many times in the past. you basically divide the engine state into two
> parts, one that is completely private to the engine thread, and one
> that can be manipulated (with locks if necessary) by any other
> thread.the engine thread periodically reassesses its public state. no
> sleeping, unless two non-engine threads both want to mess with the
> same part of the engine's public state at the same time. if the state
> elements are simple and non-correlated, you can even use atomic_t and
> avoid locks.

So where do you get the CPU time for other tasks, if the engine never
sleeps...? Or am I missing what you're actually saying here?

> >> But wait - how is the engine thread going to safely copy or otherwise
> >> use this data when the MIDI input thread (or any other h/w-driven
> >> thread) could modify the port's event list at any time ?
> >
> >You don't do that. Once an event is "posted", it is considered
> >property of the destination context. 
> 
> there is no destination context. one thread *cannot* write to another
> thread's event_port_t. all that a sensor thread can do is to post a new
> event to its port, and hope that the right people find it there. in
> this case, the right people is the engine thread.

("Context" is the word I chose to use for sub nets, no matter if
they're running on the same thread or not. This is because it's
significant when dealing with cycle times, event buffer life times
and ralated things. It may not be appropriate for client/server
relations, although the same rules still apply...)

Anyway... FIFO. Any other behavior would be erroneous and fatal in
this case. If your events are late for the cycle, you're missing a
deadline, which is a Very Bad Thing(tm) in a real time system.

> >				      And the event data is going
> >nowhere until the buffer is flushed. You allocate memory, fill in the
> >event_t, and add it to the list.
> 
> Nope. I didn't say modify the events within the list, I said modify
> the list. When the engine takes a look at the list, it needs to know
> where it starts and where it finishes. we have to be very careful to
> ensure that this can be done without locks.

It's rather safe if your new list is entirely on your side of a
FIFO... :-)

> >Actually, there's one more level; the transfer of the finished list
> >of events (for the cycle) to the destination port.
> 
> this can't happen without locking. we don't want to do this.

A FIFO doesn't need locking in the single reader - single writer
case, and it also allows queueing of multiple event buffers. That
means we get cycle period matching almost for free. The engine only
needs to grab the buffers one by one and do the compulsory time stamp
conversion.

> You write of a "finish cycle operation"
> 
> >...or you can add all events to the list of the shadow event port, and
> >then just finish_cycle(my_event_port) to send the list off to the
> >engine. The engine will never see the shadow port at all - only the
> >code that gathers new events from the queues is aware of the fact
> >that the events actually come from a different thread.
> 
> sorry, this won't work. once again, a sensor thread is not going to
> wait for a command to "finish the cycle". its working asynchronously
> with respect to the engine.

So, your "cycle time" will have to be based on the only wake up
source you have; the device you're sensing. However, that does not
mean that you have to pass one event at a time. Just send'em all of
before you go back to sleep.

> then you provide two hints about non-shared-memory implementations:
> 
> >What I proposed earlier was just to wake up the MIDI thread an extra
> >time to perform this operation once per engine cycle, rather than
> >doing finish_cycle() for every event, or every timestamp. With shared
> >memory and lock free queues it doesn't make much difference, but if
> >would in other settings...
> 
> >> struct event_port_t {
> >>        qm_heap_t *heap;                    /* how to allocate */
> >>        event_port_t *engine_listen_next;   /* link to engine listen list */
> >>        event_port_t *subscriber_head;      /* subscriber list */
> >>        event_port_t *subscriber_tail;      /* subscriber list */
> >>        event_t *event_head;
> >>        event_t *event_tail;
> >> }
> >
> >Hmmm... Maybe at least some of these should be hidden in the private
> >parts of the implementation. (They will probably look different for
> >non-shared memory connections and other weird things...)
> 
> 1) in general, we should not be supporting non-shared memory
>    directly. for example:

Agreed. However, we don't have to make it inherently difficult to
implement...

> 2) sensor threads make no sense for other settings. if you want to
>    collect information across a network, for example, thats OK, but you
>    still have a sensor thread that is responsible for collecting it in
>    the same way as if it were MIDI data or whatever.

Ok, just set up a communication thread with a sensible cycle rate, in
case event rate >> fixed latency. ("Fixed latency" being the jitter
elimination delay that makes time stamps useful.) What I mean is that
it's insane to send events 20 times during a single fixed latency
period.

> we can use this principle for any kind of connection that can't use
> shared memory.
> 
> i don't care what set of sensor threads you might want to run, but I
> don't want the core engine messed up by non-shared memory junk which
> will slow it down and make it much more complex.

No, that's not the idea. I only want to clean up the API, and make it
posible to change the implementation without breaking the API.

API != implementation.

> >It fits my idea of a client... The most significant difference from a
> >plug-in is that it has it's own thread, and runs whenever it wants.
> 
> aha! you admit it: "runs whenever it wants". this is why the
> "finish_cycle" operation idea won't work.

finish_cycle() *can* be called whenever you want. (Plug-ins don't
need it, as returning from process() has the same meaning.) It's just
that *recommending* that it's not called more frequently than
necessary will make optimization of the implementation a bit easier.

> "client" is a word that suggests someone who gets something from a
> "server". the sensor threads don't do that - in fact, they get almost
> nothing from the server, and spend their life entirely in its
> service. so "slave" might be a better term.

That's true... (However, I think "slave" suggests that the sensor
thread is controlled by the system somehow - which is not the case.)

The client/server/plug-in terminonolgy doesn't fit too well. "Plug-in"
is still ok, and is different from what we have called clients and
servers so far. But clients and servers are too similar to make a
distinction... They both connect through the same API, and the only
difference is the balance between send and recieve. They're just
nodes in a network... They may be plug-in hosts (engines), they can
publish some services, or use some services provided by other nodes.
Drivers are no different...

And we don't even have a name for the *API* yet! *hehe*


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:33:36 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA05439
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 11:52:14 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA20550 for linux-audio-dev-list; Sun, 10 Oct 1999 11:38:50 -0400
Received: from gate.suse.cz (perex.cb.cesnet.cz [194.212.165.105]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA20547 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 11:38:47 -0400
Received: from localhost (perex@localhost)
	by gate.suse.cz (8.8.8/8.8.8) with ESMTP id RAA14395;
	Sun, 10 Oct 1999 17:33:52 +0200
X-Authentication-Warning: gate.suse.cz: perex owned process doing -bs
Date: Sun, 10 Oct 1999 17:33:52 +0200 (MEST)
From: Jaroslav Kysela <perex@suse.cz>
To: David Olofson <audiality@swipnet.se>
cc: Linux Audio Development Mailing list <linux-audio-dev@ginette.musique.umontreal.ca>,
        ALSA development <alsa-devel@alsa-project.org>
Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc.
In-Reply-To: <9910100248370C.00456@localhost.localdomain>
Message-ID: <Pine.LNX.4.05.9910101704500.14177-100000@gate.suse.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1297ab00727b821f74f412e28f98c144

On Sun, 10 Oct 1999, David Olofson wrote:

> > I think that the big problem will be with the memory allocation, because
> > the allocation must be done inside kernel (use mmap from the user space?).
> > It's problem #1 and we should solve it firstly.
> 
> There is a module called mbuff that's used with RTLinux for this
> purpose. It's based on the "heavy wizardry" in bttv.c, and I think
> the module should work w/o RTL... (Memory allocation from the
> standard kernel heap can never be hard real time anyway.)

I'm not sure, if using physical memory for events (my proposal and
probably mbuff does this, too) is a good idea. The question is, how long
will be an event. I'd like to see an event for complete wavetable
instrument (tens of megabytes). If we will use only physical memory
allocation and an user have only little memory, it will not work, but it
works perfectly with current implementations which use the virtual memory
(swap).

Onother thing: the process security. Do you thing that one shared memory
heap is a good solution for multi user / multi tasking system? I don't.
The memory heaps could be shared only among participants, but it's a
question, how to do it (duplicate information? - another memory wasting).

I also think that we should cooperate from beginning with Linus and Alan
Cox to make sure, that this code will be included into the standard kernel
tree.

A little dream:

Event - picture 768x576 from grabbed from the BTTV driver 8-bits per color
Event - Piano instrument 96kHz, 24-bit resolution

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA project  http://www.alsa-project.org


From - Sun Oct 10 22:33:57 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA12823
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 13:01:53 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA20674 for linux-audio-dev-list; Sun, 10 Oct 1999 12:49:06 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA20671 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 12:49:02 -0400
Received: from localhost.localdomain (d212-151-32-33.swipnet.se [212.151.32.33]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id SAA11123; 
          Sun, 10 Oct 1999 18:44:17 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>
Subject: Re: [linux-audio-dev] plugin questions
Date: Sun, 10 Oct 1999 18:15:24 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <199910101432.KAA04310@renoir.op.net>
In-Reply-To: <199910101432.KAA04310@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101018510901.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id SAA11123
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id NAA12823
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: dc2022ce1a5ede72e77b15a633308ee3

On Sun, 10 Oct 1999, Paul Barton-Davis wrote:
> [ ... init() ... ]
> 
> >> what do you have in mind ?
> >
> >It should do both. The event system is used instead of the
> >structures or callbacks that many other plug-in APIs use.
> 
> sure, but you talk about it being called many times. thats not how i
> think of an "init()" function.

What about all the callbacks that VST plug-ins do to the host?
Anyway, multiple calls would only be needed if the host and the
plug-in really have a problem agreeing on something. That should be
possible to avoid, I think.

For <clients, servers, nodes, whatever...>, it's different. As soon
as you're connected to the client/server (...?) API, it's time to
register with the communication system manager and perhaps look for
some services that you'll use. Or, preferably, you should look up
your services when you need them. That's not a single, two stage init
sequence. There are more details to sort out here...

[...]
> >I don't like that since I don't think connection management belongs
> >in the plug-in code, and I do think that it's a good idea to be able
> >to tell what a plug-in actually cares about. And the characteristics
> >*have* to be published one way or another, or you're forced to use
> >the plug-in's custom GUI for the values to make any sense.
> 
> What are you describing is not "telling you what events they care
> about", but "telling us what events they accept".

How? I'm being unclear again, I guess...

> This is (subtly)
> opposite, and i think that your version is a bad design pattern. the
> linkage between a plugin that wants to receive events and another
> source that sends them should be based on the event types of the
> source, not the nature of the destination. 

True, but how do you know what you can actually connect without just
being ignored? The info I'm talking about could be placed in a config
file that comes with the plug-in, but I wonder if that's a good
idea...

> there is simply no reason to publish any of the characteristics of the
> plugin.

The engine could still ignore the information (whether in the
plug-in, or in a separate file), but what's the point? User: "Why the
h*ll can I connect this output to that plug-in, when the plug-in
doesn't care anyway?"

> this is completely private to it.

No. Don't you want to know what MIDI events a synth supports?

> if a plugin wants to use
> MIDI CC 34 to control one of its internal parameters, then thats
> fine. we don't care.

MIDI... When I realized that there's no way around the cost involved
with broadcasting events, I dropped that idea. The fact that I see
event ports as quite similar to audio ports may explain why we have
very different views on this. I want the *engine* to control who
listens to what - just as with audio connections. Channels, addresses
and broadcasting belong in bus systems - while plug-ins are parts of
nets...

> other plugins have no business thinking that they
> can directly request a state change in another plugin - they should
> just be communicated how *they* see the world, and hope that everybody
> else agrees with them.

...but that doesn't conflict with a way of saying "I listen to CC
98 and CC 99 - I'll ignore anything else you send, in case you care."

And, a plug-in should certainly not think that it can directly
control *anything* - the events it outputs might well be routed to
the engine's version of "/dev/null". No different from the audio
outputs.

> this is all basic stuff from the design patterns world. its also, BTW,
> the difference between web-based "push" and "pull" technology.
> 
> can you give an example that illustrates why it should be different ?

I think we're too much out of sync for me to give a sensible answer
to that question... :-) (Or the answer might be in the above?)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:33:54 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA11590
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 12:50:37 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA20645 for linux-audio-dev-list; Sun, 10 Oct 1999 12:37:15 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA20642 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 12:37:13 -0400
Received: from op.net (d-bm2-1c.ppp.op.net [209.152.194.60]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id MAA09922 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 12:32:34 -0400 (EDT)
Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id MAA32037; Sun, 10 Oct 1999 12:33:13 -0400
Date: Sun, 10 Oct 1999 12:33:13 -0400
Message-Id: <199910101633.MAA32037@op.net>
From: Paul Barton-Davis <pbd@Op.Net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] client/server stuff in MCS
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: d3ad0d7bd75855a8573be2af71a14c91

[ i broke this out since it seems like a separate aspect of things
  altogether 
]

this client/server stuff: what is a client ? my best guess so far might be a
standalone program that wants to route its (say) audio through the
MCS. it seems that you propose using the event system for
this. 

ignoring my misgivings about this for a moment, this is handled very
simply using a sensor thread plus the kind of shmem setup that Benno
has described. the sensor thread behaves exactly as would a sensor
thread reading from /dev/snd/pcmCnDnn. so thats easy.

but wait a moment: this implies that we have to code other
applications to use this system, and not the one that they would use
if they were writing to /dev/snd/pcmCnDnn. this isn't nice. 

i think that its a much better idea to use esd-like
open/close/read/write redirection via LD_PRELOAD. our read/write
wrapper can take care of mapping the system call into a "scribble in a
shared memory buffer".  the open/close wrapper converts a device open
to "shmget+shmat/shmdt" operations.

that way, applications can function without alteration with or without
a running MCS system.

  % alias use_mcs='env LD_PRELOAD=/lib/mcs_wrapper.o'
  % if [ $MOON_PHASE -gt 3 ] ; then 
          use_mcs oolaboola ...
    else 
          oolaboola ...
    fi
  %

or (better):

  % cat run-audio
  #!/bin/sh

  if [ -f /var/lock/mcs.pid ] ; then
       exec env LD_PRELOAD=/lib/mcs_wrapper.o $*
  else 
       exec $*
  fi
  % run-audio oolaboola ...

      

From - Sun Oct 10 22:33:55 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA12302
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 12:57:48 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA20652 for linux-audio-dev-list; Sun, 10 Oct 1999 12:43:07 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA20649 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 12:43:02 -0400
Received: from someip.ppp.op.net (d-bm2-1c.ppp.op.net [209.152.194.60]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id MAA10195; Sun, 10 Oct 1999 12:38:20 -0400 (EDT)
Message-Id: <199910101638.MAA10195@renoir.op.net>
To: David Olofson <audiality@swipnet.se>
cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] API design again [MORE code] 
In-reply-to: Your message of "Sun, 10 Oct 1999 17:18:49 +0200."
             <99101018143300.00456@localhost.localdomain> 
Date: Sun, 10 Oct 1999 12:38:59 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7359aa03ab645f90193062bbade5fe4f

 [ ... sleeping ... ]

>So where do you get the CPU time for other tasks, if the engine never
>sleeps...? Or am I missing what you're actually saying here?

(for a moment there, i thought i had fallen into my "i have a dual CPU
box and so does everyone else" trap. but fortunately, no ... )

the engine sleeps whenever it calls a plugin that calls
read/write. how long it sleeps depends on the i-node it reads/writes.
if it never calls read/write, it will never sleep.

"nothing is calling read/write" is actually a pathological situation,
but relatively easily dealt with. quasimodo and hdr both have to do
this. for quasimodo, a plugin must be able to tell us if it does
input. for hdr, if there are no inputs active then we stall the
engine. we focus on input because output is handled in these programs
by the "engine" itself. in MCS, this may not be true, so the
work_to_do() test has to include active ins OR active outs. 

sensor threads should run with SCHED_FIFO, but its not clear to me if
they should have a priority above or below or equal to that of the
engine thread.

>Anyway... FIFO. Any other behavior would be erroneous and fatal in
>this case. If your events are late for the cycle, you're missing a
>deadline, which is a Very Bad Thing(tm) in a real time system.

>> >Actually, there's one more level; the transfer of the finished list
>> >of events (for the cycle) to the destination port.
>> 
>> this can't happen without locking. we don't want to do this.
>
>A FIFO doesn't need locking in the single reader - single writer
>case, and it also allows queueing of multiple event buffers. That
>means we get cycle period matching almost for free. The engine only
>needs to grab the buffers one by one and do the compulsory time stamp
>conversion.

time stamp conversion ? the sensor thread should have timestamped the
events with the same timebase as the engine. hence:

       ev->timestamp = engine->timestamp();

>> sorry, this won't work. once again, a sensor thread is not going to
>> wait for a command to "finish the cycle". its working asynchronously
>> with respect to the engine.
>
>So, your "cycle time" will have to be based on the only wake up
>source you have; the device you're sensing. However, that does not
>mean that you have to pass one event at a time. Just send'em all of
>before you go back to sleep.

well, yes, of course. but the point here is that this sending will
happen (potentially) in the middle of the engine's control
cycle, not at a point defined by the engine.

the overall point here is to think of the engine as collecting events
from the subscribable ports, not as the sensor threads delivering them
anywhere. then all this "shadow port" stuff goes away. the only key
thing, as i said before, is to ensure that we have reliable lock-free
event queues for the ports.

 [ ... handling non-shared memory stuff ... ]

>Ok, just set up a communication thread with a sensible cycle rate, in
>case event rate >> fixed latency. ("Fixed latency" being the jitter
>elimination delay that makes time stamps useful.) What I mean is that
>it's insane to send events 20 times during a single fixed latency
>period.
 
not really, if you forget about this idea of "sending" as an active
thing. you're just putting events on a queue. somebody else will take
them off when they're ready.

>No, that's not the idea. I only want to clean up the API, and make it
>posible to change the implementation without breaking the API.
>
>API != implementation.

yep. and i think we agree that using a communication thread will
satisfy this, so we can exclude all considerations of non-shared
memory from our discussion :)

>> aha! you admit it: "runs whenever it wants". this is why the
>> "finish_cycle" operation idea won't work.
>
>finish_cycle() *can* be called whenever you want. (Plug-ins don't
>need it, as returning from process() has the same meaning.) It's just
>that *recommending* that it's not called more frequently than
>necessary will make optimization of the implementation a bit easier.

you write as if the engine calls finish_cycle(), and this is what i
meant would not work. sure, a sensor thread can do this whenever it
likes, but then it doesn't need a special name - its just another
thing the sensor thread does on its own.

--p

From - Sun Oct 10 22:34:18 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA25424
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 15:05:37 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA20946 for linux-audio-dev-list; Sun, 10 Oct 1999 14:49:14 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA20927 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 14:48:56 -0400
Received: from localhost.localdomain (d212-151-44-51.swipnet.se [212.151.44.51]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id UAA09869; 
          Sun, 10 Oct 1999 20:44:10 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Jaroslav Kysela <perex@suse.cz>
Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc.
Date: Sun, 10 Oct 1999 18:52:16 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: Linux Audio Development Mailing list <linux-audio-dev@ginette.musique.umontreal.ca>,
        ALSA development <alsa-devel@alsa-project.org>
References: <Pine.LNX.4.05.9910101704500.14177-100000@gate.suse.cz>
In-Reply-To: <Pine.LNX.4.05.9910101704500.14177-100000@gate.suse.cz>
MIME-Version: 1.0
Message-Id: <99101019284402.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id UAA09869
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id PAA25424
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7087fac890e69f3424e941b81bee752c

On Sun, 10 Oct 1999, Jaroslav Kysela wrote:
> On Sun, 10 Oct 1999, David Olofson wrote:
> 
> > > I think that the big problem will be with the memory allocation, because
> > > the allocation must be done inside kernel (use mmap from the user space?).
> > > It's problem #1 and we should solve it firstly.
> > 
> > There is a module called mbuff that's used with RTLinux for this
> > purpose. It's based on the "heavy wizardry" in bttv.c, and I think
> > the module should work w/o RTL... (Memory allocation from the
> > standard kernel heap can never be hard real time anyway.)
> 
> I'm not sure, if using physical memory for events (my proposal and
> probably mbuff does this, too) is a good idea. The question is, how long
> will be an event. I'd like to see an event for complete wavetable
> instrument (tens of megabytes). If we will use only physical memory
> allocation and an user have only little memory, it will not work, but it
> works perfectly with current implementations which use the virtual memory
> (swap).

That will have to be an API extension in that case... What we're
dealing with is a real time event system that's primarily designed
for efficient communication with plug-ins. Actually, it won't even do
function calls when allocating memory for events most of the time...

> Onother thing: the process security. Do you thing that one shared memory
> heap is a good solution for multi user / multi tasking system? I don't.
> The memory heaps could be shared only among participants, but it's a
> question, how to do it (duplicate information? - another memory wasting).

That's a serious problem, and the question is; is it even possible to
run a system of this kind efficiently without compromising security
in some way? Sure, it would be nice to make sure no other user with
access to the "Multimedia Communication System" can connect to your
processing nets without permission, but is it worth the performance
impact?

There is one thing that may help, though; it wouldn't be a big
problem to have multiple memory areas for the communication system.
That would eliminate the possibility of tasks accessing things
without authorization, by simply controlling the access of the memory
areas. Communication between plug-ins, clients and servers (or
whatever we'll call them) across the memory areas would mean
copying. (Event system firewalls are possible...)

Is that cost significant? Will users on the same system really
interconnect their applications with so many connections/high
bandwidth that it matters?

> I also think that we should cooperate from beginning with Linus and Alan
> Cox to make sure, that this code will be included into the standard kernel
> tree.

That would be good, yes... I think it's time to write a
comprehensible, compact document as soon as the API starts to get
into the alpha implementation stage.

> A little dream:
> 
> Event - picture 768x576 from grabbed from the BTTV driver 8-bits per color

Sorry... Events can never be that big due to the performance hit that
would mean for plug-ins and applications that need to send thousands
of events, and still be capable of hard real time.

But... There are data streams. In the case of the picture; that's
*exactly* what I had in mind for this part of the API - apart from
streaming audio, of course.

> Event - Piano instrument 96kHz, 24-bit resolution

I guess off-line streaming could handle that... Things that can't be
done in a single process cycle doesn't fit well with our definition of
plug-ins (callbacks), but it should be possible to implement as one
of the protocols on top of the event system. (Which is used by
clients, servers etc, in addition to plug-ins.) The audio streams
that we have been thinking about mostly so far are constant rate, and
they're strictly bound to the time base of the communicating
parties. However, the idea of supporting variable rate streams have
been in the back of my mind for long, and extending it to cope with
huge data buffers doesn't seem impossible. Not hard real time, but
still the same API... :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:34:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA13865
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 13:11:34 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA20692 for linux-audio-dev-list; Sun, 10 Oct 1999 12:59:07 -0400
Received: from gate.suse.cz (perex.cb.cesnet.cz [194.212.165.105]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA20689 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 12:59:04 -0400
Received: from localhost (perex@localhost)
	by gate.suse.cz (8.8.8/8.8.8) with ESMTP id SAA14725;
	Sun, 10 Oct 1999 18:53:57 +0200
X-Authentication-Warning: gate.suse.cz: perex owned process doing -bs
Date: Sun, 10 Oct 1999 18:53:57 +0200 (MEST)
From: Jaroslav Kysela <perex@suse.cz>
To: David Olofson <audiality@swipnet.se>
cc: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] plugin questions
In-Reply-To: <99101018510901.00456@localhost.localdomain>
Message-ID: <Pine.LNX.4.05.9910101851480.14177-100000@gate.suse.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 81967caacc1c3c3ccc03a9b7edd986fd

On Sun, 10 Oct 1999, David Olofson wrote:

> On Sun, 10 Oct 1999, Paul Barton-Davis wrote:
> > [ ... init() ... ]
> > 
> > >> what do you have in mind ?
> > >
> > >It should do both. The event system is used instead of the
> > >structures or callbacks that many other plug-in APIs use.
> > 
> > sure, but you talk about it being called many times. thats not how i
> > think of an "init()" function.
> 
> What about all the callbacks that VST plug-ins do to the host?

Please, forget about any callback implementation inside the communication 
API. Imagine that one communication node can be inside the kernel space
and other inside the user space. We can't use a callback with this
combination.

							Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA project  http://www.alsa-project.org

From - Sun Oct 10 22:34:01 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA14586
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 13:17:54 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA20712 for linux-audio-dev-list; Sun, 10 Oct 1999 13:04:42 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA20709 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 13:04:38 -0400
Received: from someip.ppp.op.net (d-bm2-1c.ppp.op.net [209.152.194.60]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id MAA11183 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 12:59:59 -0400 (EDT)
Message-Id: <199910101659.MAA11183@renoir.op.net>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] plugin questions 
In-reply-to: Your message of "Sun, 10 Oct 1999 18:53:57 +0200."
             <Pine.LNX.4.05.9910101851480.14177-100000@gate.suse.cz> 
Date: Sun, 10 Oct 1999 13:00:39 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: dce42234dab8aa4074eb04bbbe025363

>Please, forget about any callback implementation inside the communication 
>API. Imagine that one communication node can be inside the kernel space
>and other inside the user space. We can't use a callback with this
>combination.

thats why the ALSA sequencer, as truly wonderful as it is, is not the
right answer to the system we're trying to build. its a valuable part
of it, but it cannot be the core of it for all kinds of reasons, this
being one of them.

--p

From - Sun Oct 10 22:34:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA15889
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 13:30:05 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA20732 for linux-audio-dev-list; Sun, 10 Oct 1999 13:14:58 -0400
Received: from gate.suse.cz (perex.cb.cesnet.cz [194.212.165.105]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA20729 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 13:14:55 -0400
Received: from localhost (perex@localhost)
	by gate.suse.cz (8.8.8/8.8.8) with ESMTP id TAA14916
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 19:10:01 +0200
X-Authentication-Warning: gate.suse.cz: perex owned process doing -bs
Date: Sun, 10 Oct 1999 19:10:01 +0200 (MEST)
From: Jaroslav Kysela <perex@suse.cz>
To: Linux Audio Development Mailing list <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] plugin questions
Message-ID: <Pine.LNX.4.05.9910101909410.14883-100000@gate.suse.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 22a6d635a3edcba5d09d6f46b9bd3cf1

On Sun, 10 Oct 1999, Paul Barton-Davis wrote:

> >Please, forget about any callback implementation inside the communication 
> >API. Imagine that one communication node can be inside the kernel space
> >and other inside the user space. We can't use a callback with this
> >combination.
> 
> thats why the ALSA sequencer, as truly wonderful as it is, is not the
> right answer to the system we're trying to build. its a valuable part
> of it, but it cannot be the core of it for all kinds of reasons, this
> being one of them.

I'm lost here. I though that we are speaking about an event based
communication system with nodes inside user or kernel space.
Every callback can be implemented as two event calls (request &
reply).

						Jaroslav	
-----
Jaroslav Kysela <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA project  http://www.alsa-project.org


From - Sun Oct 10 22:34:02 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA15704
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 13:29:05 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA20740 for linux-audio-dev-list; Sun, 10 Oct 1999 13:15:12 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA20737 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 13:15:10 -0400
Received: from someip.ppp.op.net (d-bm2-1c.ppp.op.net [209.152.194.60]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id NAA11781 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 13:10:31 -0400 (EDT)
Message-Id: <199910101710.NAA11781@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway 
In-reply-to: Your message of "Sun, 10 Oct 1999 14:02:29 +0300."
             <Pine.LNX.4.10.9910101322540.752-100000@sculpcave.localdomain> 
Date: Sun, 10 Oct 1999 13:11:11 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e53be49cbf612a3bec194fac9756dd55

>In hardware we can always add new knobs and sliders, but PCs rarely
>have more than one controller device (=mouse). Keyboard isn't a very 
>good (realtime) controller.

right. its exactly because of this that the user interface must be
distinct from the rest of the program - if you don't have a good
controller, you want a different kind of interface than if you do. i
don't want to force you to deal with 16 on-screen faders if that makes
no sense, but i don't want you to force me to use a model in which i
can only alter one thing at a time. 

but i think we agree on this :)

>Well, for instance in ecasound, I chose to concentrate all processing 
>around chains. All chain operators (=effects), controllers, etc are 
>connected to chains. Inputs and outputs are separate objects.
>For simplicity (=performance), a chain can only have one input and
>output, although one input/output can be connected to many chains. 

how will you ever handle a stereo mixer strip ? it has one input, and
gets routed to two outputs. for surround sound, you take one input,
and output it to some variable number of outputs.

hdr has low level input devices, output devices, and four higher-level
abstractions called sources, destinations, strips and buses.

the engine does this:

       while (1) {

              for each input device {
		  tell input device to read N frames
	      }

	      for each bus {
		  for each strip using bus {
		       buf = strip->return_buffer (bus->id);
		       mix buf into bus's output buffer;
		       send to output destination
		  }
	      }

	      foreach output device {
	          write N frames to output device
              }
       }

in this scheme, the buses "pull" data from the strips. the strips in
turn "pull" data from the sources, which are just front-ends for the
current N frames of data that was read from the input device.

likewise, the buses "push" data into the destinations, which are just
front ends for a staging buffer used by the output devices. 

this system allows a strip to be connected to a single input, but any
number of buses, and thus any number of outputs, permitting surround
sound as well as other interesting stuff.

--p

From - Sun Oct 10 22:34:11 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA25134
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 15:02:55 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA20932 for linux-audio-dev-list; Sun, 10 Oct 1999 14:48:58 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA20923 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 14:48:54 -0400
Received: from localhost.localdomain (d212-151-44-51.swipnet.se [212.151.44.51]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id UAA09922; 
          Sun, 10 Oct 1999 20:44:12 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Kai Vehmanen <kaiv@wakkanet.fi>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] linux audio apps/authors behind open-plugin-whatever
Date: Sun, 10 Oct 1999 19:29:30 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <Pine.LNX.4.10.9910101402380.752-100000@sculpcave.localdomain>
In-Reply-To: <Pine.LNX.4.10.9910101402380.752-100000@sculpcave.localdomain>
MIME-Version: 1.0
Message-Id: <99101019370203.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id UAA09922
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id PAA25134
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3f1b86b1260301a4dad4ac59bd7aa7d9

On Sun, 10 Oct 1999, Kai Vehmanen wrote:
> On Sat, 9 Oct 1999 est@hyperreal.org wrote:
> 
> > I suspect progress in this area will be made as people make resonably
> > concrete and complete proposals that are explcitly GLPLed (or at least
> > GPLed) so that others can improve them freely.  The devil's in the
> > details *and* their interaction in the whole.
> 
> But as we're talking about a plugin system, making changes afterwards 
> will be difficult. This is why I think it's important to get other
> linux-audio projects involved.

Yes, we might have a serious design flaw creeping around, that we
won't find until it becomes obvious that some project can't adopt the
API. My wanting to support other uses than real time audio doesn't
make it easier to keep everything under control...

Still, I think getting some kind of alpha spec together and hacking
some prototype implementations ASAP is a *very* good idea, as that's
an efficient way of finding logical errors and practical
implementation problems. Releasing an official API before having a
working prototype implementation would be a serious mistake. This
project is too complex for that.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:34:13 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA25181
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 15:03:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA20944 for linux-audio-dev-list; Sun, 10 Oct 1999 14:49:08 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA20926 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 14:48:56 -0400
Received: from localhost.localdomain (d212-151-44-51.swipnet.se [212.151.44.51]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id UAA09968; 
          Sun, 10 Oct 1999 20:44:14 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Kai Vehmanen <kaiv@wakkanet.fi>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway
Date: Sun, 10 Oct 1999 19:37:55 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <Pine.LNX.4.10.9910101322540.752-100000@sculpcave.localdomain>
In-Reply-To: <Pine.LNX.4.10.9910101322540.752-100000@sculpcave.localdomain>
MIME-Version: 1.0
Message-Id: <99101020023904.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id UAA09968
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id PAA25181
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: abd9fafca00dd29e05b6a062c34832f0

On Sun, 10 Oct 1999, Kai Vehmanen wrote:
> Keyboard isn't a very good (realtime) controller.

Naah... Works for Doom! ;-)

> >>- why concentrate on inputs?
> > not sure what you mean by this ? can you explain ?
> 
> Well, for instance in ecasound, I chose to concentrate all processing 
> around chains. All chain operators (=effects), controllers, etc are 
> connected to chains. Inputs and outputs are separate objects.
> For simplicity (=performance), a chain can only have one input and
> output, although one input/output can be connected to many chains. 
> 
> I'm still developing the concept, but it's already quite usable.
> I don't need to use inserts, effect buses or any other "extra" 
> concepts. When doing effect processing: "1 input -> n chains -> 1
> output", mixing: "n inputs -> n chains -> 1 output", multitrack
> recording: "n monitor-inputs -> n chains -> 1 monitor-output,
> m recording-inputs -> m chains -> record-output", etc.

I like that. No legacy design cruft. :-)

But I have yet to see a sensible GUI representation of it... Modular
synth style GUIs get messy too quickly, and a Bars'n'pipes "routing
matrix" would become huge... Some combination?

All icons:
.---.   .-------------------.   .----.
|IN1|-->| P1 | P2 | P3 | P4 |-->|OUT1|
`---'   `-------------------'   `----'
                                  ^
.---.   .---------.               |
|IN2|-->| P5 | P6 |---------------'
`---'   `---------'

P2 and P3 popped up:
.---.   .---------------------------------.   .----.
|IN1|-->| P1 | P2      | P3          | P4 |-->|OUT1|
`---'   `----| | | | | | ----L------ |----'   `----'
             | | O | O | -------H--- |          ^
             | O | | | | --Q-- ---G- |          |
             | | | O | |             |          |
             `---------| X BPF O NTCH|          |
                       | O LPF O PEAK|          |
                       `-------------'          |
.---.   .---------.                             |
|IN2|-->| P5 | P6 |-----------------------------'
`---'   `---------'

Point: No loose panels (or windows! *grr*) to move around...


Well, enough ASCII gfx for now... :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:34:05 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA18789
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 13:59:46 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA20778 for linux-audio-dev-list; Sun, 10 Oct 1999 13:44:49 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA20775 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 13:44:47 -0400
From: est@hyperreal.org
Received: (qmail 10708 invoked by uid 162); 10 Oct 1999 17:40:29 -0000
Message-ID: <19991010174029.10707.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] linux audio apps/authors behind open-plugin-whatever
In-Reply-To: <Pine.LNX.4.10.9910101402380.752-100000@sculpcave.localdomain> from
 Kai Vehmanen at "Oct 10, 1999 02:24:40 pm"
To: Kai Vehmanen <kaiv@wakkanet.fi>
Date: Sun, 10 Oct 1999 10:40:29 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 8e362cb1d1f37609334437c2f379dc0d

Kai Vehmanen discourseth:
> On Sat, 9 Oct 1999 est@hyperreal.org wrote:
> 
> > I suspect progress in this area will be made as people make resonably
> > concrete and complete proposals that are explcitly GLPLed (or at least
> > GPLed) so that others can improve them freely.  The devil's in the
> > details *and* their interaction in the whole.
> 
> But as we're talking about a plugin system, making changes afterwards 
> will be difficult.

That's a concern once a specification shows signs of widespread
allegiance.  I'm talking about modifications that get a spec to that
point.

Eric

From - Sun Oct 10 22:34:06 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA20082
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 14:12:39 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA20790 for linux-audio-dev-list; Sun, 10 Oct 1999 13:51:36 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA20787 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 13:51:33 -0400
Received: from someip.ppp.op.net (d-bm2-1c.ppp.op.net [209.152.194.60]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id NAA13480; Sun, 10 Oct 1999 13:46:48 -0400 (EDT)
Message-Id: <199910101746.NAA13480@renoir.op.net>
To: David Olofson <audiality@swipnet.se>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] plugin questions 
In-reply-to: Your message of "Sun, 10 Oct 1999 18:15:24 +0200."
             <99101018510901.00456@localhost.localdomain> 
Date: Sun, 10 Oct 1999 13:47:29 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: a4365c500065e154c789b898d54d2946

here's the heart of the matter, i think:

>> other plugins have no business thinking that they
>> can directly request a state change in another plugin - they should
>> just be communicated how *they* see the world, and hope that everybody
>> else agrees with them.
>
>...but that doesn't conflict with a way of saying "I listen to CC
>98 and CC 99 - I'll ignore anything else you send, in case you care."

no, it doesn't conflict. but there are two ways of saying this, one of
them as you just did, and one like this :

    cc_port[0] = subscribe (engine->get_port ("MIDI CC 98"));
    cc_port[1] = subscribe (engine->get_port ("MIDI CC 99"));

the big difference is that if the plugin changes its mind
(e.g. someone pressed the GUI controller for the CC it should use),
the plugin just does:
    
    unsubscribe (cc_port[0]);
    unsubscribe (cc_port[1]);

    cc_port[0] = subscribe (engine->get_port ("New ID"));
    cc_port[1] = subscribe (engine->get_port ("New ID"));
    
and nobody else has to care.

in your scheme, when a plugin changes it mind (and the example above
is a *very* likely one in my experience), you have to broadcast the
change to everyone who might care, which actually means everyone.

>> This is (subtly)
>> opposite, and i think that your version is a bad design pattern. the
>> linkage between a plugin that wants to receive events and another
>> source that sends them should be based on the event types of the
>> source, not the nature of the destination. 
>
>True, but how do you know what you can actually connect without just
>being ignored? 

>The fact that I see event ports as quite similar to audio ports may
>explain why we have very different views on this.

Yes, I think it may, as the following example illustrates:

>User: "Why the h*ll can I connect this output to that plug-in, when
>the plug-in doesn't care anyway?"

this is a good case in point. 

there is a big difference between port connections that are driven by
a user metaphorically (or literally, I don't know :) dragging a patch
cord from one place to another, and those that happen because the user
presses a button on a plugin GUI which says "Controller ID".

in the latter case, when the plugin does its stuff to respond to a
message from the GUI ("multiway switch XXX now has value 64"), it
doesn't don't connect to anything as the *source*. it connects to
another port as the *destination*. thats a key difference that ensures
the connections "matter".

in the former case (user dragging patch cords): when you're dealing
with typed events, which we're proposing, you (the user) can only
connect meaningfully two ports of the same type. if you connect an
audio port to an audio port, you're guaranteed that the destination
will care. but if you connect an audio port to a MIDI port, you can be
certain that you'll be ignored, if you can do it all.

so think about this a little bit more: what are the different event
types ?  if you have only a few of them, then you'll be asking plugins
to process all kinds of events that they *just don't care about*. if
you have a lot, and you enforce type equivalency when connecting, you
know you'll be paid attention to.

>Don't you want to know what MIDI events a synth supports?

Well, yes and no. If the synth comes with a MIDI IN port, and I connect
some MIDI OUT port to it, then in order to use it effectively, I need
to know which MIDI events make a difference.

But if the synth has a button which says "MIDI Controller ID" and
controls, say, the controller that sets pitch bend, then I don't care
to know anymore: when I press the button, the plugin will do the right
thing.

So again, it comes back to event types. If ports can only be
distinguished on the basis of being Audio or MIDI, then somebody will
have to tell us which MIDI events the plugin will use if we are to
usefully use a MIDI connection.

If, on the other hand, a port comes with a more specific type, say
"Audio level above XXdB" or "MIDI controller 32", then we need know
very little about a plugin to use it - the plugin will be able to
establish its own connections based on its current state ("Oh, the GUI
wants me to start monitoring audio levels above XXdB. OK, I'd better
establish a connection to ...")

Please note: the audio level example is a deliberately extreme
example. I am not sure that anyone would ever want to create such a
port, let alone subscribe to its events. But its an illustration of
what is possible.

>I think we're too much out of sync for me to give a sensible answer
>to that question... :-) (Or the answer might be in the above?)

I do think we're looking at this from opposite ends. I'm not sure that
what we're looking at is different, though.

I feel really strongly convinced that the model used by GTK, Qt, Gtk--
and libsigc++, and written about in many software engineering/pattern
language articles, is the one to use. Its a highly successful, well
thought out, multiply implemented, and widely used. 

I also have implemented a multiport MIDI library that uses libsigc++
in this way, and has "events" for every MIDI message type. Its been a
joy to work with, one of the best and most useful pieces of code
development I've ever done. The MIDIPort objects have no idea who is
listening to them, they just do their stuff, and when it matters, the
right objects get to hear about it.

--p


From - Sun Oct 10 22:34:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA20442
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 14:16:45 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA20797 for linux-audio-dev-list; Sun, 10 Oct 1999 13:56:42 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA20794 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 13:56:39 -0400
Received: from someip.ppp.op.net (d-bm2-1c.ppp.op.net [209.152.194.60]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id NAA13807 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 13:51:54 -0400 (EDT)
Message-Id: <199910101751.NAA13807@renoir.op.net>
To: Linux Audio Development Mailing list <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] plugin questions 
In-reply-to: Your message of "Sun, 10 Oct 1999 19:10:01 +0200."
             <Pine.LNX.4.05.9910101909410.14883-100000@gate.suse.cz> 
Date: Sun, 10 Oct 1999 13:52:35 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ddba364331c8f25cba9dd5dd524c6d0e

>> >Please, forget about any callback implementation inside the communication 
>> >API. Imagine that one communication node can be inside the kernel space
>> >and other inside the user space. We can't use a callback with this
>> >combination.
>> 
>> thats why the ALSA sequencer, as truly wonderful as it is, is not the
>> right answer to the system we're trying to build. its a valuable part
>> of it, but it cannot be the core of it for all kinds of reasons, this
>> being one of them.
>
>I'm lost here. I though that we are speaking about an event based
>communication system with nodes inside user or kernel space.
>Every callback can be implemented as two event calls (request &
>reply).

crossing the user/kernel boundary is too expensive for distributing
events which the kind of response we want. the communication system
needs to reside in user-space, IMHO. 

the sequencer fits into this system because of the abstraction it
provides of the existing (currently just MIDI-related) device drivers,
turning them into subscribable event queues.

but having to cross into the kernel every time we want to deliver or
receive an event is not the way to go, i think.

--p

From - Sun Oct 10 22:34:15 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA25231
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 15:03:40 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA20936 for linux-audio-dev-list; Sun, 10 Oct 1999 14:49:02 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA20931 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 14:48:58 -0400
Received: from localhost.localdomain (d212-151-44-51.swipnet.se [212.151.44.51]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id UAA09987; 
          Sun, 10 Oct 1999 20:44:15 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Kai Vehmanen <kaiv@wakkanet.fi>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: timing issues in a client/server enviroment
Date: Sun, 10 Oct 1999 20:03:23 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <Pine.LNX.4.10.9910101428060.752-100000@sculpcave.localdomain>
In-Reply-To: <Pine.LNX.4.10.9910101428060.752-100000@sculpcave.localdomain>
MIME-Version: 1.0
Message-Id: <99101020161905.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id UAA09987
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id PAA25231
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: db5aed35f7f9bcb59f4a1d439adcbdfe

On Sun, 10 Oct 1999, Kai Vehmanen wrote:
> On Sun, 10 Oct 1999, Benno Senoner wrote:
> 
> >> or more sample implementations is a great idea, but please don't
> >> anyone go off and think they are writing "the Linux Sound System".
> > I agree on the fact that apps should be able to do their own pugin hosting,
> > but sooner or later we will need some engine which allows routing and
> > integration of simultaneously running audio apps, 
> 
> I don't want to sound pessimistic, but it might be better to start 
> with something simpler. For instance, I'm currently using ALSA's 
> loopback device quite successfully for routing audio data between
> audio apps. With a few improvements/additions, ALSA's flexible 
> mixer design combined with ALSA-lib/driver functionality would serve a lot
> of purposes. And what's important, these things exist and are ready
> for use, now. 

Sample accurate sync between apps? Yes, that can be done in the
protocol, and that's one of the points with the Multimedia
Communication System. You'll be able to do what you're doing now,
you'll be able to do it about the same way but get real sync with the
new system, or you can use plug-ins in a central engine, if you want
the lowest possible latency. (The engine might even be running under
RTLinux if the user is a latency freak! :-)

Breaking and replacing the currently existing APIs is not the goal,
IMHO. Replacing the underlying implementation with an infrastructure
that can provide *both* the old and the new Apsis with the best
possible performance is, in the longer perspective. If we manage to
integrate the low level communication system with ALSA, we could get
very close soon.

However; the plug-in API first.

Just keep in mind that it must fit nicely with the communication
system, or we'll end up with little more than yet another "standard",
that inherently generates clumsy and inefficient implementations.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:34:16 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA25389
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 15:05:17 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA20945 for linux-audio-dev-list; Sun, 10 Oct 1999 14:49:08 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA20937 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 14:49:02 -0400
Received: from localhost.localdomain (d212-151-44-51.swipnet.se [212.151.44.51]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id UAA10030; 
          Sun, 10 Oct 1999 20:44:17 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] client/server stuff in MCS
Date: Sun, 10 Oct 1999 20:16:46 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910101633.MAA32037@op.net>
In-Reply-To: <199910101633.MAA32037@op.net>
MIME-Version: 1.0
Message-Id: <99101020330706.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id UAA10030
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id PAA25389
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 115c16f9ff00c25c9084439c54e04c8b

On Sun, 10 Oct 1999, Paul Barton-Davis wrote:
> [ i broke this out since it seems like a separate aspect of things
>   altogether 
> ]
> 
> this client/server stuff: what is a client ? my best guess so far might be a
> standalone program that wants to route its (say) audio through the
> MCS. it seems that you propose using the event system for
> this. 

Yes, and the event system goes with the (quite similar) streaming
interface. Or; the event API is actually a way of streaming events.

> ignoring my misgivings about this for a moment, this is handled very
> simply using a sensor thread plus the kind of shmem setup that Benno
> has described. the sensor thread behaves exactly as would a sensor
> thread reading from /dev/snd/pcmCnDnn. so thats easy.

Yep. :-)

> but wait a moment: this implies that we have to code other
> applications to use this system, and not the one that they would use
> if they were writing to /dev/snd/pcmCnDnn. this isn't nice. 

You can't have it all... But, you don't *have* to code applications
that way. The engine could read FIFOs as well. (At least if the
communication system is in the kernel - sync or performance problems
in user space?)

> i think that its a much better idea to use esd-like
> open/close/read/write redirection via LD_PRELOAD. our read/write
> wrapper can take care of mapping the system call into a "scribble in a
> shared memory buffer".  the open/close wrapper converts a device open
> to "shmget+shmat/shmdt" operations.

...or you could do it that way... But when did I suggest that there
should be no compatibility layer? That's not really a part of the
API, but of course, we have to keep it in mind.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:34:23 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA28515
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 15:35:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA21046 for linux-audio-dev-list; Sun, 10 Oct 1999 15:20:26 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA21043 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 15:20:21 -0400
Received: from localhost.localdomain (d212-151-44-51.swipnet.se [212.151.44.51]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id VAA19243; 
          Sun, 10 Oct 1999 21:15:36 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>
Subject: Re: [linux-audio-dev] API design again [MORE code]
Date: Sun, 10 Oct 1999 20:33:56 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
References: <199910101638.MAA10195@renoir.op.net>
In-Reply-To: <199910101638.MAA10195@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101021222707.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id VAA19243
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id PAA28515
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 68430ff56515413ac6fdf409c1de6436

On Sun, 10 Oct 1999, Paul Barton-Davis wrote:
> [ ... sleeping ... ]
> 
> >So where do you get the CPU time for other tasks, if the engine never
> >sleeps...? Or am I missing what you're actually saying here?
> 
> (for a moment there, i thought i had fallen into my "i have a dual CPU
> box and so does everyone else" trap. but fortunately, no ... )

Scary... *hehe*

> the engine sleeps whenever it calls a plugin that calls
> read/write. how long it sleeps depends on the i-node it reads/writes.
> if it never calls read/write, it will never sleep.

Ok, that's exactly the sleep point I had in mind...

> "nothing is calling read/write" is actually a pathological situation,
> but relatively easily dealt with. quasimodo and hdr both have to do
> this. for quasimodo, a plugin must be able to tell us if it does
> input. for hdr, if there are no inputs active then we stall the
> engine. we focus on input because output is handled in these programs
> by the "engine" itself. in MCS, this may not be true, so the
> work_to_do() test has to include active ins OR active outs. 

Yep. However, there's one thing to keep in mind here (at least with
the kernel MCS implementation I have in mind); it's perfectly
possible that the *engine* never calls an I/O plug-in, and therefore
never sleeps that way. Instead, it'll have to sleep on the MCS
connection it's supposed to be sync'ed with, after each finished
cycle. (Like Benno's client/server interface.)

> sensor threads should run with SCHED_FIFO, but its not clear to me if
> they should have a priority above or below or equal to that of the
> engine thread.

Above, as they have to be able to preempt the engine to get correct
timestamps.

> >Anyway... FIFO. Any other behavior would be erroneous and fatal in
> >this case. If your events are late for the cycle, you're missing a
> >deadline, which is a Very Bad Thing(tm) in a real time system.
> 
> >> >Actually, there's one more level; the transfer of the finished list
> >> >of events (for the cycle) to the destination port.
> >> 
> >> this can't happen without locking. we don't want to do this.
> >
> >A FIFO doesn't need locking in the single reader - single writer
> >case, and it also allows queueing of multiple event buffers. That
> >means we get cycle period matching almost for free. The engine only
> >needs to grab the buffers one by one and do the compulsory time stamp
> >conversion.
> 
> time stamp conversion ? the sensor thread should have timestamped the
> events with the same timebase as the engine. hence:
> 
>        ev->timestamp = engine->timestamp();

Yes... But that means plug-ins will recieve events with running sample
clock timestamps, rather than start of buffer == 0.

Both system work, but is it a good idea to force every single plug-in
to convert the timestamps of all events it recieves, or to keep track
of the time base of the port(s) they send to?

My idea is that time == local time, at least for plug-ins.

> >> sorry, this won't work. once again, a sensor thread is not going to
> >> wait for a command to "finish the cycle". its working asynchronously
> >> with respect to the engine.
> >
> >So, your "cycle time" will have to be based on the only wake up
> >source you have; the device you're sensing. However, that does not
> >mean that you have to pass one event at a time. Just send'em all of
> >before you go back to sleep.
> 
> well, yes, of course. but the point here is that this sending will
> happen (potentially) in the middle of the engine's control
> cycle, not at a point defined by the engine.

Yes, but if you're not missing the deadline, the event is going in
when it's supposed to; during the next cycle or later.

> the overall point here is to think of the engine as collecting events
> from the subscribable ports, not as the sensor threads delivering them
> anywhere. then all this "shadow port" stuff goes away. the only key
> thing, as i said before, is to ensure that we have reliable lock-free
> event queues for the ports.

Yes, but you want both threads to mess with the same event port
without locking?

1) The lock free queue gets in the inline code, rather than
   into the finish_cycle() API library *function call*.

2) There's no efficient way you can handle multiple senders
   to one port without shadow ports. Why *sort* events inside
   a lock free queue, when you can merge events from queues
   that you know contain events in order?

3) There's possibly more to the event port than point-to-point
   event transfer. This could mean more than one sync problem.
   How much complexity do we want to show through the API...?

IMO, direct access of the event port is only to be done when you're
in the same context (that is, same thread, same cycle time) as the
destination port, *and* you're the ony one sending to that port. (The
engine might work around that, but that's another story...) If there
are N senders, N-1 of them will get shadow ports, so that the engine
can get away with a single merge operation, in case the destination
port requires events to come in order. (Note: In VST 2.0, plug-ins
*have* to sort events themselves if they care... How nice is that?)

>  [ ... handling non-shared memory stuff ... ]
> 
> >Ok, just set up a communication thread with a sensible cycle rate, in
> >case event rate >> fixed latency. ("Fixed latency" being the jitter
> >elimination delay that makes time stamps useful.) What I mean is that
> >it's insane to send events 20 times during a single fixed latency
> >period.
>  
> not really, if you forget about this idea of "sending" as an active
> thing. you're just putting events on a queue. somebody else will take
> them off when they're ready.

Yes, with a lock free queue, you're right. And the communication
thread would still work.

> >No, that's not the idea. I only want to clean up the API, and make it
> >posible to change the implementation without breaking the API.
> >
> >API != implementation.
> 
> yep. and i think we agree that using a communication thread will
> satisfy this, so we can exclude all considerations of non-shared
> memory from our discussion :)

Yep, seems like it. :-)

However, let's not forget about non-shared memory completely, as that
might hurt a lot later on...

> >> aha! you admit it: "runs whenever it wants". this is why the
> >> "finish_cycle" operation idea won't work.
> >
> >finish_cycle() *can* be called whenever you want. (Plug-ins don't
> >need it, as returning from process() has the same meaning.) It's just
> >that *recommending* that it's not called more frequently than
> >necessary will make optimization of the implementation a bit easier.
> 
> you write as if the engine calls finish_cycle(), and this is what i
> meant would not work. sure, a sensor thread can do this whenever it
> likes, but then it doesn't need a special name - its just another
> thing the sensor thread does on its own.

What about the API, then? *Every* MCS "client" will need to do the
finish_cycle() operation, and as it's the perfect hook for special
MCS implementations, I think it's silly leaving it out. It could be a
NOP, but because of the shadow ports, it probably won't.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:34:10 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA24788
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 14:59:56 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA20912 for linux-audio-dev-list; Sun, 10 Oct 1999 14:44:21 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id OAA20909 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 14:44:18 -0400
From: est@hyperreal.org
Received: (qmail 2760 invoked by uid 162); 10 Oct 1999 18:40:00 -0000
Message-ID: <19991010184000.2759.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] API design again [MORE code]
In-Reply-To: <199910100406.AAA15959@renoir.op.net> from Paul Barton-Davis at
 "Oct 10, 1999 00:07:00 am"
To: Paul Barton-Davis <pbd@Op.Net>
Date: Sun, 10 Oct 1999 11:40:00 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 8adb1df918d822e982205bffedc53b41

Paul Barton-Davis discourseth:
> 
> But wait - how is the engine thread going to safely copy or otherwise
> use this data when the MIDI input thread (or any other h/w-driven
> thread) could modify the port's event list at any time ?
> 
> this, it seems, is where we might be able to use a lock free queue. we
> have exactly one writer and one reader per queue, making them OK for
> the kind of logic that Eli Brandt outlined (which was thankfully not
> a Herlihy-like compare-and-swap system). as Eli pointed out, this
> does rely on pointer writes being atomic and surrounding writes not
> being reordered, which we can probably ensure.

Those lock-free-qs also look like they'd allow you to snapshot a
subsequence at a given time--e.g., record the relevant pointers for
the next set of events you want to process.

Now, have I missed something, or do those qs only work for fixed
sizes?  Not that that is necessarily prohibitive.

Also, how can we know that the algorithm's requirements are met.  They
probably are, but I'd like to gather sources of reassurance in this
area for future reference.  For example, the glibc people say pointer
reads/writes are atomic on all systems they know of.  That's one
useful datum.

> notice that the use of '<' and '>' to test for head/tail
> relations are nominal, not actual C code. if we could use fixed size
> arrays of event_t's, then we could actually use '<' and '>', but this
> seems unlikely to satisfy us.

Again, as I understood it, the algorithm uses fixed size circular
buffers.

Eric

From - Sun Oct 10 22:34:20 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA25610
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 15:07:17 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA20958 for linux-audio-dev-list; Sun, 10 Oct 1999 14:52:23 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id OAA20955 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 14:52:20 -0400
From: est@hyperreal.org
Received: (qmail 4080 invoked by uid 162); 10 Oct 1999 18:48:02 -0000
Message-ID: <19991010184802.4079.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] Re: fifos & unix domain sockets
In-Reply-To: <99101004272505.00676@linuxhost.localdomain> from Benno Senoner
 at "Oct 10, 1999 04:21:05 am"
To: Benno Senoner <sbenno@gardena.net>
Date: Sun, 10 Oct 1999 11:48:02 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1fbd640dd9bed4a2d51d9e552bfc56e4

Benno Senoner discourseth:
> > 
> > I tested their throughput a couple of months ago on Linux.  They were
> > about 1.55 times slower than pipes/fifos.  A tcp connection on the
> > same machine was 1.6 times slower still (i.e., 2.5 times slower than
> > pipes/fifos).
> 
> ah, good to know !
> but how did you compare the fifos to unix sockets ?
> 
> make sure that you compare 2 FIFOs (for fullduplex)
> to 1 socket.
> Because fullduplex communication requires more context switches.

Ah..good point.  I only tested one-way transfer.  I suspect, however,
that the proportions would be similar for full-duplex.

Eric

From - Sun Oct 10 22:34:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA29013
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 15:40:15 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA21053 for linux-audio-dev-list; Sun, 10 Oct 1999 15:27:42 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA21050 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 15:27:37 -0400
Received: from localhost.localdomain (d212-151-44-51.swipnet.se [212.151.44.51]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id VAA21732; 
          Sun, 10 Oct 1999 21:22:41 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Jaroslav Kysela <perex@suse.cz>
Subject: Re: [linux-audio-dev] plugin questions
Date: Sun, 10 Oct 1999 21:23:05 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
References: <Pine.LNX.4.05.9910101851480.14177-100000@gate.suse.cz>
In-Reply-To: <Pine.LNX.4.05.9910101851480.14177-100000@gate.suse.cz>
MIME-Version: 1.0
Message-Id: <99101021293208.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id VAA21732
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id PAA29013
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1be43d565b9acc544360a84d1e819a66

On Sun, 10 Oct 1999, Jaroslav Kysela wrote:
> > What about all the callbacks that VST plug-ins do to the host?
> 
> Please, forget about any callback implementation inside the communication 
> API. Imagine that one communication node can be inside the kernel space
> and other inside the user space. We can't use a callback with this
> combination.

*Exactly.* That's why I want to use the same API, the event system,
for "everything", as that eliminates the need for messy RPC style
cludges in the API library.

Ok, a plug-in will always run in the same thread as it's host, but is
that an excuse to use callbacks or info structures in that special
case? I don't think so. Uniform interfaces mean more code reuse. What
seems to simplify a little in a particular case, could actually
complicate the full system.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:34:28 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA29410
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 15:43:58 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA21064 for linux-audio-dev-list; Sun, 10 Oct 1999 15:30:50 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA21061 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 15:30:46 -0400
Received: from localhost.localdomain (d212-151-44-51.swipnet.se [212.151.44.51]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id VAA01719; 
          Sun, 10 Oct 1999 21:25:57 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>
Subject: Re: [linux-audio-dev] plugin questions
Date: Sun, 10 Oct 1999 21:30:25 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <199910101659.MAA11183@renoir.op.net>
In-Reply-To: <199910101659.MAA11183@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101021324809.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id VAA01719
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id PAA29410
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1f8283878afdf12d263d3ac015e6c217

On Sun, 10 Oct 1999, Paul Barton-Davis wrote:
> >Please, forget about any callback implementation inside the communication 
> >API. Imagine that one communication node can be inside the kernel space
> >and other inside the user space. We can't use a callback with this
> >combination.
> 
> thats why the ALSA sequencer, as truly wonderful as it is, is not the
> right answer to the system we're trying to build. its a valuable part
> of it, but it cannot be the core of it for all kinds of reasons, this
> being one of them.

Data is data. How big is the difference between these ways of
passing it around, in the big picture? So big that it invalidates the
point with a uniform API?


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:34:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA02758
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 16:47:30 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA21185 for linux-audio-dev-list; Sun, 10 Oct 1999 16:31:48 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA21182 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 16:31:43 -0400
Received: from localhost.localdomain (d212-151-44-51.swipnet.se [212.151.44.51]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id WAA12593; 
          Sun, 10 Oct 1999 22:26:55 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>
Subject: Re: [linux-audio-dev] plugin questions
Date: Sun, 10 Oct 1999 21:38:13 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <199910101746.NAA13480@renoir.op.net>
In-Reply-To: <199910101746.NAA13480@renoir.op.net>
MIME-Version: 1.0
Message-Id: <9910102233460A.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id WAA12593
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id QAA02758
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 364cbe3113ea022b87ca9572ba99fe9a

On Sun, 10 Oct 1999, Paul Barton-Davis wrote:
[...]
> in your scheme, when a plugin changes it mind (and the example above
> is a *very* likely one in my experience), you have to broadcast the
> change to everyone who might care, which actually means everyone.

Why would a plug-in want to change it's input setup in a way that
affects other parts of the net? That's the same thing as changing
the net, and I *don't* think plug-ins should do that directly.

A plug-in could just publish a list of inputs that it *might* use,
just as a mixer would publish it's audio input channels - despite the
fact that they can be muted. Why add another level of routing to the
event system?

[...]
> there is a big difference between port connections that are driven
> by a user metaphorically (or literally, I don't know :) dragging a
> patch cord from one place to another, and those that happen
> because the user presses a button on a plugin GUI which says
> "Controller ID".

Yes, but that's only on the GUI level, IMO.

> in the latter case, when the plugin does its stuff to respond to a
> message from the GUI ("multiway switch XXX now has value 64"), it
> doesn't don't connect to anything as the *source*. it connects to
> another port as the *destination*. thats a key difference that ensures
> the connections "matter".

As I said, I think connecting belongs in the engine...

> in the former case (user dragging patch cords): when you're dealing
> with typed events, which we're proposing, you (the user) can only
> connect meaningfully two ports of the same type. if you connect an
> audio port to an audio port, you're guaranteed that the destination
> will care.

No. The input could be muted. :-)

> but if you connect an audio port to a MIDI port, you can be
> certain that you'll be ignored, if you can do it all.

Well, that's a bit outside the scope... There are event ports and
audio ports. Period.

> so think about this a little bit more: what are the different event
> types ?  if you have only a few of them, then you'll be asking plugins
> to process all kinds of events that they *just don't care about*. if
> you have a lot, and you enforce type equivalency when connecting, you
> know you'll be paid attention to.

Actually, type is one thing, *address* (ie CC numbers) is another.
What I want is the ability to build a standard GUI using the
information the plug-in provides, if we for some reason don't want to
use the custom one, or if there *is* no custom GUI. That does not
imply that the events themselves are typed in some way; requiring all
events to be floats 0.0 .. 1.0 would do. If you don't want that,
*real* event type can be used. Perhaps that's the way to go? Or do we
need integers, and perhaps some other types as well?

Anyway, the address thing... Two dimensions. A plug-in handles a
number of different event "addresses". (Each one of a specific type,
if we have more than one type.) Plug-ins may also send events on a few
"addresses". Now, there are 3 places where the events can be remapped:

1) In the sending plug-in.

2) In the engine.

3) In the recieving plug-in.

My suggestion is that this is handled in the same domain where the
connecting of event ports is handled; that is, in the engine, as I
see it for the moment...

> >Don't you want to know what MIDI events a synth supports?
> 
> Well, yes and no. If the synth comes with a MIDI IN port, and I connect
> some MIDI OUT port to it, then in order to use it effectively, I need
> to know which MIDI events make a difference.
> 
> But if the synth has a button which says "MIDI Controller ID" and
> controls, say, the controller that sets pitch bend, then I don't care
> to know anymore: when I press the button, the plugin will do the right
> thing.
> 
> So again, it comes back to event types. If ports can only be
> distinguished on the basis of being Audio or MIDI, then somebody will
> have to tell us which MIDI events the plugin will use if we are to
> usefully use a MIDI connection.
> 
> If, on the other hand, a port comes with a more specific type, say
> "Audio level above XXdB" or "MIDI controller 32", then we need know
> very little about a plugin to use it - the plugin will be able to
> establish its own connections based on its current state ("Oh, the GUI
> wants me to start monitoring audio levels above XXdB. OK, I'd better
> establish a connection to ...")

A connection to... what? That's the problem here.

[...]
> The MIDIPort objects have no idea who is
> listening to them, they just do their stuff, and when it matters, the
> right objects get to hear about it.

Ok... Looks like the most significant difference here is how someone
gets the idea to listen to a port. You want the plug-in to establish
a connection when someone wants it to, while I want the engine to do
that. The rest is little more than info details for the GUI.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:34:31 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA05175
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 17:11:36 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA21195 for linux-audio-dev-list; Sun, 10 Oct 1999 16:42:59 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA21192 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 16:42:54 -0400
Received: from localhost.localdomain (d212-151-44-51.swipnet.se [212.151.44.51]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id WAA27296; 
          Sun, 10 Oct 1999 22:37:44 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        Linux Audio Development Mailing list <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] plugin questions
Date: Sun, 10 Oct 1999 22:34:46 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910101751.NAA13807@renoir.op.net>
In-Reply-To: <199910101751.NAA13807@renoir.op.net>
MIME-Version: 1.0
Message-Id: <9910102244350B.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id WAA27296
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id RAA05175
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d1624609805fbfc9baa031051cdd1588

On Sun, 10 Oct 1999, Paul Barton-Davis wrote:
[...]
> crossing the user/kernel boundary is too expensive for distributing
> events which the kind of response we want. the communication system
> needs to reside in user-space, IMHO.

User/kernel "switches" are not nearly as expensive as real context
switches. This is not Windows... ;-)

> the sequencer fits into this system because of the abstraction it
> provides of the existing (currently just MIDI-related) device drivers,
> turning them into subscribable event queues.
> 
> but having to cross into the kernel every time we want to deliver or
> receive an event is not the way to go, i think.

Once every time you want to end a cycle. That's why I designed the
inline memory allocator. If you set up a thread to wake up, get the
current time, and then send some out-of-band events rather frequently,
then you're already wasting orders of magnitude more on context
switching than the cost of a kernel call. (Unless I completely
missunderstood the kernel call vs. context switch discussion on
l-k...)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:34:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA09462
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 17:52:24 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA21331 for linux-audio-dev-list; Sun, 10 Oct 1999 17:32:01 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA21328 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 17:31:59 -0400
Received: from someip.ppp.op.net (d-bm2-1c.ppp.op.net [209.152.194.60]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id RAA24986; Sun, 10 Oct 1999 17:27:16 -0400 (EDT)
Message-Id: <199910102127.RAA24986@renoir.op.net>
To: David Olofson <audiality@swipnet.se>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] plugin questions 
In-reply-to: Your message of "Sun, 10 Oct 1999 21:38:13 +0200."
             <9910102233460A.00456@localhost.localdomain> 
Date: Sun, 10 Oct 1999 17:27:58 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d938045885d86c7b99e428599158528c

... the one i was waiting for ... :)

>Why would a plug-in want to change it's input setup in a way that
>affects other parts of the net? That's the same thing as changing
>the net, and I *don't* think plug-ins should do that directly.

what is "directly" ? what else do they do, submit a request event to
the engine ? all this does is to delay the connection change till the
end of the cycle/beginning of the next. this introduces a potentially
rather complex event type ... why not let the plugin make the relevant
call itself ? 

given your predeliction for speed, think about the cache benefits of
letting a plugin, which has just received a message about a desired
reconnection from somewhere, and may well have touched some or all of
the relevant data in understanding it, go ahead and make the
reconnection itself while the stuff is still around in a cache line.

:)

>What I want is the ability to build a standard GUI using the
>information the plug-in provides, if we for some reason don't want to
>use the custom one, or if there *is* no custom GUI. That does not
>imply that the events themselves are typed in some way; requiring all
>events to be floats 0.0 .. 1.0 would do. If you don't want that,
>*real* event type can be used. Perhaps that's the way to go? Or do we
>need integers, and perhaps some other types as well?

ah! you didn't say this *at all*. that makes all the difference in the
world. my entire thinking has been that plugins are responsible for
their own GUI. a note, however, if we do end up going down this
pathway: most quasimodo modules, for example, typically have 4-10x more
internal parameters than they actually display as sockets, knobs,
etc. for MSC, each of those parameters might be specified as having an
associated event port, but that doesn't mean that any of them should
show up in the GUI. so you're going to need a "visible" tag associated
with each port to indicate if it appear in the GUI.

as for the "all floats" idea. this can work - its what quasimodo does
for example - but there is a problem if a plugin needs string
values (say, for a soundfile name). i did a strange and somewhat
beautiful hack in quasimodo, in which all such arguments are encoded
as IEEE 32 bit NaN values. There are 22-23 spare bits in a NaN for
indexing into a global string array ....

but it *is* a hack, and so we probably want to allow passing of
strings or other sized data as well as numeric data. note also the
fierce arguments on the Csound mailing list about the preferability of
double over float ...

>> If, on the other hand, a port comes with a more specific type, say
>> "Audio level above XXdB" or "MIDI controller 32", then we need know
>> very little about a plugin to use it - the plugin will be able to
>> establish its own connections based on its current state ("Oh, the GUI
>> wants me to start monitoring audio levels above XXdB. OK, I'd better
>> establish a connection to ...")
>
>A connection to... what? That's the problem here.

as my example showed:

 engine_connect (engine_get_port ("Audio Level above XXdb"),
                 plugin->some_port);


From - Sun Oct 10 22:34:36 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA13527
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 18:26:38 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA21405 for linux-audio-dev-list; Sun, 10 Oct 1999 18:11:05 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA21402 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 18:11:01 -0400
Received: from localhost.localdomain (d212-151-43-113.swipnet.se [212.151.43.113]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA15934; 
          Mon, 11 Oct 1999 00:06:17 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>
Subject: Re: [linux-audio-dev] plugin questions
Date: Sun, 10 Oct 1999 23:38:16 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <199910102127.RAA24986@renoir.op.net>
In-Reply-To: <199910102127.RAA24986@renoir.op.net>
MIME-Version: 1.0
Message-Id: <9910110013080C.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id AAA15934
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA13527
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 13c8b7717a76779f6cef7b8ec5d16a66

On Sun, 10 Oct 1999, Paul Barton-Davis wrote:
> ... the one i was waiting for ... :)
> 
> >Why would a plug-in want to change it's input setup in a way that
> >affects other parts of the net? That's the same thing as changing
> >the net, and I *don't* think plug-ins should do that directly.
> 
> what is "directly" ? what else do they do, submit a request event to
> the engine ? all this does is to delay the connection change till the
> end of the cycle/beginning of the next. this introduces a potentially
> rather complex event type ... why not let the plugin make the relevant
> call itself ? 

Nonono, that's not what I meant! :-) Yes, a plug-in *could* (just as
any other node on the MCS net) talk some to the engine, and even ask
it to build a little private sub net or whatever (oops... the
permission control system needs to step in here), but a normal
plug-in would not even *know about* such operations. It just recieves
evenst and data, and sends events and data - in the normal case using
only a set of audio ports, one input event port, and one output event
port.

> given your predeliction for speed, think about the cache benefits of
> letting a plugin, which has just received a message about a desired
> reconnection from somewhere, and may well have touched some or all of
> the relevant data in understanding it, go ahead and make the
> reconnection itself while the stuff is still around in a cache line.
> 
> :)

What about letting the engine handle the events it recieved on it's
own port, and leave all plug-ins affected by net modification
requests alone...?

> >What I want is the ability to build a standard GUI using the
> >information the plug-in provides, if we for some reason don't want to
> >use the custom one, or if there *is* no custom GUI. That does not
> >imply that the events themselves are typed in some way; requiring all
> >events to be floats 0.0 .. 1.0 would do. If you don't want that,
> >*real* event type can be used. Perhaps that's the way to go? Or do we
> >need integers, and perhaps some other types as well?
> 
> ah! you didn't say this *at all*.

No, I was probably too lost in the low level details... *hehe*

> that makes all the difference in the
> world. my entire thinking has been that plugins are responsible for
> their own GUI. a note, however, if we do end up going down this
> pathway: most quasimodo modules, for example, typically have 4-10x more
> internal parameters than they actually display as sockets, knobs,
> etc. for MSC, each of those parameters might be specified as having an
> associated event port, but that doesn't mean that any of them should
> show up in the GUI.

So, describe them as "Advanced", "Hidden", or even "Private"...

> so you're going to need a "visible" tag associated
> with each port to indicate if it appear in the GUI.

Yep, or perhaps something more flexible, as described above.

> as for the "all floats" idea. this can work - its what quasimodo does
> for example

So does VST.

(VST events are a different, though; they're a dirty MIDI support
hack for soft synths, and some kinds of events actually carry raw
MIDI data! *aaargh!* What a cludge... Isn't one switch() for *all*
events fun enough? ;-)

> - but there is a problem if a plugin needs string
> values (say, for a soundfile name).

Yep. That's why I suggested types. And variable size events...

> i did a strange and somewhat
> beautiful hack in quasimodo, in which all such arguments are encoded
> as IEEE 32 bit NaN values. There are 22-23 spare bits in a NaN for
> indexing into a global string array ....
> 
> but it *is* a hack, and so we probably want to allow passing of
> strings or other sized data as well as numeric data. note also the
> fierce arguments on the Csound mailing list about the preferability of
> double over float ...

Agreed. Just not more types than necessary, and well defined
casting/conversion rules are needed, so we don't end up with plug-ins
that are incompatible for no logical reason.

> >> If, on the other hand, a port comes with a more specific type, say
> >> "Audio level above XXdB" or "MIDI controller 32", then we need know
> >> very little about a plugin to use it - the plugin will be able to
> >> establish its own connections based on its current state ("Oh, the GUI
> >> wants me to start monitoring audio levels above XXdB. OK, I'd better
> >> establish a connection to ...")
> >
> >A connection to... what? That's the problem here.
> 
> as my example showed:
> 
>  engine_connect (engine_get_port ("Audio Level above XXdb"),
>                  plugin->some_port);

Yes... But that means the plug-in is (indirectly) responsible for
looking up the port. And that, in turn, means that - unless the event
that causes the plug-in to connect contains full information on what
to connect to - you end up with a system where you can't connect to
outputs of other plug-ins in any obvious way. How to address the
output of another plug-in? And what about event address remapping?
(As I assume the normal plug-in has only one input port and one output
port.)

This is standard translation code that would *have* to be in *every*
plug-in that cares about getting connected via the event system. I
see no valid reason not to make it a part of the engine instead. What
would you be able to do, that can't be done if the engine does the
connecting and mapping?


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:34:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA14932
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 18:39:12 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA21425 for linux-audio-dev-list; Sun, 10 Oct 1999 18:23:19 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA21422 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 18:23:16 -0400
Received: from localhost.localdomain (d212-151-43-113.swipnet.se [212.151.43.113]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA10925; 
          Mon, 11 Oct 1999 00:18:32 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Jaroslav Kysela <perex@suse.cz>,
        Linux Audio Development Mailing list <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] plugin questions
Date: Mon, 11 Oct 1999 00:14:15 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <Pine.LNX.4.05.9910101909410.14883-100000@gate.suse.cz>
In-Reply-To: <Pine.LNX.4.05.9910101909410.14883-100000@gate.suse.cz>
MIME-Version: 1.0
Message-Id: <9910110025240D.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id AAA10925
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA14932
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 07a5da0cb0bb5fa7607424d3caf5805e

On Sun, 10 Oct 1999, Jaroslav Kysela wrote:
> I'm lost here. I though that we are speaking about an event based
> communication system with nodes inside user or kernel space.
> Every callback can be implemented as two event calls (request &
> reply).

Yes, and that works for plug-ins as well as nodes.

It can be as simple as the engine calling the plug-in init()
function until both are happy - just to make the control flow
virtually identical to that of two nodes having an initialization
chat. Again, a uniform API.

(I'm not saying that the plug-in init() sequence - or the
corresponding session for nodes for that matter - *should* be some
kind of event ping-pong. That would indicate that there's a problem
with the design of the init procedures.)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:34:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA17630
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 19:05:39 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA21454 for linux-audio-dev-list; Sun, 10 Oct 1999 18:48:55 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA21451 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 18:48:52 -0400
Received: from localhost.localdomain (d212-151-43-113.swipnet.se [212.151.43.113]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA29884 for <linux-audio-dev@ginette.musique.umontreal.ca>; 
          Mon, 11 Oct 1999 00:44:12 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] MCS: 64 bit timestamps?
Date: Mon, 11 Oct 1999 00:32:25 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <9910110051040E.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id AAA29884
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA17630
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: e1ab1e016740ed08cdce019002bdcad8

Hey! I just remembered one thing I thought about the other day:
timestamp type.

The timestamps we have been talking about so far are sample counts.
My idea of local time in sub nets means that every cycle will start
at sample 0, and max 2 Gsamples/cycle is probably quite acceptable
for most people. (Hey, there *are* oscilloscope boards with 10 - 40
MHz sample rate, and buffers may be longer than one second, so we're
not *that* safe!)

But what happens with the running (sample) time? It's not a big deal
to handle wrapping in the engine, and as long as local time is always
relative to the start af the current cycle, there's not much of a
problem.

However, as seen in Paul's sensor thread example, it makes sense to
use absolute time in some situations, let alone as the global time
used by the MCS.

So, 64 bit time and timestamps?


//David


PS. What about my unofficial TLA "MCS" (Multimedia Communication
System)...? MuCoS? Well, at least it shortens the posts by half a line
every time used! :-)


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sun Oct 10 22:34:47 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA21543
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 19:40:44 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA21522 for linux-audio-dev-list; Sun, 10 Oct 1999 19:23:59 -0400
Received: from breton.uol.com.br (breton.uol.com.br [200.230.198.74]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA21519 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 19:23:54 -0400
Received: from default ([200.191.148.159])
	by breton.uol.com.br (8.9.1/8.9.1) with SMTP id VAA23280
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 21:19:12 -0200 (BRST)
Received: by default with Microsoft Mail
	id <01BF1365.475A7B40@default>; Sun, 10 Oct 1999 21:20:29 -0300
Message-ID: <01BF1365.475A7B40@default>
From: Rafael Flister Monteiro <flister@uol.com.br>
To: "'linux-audio-dev@ginette.musique.umontreal.ca'"
	 <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] full-duplex
Date: Sun, 10 Oct 1999 21:20:17 -0300
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA21543
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 5447740be9c9243995a644ca9f9e60e4

Hello,

I am a graduate student from Brazil and I am starting to work with sound programming under Linux. I would like to know if you could help me. 
I have been having problems with full-duplex operation, I created two processes, the first reads 16 milliseconds of sound samples from de microphone and sends them to the second process using an UDP socket. The second process receives these samples and writes them on the soundcard. 
I opened the device for reading and writing (O_RDWR), set the full-duplex option and set the fragment size (0x7fff0007). But I am not able to read and write the amount of data that I ask.
What are the problems involved in full-duplex operation?

I will be very thankful if you could help me.

Thanks.

Rafael Flister Monteiro
Telecommunications Engineering 
CPDEE/UFMG - Belo Horizonte - MG - Brazil
flister@novell.cpdee.ufmg.br
flister@uol.com.br

From - Sun Oct 10 23:11:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA12324
	for <slinkp@ulster.net>; Sun, 10 Oct 1999 23:00:51 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA22063 for linux-audio-dev-list; Sun, 10 Oct 1999 22:28:13 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA22060 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 22:28:11 -0400
Received: from someip.ppp.op.net (d-bm3-06.ppp.op.net [209.152.194.70]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id WAA11380 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 22:23:30 -0400 (EDT)
Message-Id: <199910110223.WAA11380@renoir.op.net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] MCS: 64 bit timestamps? 
In-reply-to: Your message of "Mon, 11 Oct 1999 00:32:25 +0200."
             <9910110051040E.00456@localhost.localdomain> 
Date: Sun, 10 Oct 1999 23:18:55 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1c066f0298107a35defd47123ad3c9aa

>So, 64 bit time and timestamps?

yes. even more significant given that the pentium cycle counter uses
such values, though many cycle counter users only read the low order
32 bits.

gcc is not to bad at dealing with "long long" arithmetic, either.

another word about timestamps though. you suggested that in order to
call engine->timestamp(), a sensor thread would have to preempt the
engine. Not true. more importantly, if every plugin/thread uses local
time, and that thread has no sample time base to clock from, how can
the engine ever convert events from that plugin/thread to its own time
base ?

this is where we need to go back to your suggestion of using the cycle
counter to determine the current sample number. its easy to do, and
provides very, very lightweight timing for any and everyone in the
system. 

yes, it won't work on, say, a MIPS chip, but the alpha and all intel
chips have a cycle counter. don't know about the ultrasparc.

--p

From - Mon Oct 11 00:21:20 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA18472
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 00:06:11 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA22156 for linux-audio-dev-list; Sun, 10 Oct 1999 23:41:59 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA22153 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 23:41:56 -0400
Received: from localhost.localdomain (d212-151-37-29.swipnet.se [212.151.37.29]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id FAA22038; 
          Mon, 11 Oct 1999 05:37:13 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] MCS: 64 bit timestamps?
Date: Mon, 11 Oct 1999 05:26:34 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910110223.WAA11380@renoir.op.net>
In-Reply-To: <199910110223.WAA11380@renoir.op.net>
MIME-Version: 1.0
Message-Id: <9910110544040I.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id FAA22038
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id AAA18472
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 26956a6ce1afe55e0bf78187aa23e6a5

On Mon, 11 Oct 1999, Paul Barton-Davis wrote:
> >So, 64 bit time and timestamps?
> 
> yes. even more significant given that the pentium cycle counter uses
> such values, though many cycle counter users only read the low order
> 32 bits.
> 
> gcc is not to bad at dealing with "long long" arithmetic, either.
> 
> another word about timestamps though. you suggested that in order to
> call engine->timestamp(), a sensor thread would have to preempt the
> engine. Not true.

So, how do you find out when the event that woke you up actually
occurred, if the engine blocks you out for a few ms? If that was
possible, there would be *no need* for sensor threads. (And there
isn't, if the drivers can timestamp data - which is currently not the
case with most of them.)

> more importantly, if every plugin/thread uses local
> time, and that thread has no sample time base to clock from, how can
> the engine ever convert events from that plugin/thread to its own time
> base ?

local_time = sample_count / current_cycle;

It's just a matter of convenience for plug-ins, and I doubt it makes
any sense to threads/MCS nodes. It does inside plug-ins, however,
especially in big nets with intense event activity, as it means that
plug-ins don't have to keep track of time as anything but offsets
from the first sample in the current cycle.

> this is where we need to go back to your suggestion of using the cycle
> counter to determine the current sample number. its easy to do, and
> provides very, very lightweight timing for any and everyone in the
> system. 
> 
> yes, it won't work on, say, a MIPS chip, but the alpha and all intel
> chips have a cycle counter. don't know about the ultrasparc.

A good time source - with a known relation to the sample time base -
is needed for *real time* events. As soon as you have events stamped
with sample time, it becomes irrelevant. So as long as we don't have
drivers that provide timestamping, TSC or some other timer + sensor
threads will be needed...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Mon Oct 11 00:41:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA19856
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 00:24:59 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA22151 for linux-audio-dev-list; Sun, 10 Oct 1999 23:41:12 -0400
Received: from heroine.tampa.fl.us (alpha-iota97.resnet.usf.edu [131.247.220.97]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id XAA22148 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 23:41:10 -0400
Received: (qmail 3587 invoked from network); 11 Oct 1999 03:38:41 -0000
Received: from unknown (HELO earthling.net) (root@127.0.0.1)
  by 127.0.0.1 with SMTP; 11 Oct 1999 03:38:41 -0000
Message-ID: <38015BBD.254BC1B@earthling.net>
Date: Sun, 10 Oct 1999 23:38:37 -0400
From: Adam Williams <broadcast@earthling.net>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] full-duplex
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 417c3754077f39d434af93ef2ec82e27

> What are the problems involved in full-duplex operation?

The standardization of the audio API ends with full duplex.  OSS Free,
ALSA, and OSS commercial have incompatible interfaces.  Also you need to
handle different soundcards differently.

OSS Commercial:
Open /dev/dsp RDONLY 16 bits 2 channels for recording.
Open /dev/dsp again WRONLY 8 bits 2 channels for playback.
Playback can start and stop during recording.

OSS/Free:
Open /dev/dsp RDWR 16 bits 2 channels for record and playback.
Either start recording before playback or playback before recording. The
order is important and it changes all the time.
Playback buffers must not underrun or the recording stops.

ALSA:
Won't compile with gcc-2.95 but it's probably similar to OSS/Free.

For tinkering just focus on OSS commercial since it's the easiest to
work with and will save you time.
-- 
                               Heroine Virtual
                        freeyellow.com/members4/heroine
                      Render the impossible into reality

From - Mon Oct 11 00:21:23 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA18903
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 00:11:56 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA22179 for linux-audio-dev-list; Sun, 10 Oct 1999 23:50:26 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA22176 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 10 Oct 1999 23:50:23 -0400
Received: from localhost.localdomain (d212-151-37-29.swipnet.se [212.151.37.29]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id FAA27091; 
          Mon, 11 Oct 1999 05:45:40 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] MCS: 64 bit timestamps?
Date: Mon, 11 Oct 1999 05:45:10 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910110223.WAA11380@renoir.op.net>
In-Reply-To: <199910110223.WAA11380@renoir.op.net>
MIME-Version: 1.0
Message-Id: <9910110552310J.00456@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id FAA27091
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id AAA18903
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0f033ba343d6f8034457e6f4329d1509

On Mon, 11 Oct 1999, Paul Barton-Davis wrote:

Waidaminnit! Too tired for this... :-)

> another word about timestamps though. you suggested that in order to
> call engine->timestamp(), a sensor thread would have to preempt the
       ^^^^^^^^^^^^^^^^^^^
What does this function do, exactly?

If it reads the current cycle count (in samples or whatever), it's
useless for sensor threads anyway - it'll only update once every
cycle.

I assume this is not the case, but that it reads the TSC and converts
into a timestamp using the engine's time base. That still means you
have to preempt the engine for it to make much sense...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Mon Oct 11 01:31:18 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA23837
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 01:22:32 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA22283 for linux-audio-dev-list; Mon, 11 Oct 1999 00:53:06 -0400
Received: from alsa.alsa-project.org (alsa.jcu.cz [160.217.1.49]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA22280 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 00:53:04 -0400
Received: from localhost (andy@localhost)
	by alsa.alsa-project.org (8.8.8/8.8.8) with ESMTP id GAA12090;
	Mon, 11 Oct 1999 06:48:22 +0200
Date: Mon, 11 Oct 1999 06:48:22 +0200 (MEST)
From: Andy Lo A Foe <andy@alsa-project.org>
To: Adam Williams <broadcast@earthling.net>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] full-duplex
In-Reply-To: <38015BBD.254BC1B@earthling.net>
Message-ID: <Pine.LNX.4.05.9910110642000.7862-100000@alsa.alsa-project.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: a1e5769cfbfe21651e0caad5ee806e6c

On Sun, 10 Oct 1999, Adam Williams wrote:

> ALSA:
> Won't compile with gcc-2.95 but it's probably similar to OSS/Free.

FWIW ALSA compiles just fine with gcc-2.95.2

Andy
--
AlsaPlayer, http://www.alsa-project.org/~andy/

From - Mon Oct 11 00:51:18 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA20772
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 00:37:28 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA22239 for linux-audio-dev-list; Mon, 11 Oct 1999 00:09:19 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA22236 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 00:09:17 -0400
Received: from someip.ppp.op.net (d-bm3-07.ppp.op.net [209.152.194.71]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id AAA17257 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 00:04:36 -0400 (EDT)
Message-Id: <199910110404.AAA17257@renoir.op.net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] MCS: 64 bit timestamps? 
In-reply-to: Your message of "Mon, 11 Oct 1999 05:45:10 +0200."
             <9910110552310J.00456@localhost.localdomain> 
Date: Mon, 11 Oct 1999 01:00:02 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 870e27a3f991189e993eb5772e6f0e18

>> another word about timestamps though. you suggested that in order to
>> call engine->timestamp(), a sensor thread would have to preempt the
>       ^^^^^^^^^^^^^^^^^^^
>What does this function do, exactly?

msc_time_t
Engine::timestamp ()

{
	/* greatly un-inlined to make function clear ... */

	tsc_t current_cycle_counter;
	tsc_t cycle_diff;	
	msc_time_t now;

        current_cycle_counter = read_tsc ();
	cycle_diff = current_cycle_counter -
	             cycle_counter_at_start_of_control_loop;
        now = (msc_time_t) (samples_per_cycle * (float) cycle_diff));

        return now;		
}

all the engine has to do is to compute samples_per_cycle during its
initialization, and then update
    
    cycle_counter_at_start_of_control_loop => pretty obvious semantics

all other threads can access the current engine timestamp without
affecting the engine thread in any way.

this doesn't take sample clock drift into account. the engine would
have to deal with this by adjusting the
cycle_counter_at_start_of_control_loop value at appropriate intervals
to shift everyone's idea of the current time.

OK ?

--p

From - Mon Oct 11 01:41:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA24358
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 01:33:04 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id BAA22323 for linux-audio-dev-list; Mon, 11 Oct 1999 01:12:50 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA22320 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 01:12:48 -0400
Received: from someip.ppp.op.net (d-bm3-07.ppp.op.net [209.152.194.71]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id BAA20057 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 01:08:07 -0400 (EDT)
Message-Id: <199910110508.BAA20057@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] full-duplex 
In-reply-to: Your message of "Sun, 10 Oct 1999 23:38:37 EDT."
             <38015BBD.254BC1B@earthling.net> 
Date: Mon, 11 Oct 1999 02:03:33 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c471cc295481b0a6a75851173312bf1e

>ALSA:
>Won't compile with gcc-2.95 but it's probably similar to OSS/Free.

ALSA:
1) open the device O_RDWR. then use it the way you'd expect,
   independent of the card type or anything else.

OSS/Free or OSS/Commercial:
1) forget about it for full-duplex. its just not reliable and/or too
card dependent.

--p

ps. if the kernel doesn't compile with gcc-2.95, which i suspect it
does not, there is no reason why any set of device drivers should be
expected to.

From - Mon Oct 11 02:40:42 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id CAA27100
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 02:30:50 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id CAA26183 for linux-audio-dev-list; Mon, 11 Oct 1999 02:05:19 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA26180 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 02:05:16 -0400
Received: from ulster.net (port49.ts2.ulster.net [208.242.164.49])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id CAA25892;
	Mon, 11 Oct 1999 02:02:18 -0400
Message-ID: <38017ED4.5674A16D@ulster.net>
Date: Mon, 11 Oct 1999 02:08:20 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Kai Vehmanen <kaiv@wakkanet.fi>
CC: LAD <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] linux audio apps/authors behind 
 open-plugin-whatever
References: <Pine.LNX.4.10.9910092125210.5477-100000@sculpcave.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e71b5dcf75673a8928edb5e8492d9848

Kai Vehmanen wrote:
> 
> No answer, so let's ask again...
> 
> So far:
> 
> - Audiality
> - Quasimodo
> - oolaboola (?)
> - ecasound
> 
> Other list actives, are you working on some project?
> 
> - Paul Winkler

Hi!

I'm not doing anything that's really relevant to the plugin API,
except skimming other peoples' posts on it and trying to understand.
Mostly failing to understand actually.

As for what I am working on: Only the Audio Quality HOWTO and its
imminent re-implementation as a cgi-automated FAQ machine.

And I have recently hacked a little bit of "pysco", which is
the python translation of "pscore", which never did very much
anyway. It's more a learning project for me than anything.

Oh yeah, I'm also trying to write an analog-like compressor in
csound that actually works, since the "dam" opcode seems to sound
bad. So far I have it basically working with analog-style ratio
parameter (e.g. "4" means "4 to 1 compression"). Attack control
works, but the more important Release control does not work yet; but
I think I know how to do it. I haven't done any kind of Threshold
control yet, either. If I get this to work well, I'll happily post
it around ... might make a useful Quasimodule, or someone could
figure out how to translate it into a plugin for the API!

--PW
----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Tue Oct 12 01:08:20 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA17390
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 09:05:00 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA26925 for linux-audio-dev-list; Mon, 11 Oct 1999 08:30:32 -0400
Received: from sculpcave (cvx-2-34.dyn.nic.fi [62.236.99.34]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA26915 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 08:30:18 -0400
Received: from localhost (localhost [127.0.0.1])
	by sculpcave (Postfix) with ESMTP
	id 0034334D3B; Mon, 11 Oct 1999 12:26:26 +0300 (EEST)
Date: Mon, 11 Oct 1999 12:26:26 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
X-Sender: root@sculpcave.localdomain
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] linux audio apps/authors behind open-plugin-whatever
In-Reply-To: <99101019370203.00456@localhost.localdomain>
Message-ID: <Pine.LNX.4.10.9910111216290.655-100000@sculpcave.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: cb637b370cbbc5e5311e05a2f5cbbd47

On Sun, 10 Oct 1999, David Olofson wrote:

>> will be difficult. This is why I think it's important to get other
>> linux-audio projects involved.
> Still, I think getting some kind of alpha spec together and hacking
> some prototype implementations ASAP is a *very* good idea, as that's
> an efficient way of finding logical errors and practical

Yes, definitely. We (or should I say you and Paul :)) have taken
big steps forward during the last few days. At least I'm starting 
to understand what you're aiming at. 

One thing I've noticed about myself is that I'm more of a top-down
designer. When you talk about the low-level details, it's been 
hard for me to see where do these things fit in the big picture. I 
usually design my software starting from top-level concepts. Anyway, 
I've had a _lot_ of fun reading linux-audio-dev recently and that's
always a good sign! :)

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav


From - Tue Oct 12 01:08:07 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA04503
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 06:32:28 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA26731 for linux-audio-dev-list; Mon, 11 Oct 1999 06:04:58 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA26728 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 06:04:53 -0400
Received: from localhost.localdomain (d212-151-59-179.swipnet.se [212.151.59.179]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id MAA06830; 
          Mon, 11 Oct 1999 12:00:03 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] MCS: 64 bit timestamps?
Date: Mon, 11 Oct 1999 11:33:19 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910110404.AAA17257@renoir.op.net>
In-Reply-To: <199910110404.AAA17257@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101112065600.00454@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id MAA06830
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id GAA04503
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c9fdbd435111a288f77af4315ee9b58e

On Mon, 11 Oct 1999, Paul Barton-Davis wrote:

[...code...]

> this doesn't take sample clock drift into account. the engine would
> have to deal with this by adjusting the
> cycle_counter_at_start_of_control_loop value at appropriate intervals
> to shift everyone's idea of the current time.

(I don't think fiddling with the TSC timestamps is a good thing, as it
makes the engine code a bit unclear...)

The engine's cycle time should be locked to a master time base -
usually the "master" audio card - and everything else should adapt to
that. (Slave audio cards will need sample skip/insert or something
similar in the interface thread/plug-in/<whatever>.)

That is, some other thread wanting a timestamp need only worry about
the *master* time base - the one that's determined by the current
sample count of the engine's timing master.

Change all timestamps *outside* plug-ins to absolute time (as I
suggested somewhere...), and:

	current_cycle_counter = read_tsc ();
	cycle_diff = current_cycle_counter -
-		cycle_counter_at_start_of_control_loop;
+		cycle_counter_at_last_sync_point;
	now = (msc_time_t) (samples_per_cycle * (float) cycle_diff));
+	now += sample_count_at_last_sync_point;

"sample_count_at_last_sync_point" is any (preferably recent, to
minimize the effect of TSC/audio card drift) pair of sample count
(of the timing master audio card) and TSC when the sample count was
grabbed.

NOTE: As the code looks right now, it needs a lock! Pointer to struct?


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Oct 12 01:08:17 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id IAA16188
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 08:55:50 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA26928 for linux-audio-dev-list; Mon, 11 Oct 1999 08:30:39 -0400
Received: from sculpcave (cvx-2-34.dyn.nic.fi [62.236.99.34]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA26922 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 08:30:29 -0400
Received: from localhost (localhost [127.0.0.1])
	by sculpcave (Postfix) with ESMTP
	id 2D20534D3C; Mon, 11 Oct 1999 12:54:38 +0300 (EEST)
Date: Mon, 11 Oct 1999 12:54:38 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
X-Sender: root@sculpcave.localdomain
To: David Olofson <audiality@swipnet.se>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway
In-Reply-To: <99101020023904.00456@localhost.localdomain>
Message-ID: <Pine.LNX.4.10.9910111226480.655-100000@sculpcave.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 60a82a69c6ed37da7e1cdfdb453ee5a8

On Sun, 10 Oct 1999, David Olofson wrote:

[inputs -> chains -> outputs -concept]
> But I have yet to see a sensible GUI representation of it... Modular
> synth style GUIs get messy too quickly, and a Bars'n'pipes "routing
> matrix" would become huge... Some combination?

Well, this is a real problem. I personally don't like coding user 
interfaces, and especially, GUIs. This is why I chose a simple
listview based model for qtecasound... 

The top level window/list contains chainsetups. You can think of these 
as "sessions". You could for instance have chainsetups for "mixdown",
"recording", "drum submix", etc... When you open a chainsetup, 
you get a new window with "input/output" and "chain" lists. And this
goes on. By opening a chain you get a list of chain operators and
controllers, etc ... As a design-tail, there are no menubars or 
other "hidden" functions. Everything is visible (buttons) and can be 
done using keyboard short-cuts.

As qtecasound is still missing many important features, I can't yet 
tell whether this approach is really usable. I tested the current
public version of qtecasound on one of my musician friends, and to be 
honest, he just couldn't understand how to use the program. ... oh, 
well, I'll have to make some changes and try again.

> P2 and P3 popped up:
> .---.   .---------------------------------.   .----.
> |IN1|-->| P1 | P2      | P3          | P4 |-->|OUT1|
> `---'   `----| | | | | | ----L------ |----'   `----'
>              | | O | O | -------H--- |          ^
>              | O | | | | --Q-- ---G- |          |
>              | | | O | |             |          |
>              `---------| X BPF O NTCH|          |
>                        | O LPF O PEAK|          |
>                        `-------------'          |

This might work (although I'm too lazy to code these modern 
UIs with pixmaps, icons and all ;)). One problem might be how 
to add controllers (oscillators, MIDI-controllers) to the interface.

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav

From - Tue Oct 12 01:08:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id IAA16354
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 08:57:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA26924 for linux-audio-dev-list; Mon, 11 Oct 1999 08:30:32 -0400
Received: from sculpcave (cvx-2-34.dyn.nic.fi [62.236.99.34]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA26914 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 08:30:18 -0400
Received: from localhost (localhost [127.0.0.1])
	by sculpcave (Postfix) with ESMTP
	id 5861D34D3D; Mon, 11 Oct 1999 13:44:47 +0300 (EEST)
Date: Mon, 11 Oct 1999 13:44:47 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
X-Sender: root@sculpcave.localdomain
To: Paul Barton-Davis <pbd@Op.Net>
Cc: David Olofson <audiality@swipnet.se>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] plugin questions 
In-Reply-To: <199910102127.RAA24986@renoir.op.net>
Message-ID: <Pine.LNX.4.10.9910111257250.655-100000@sculpcave.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: af739e5c93e355a1eeb21356623f9c6b

On Sun, 10 Oct 1999, Paul Barton-Davis wrote:

>>What I want is the ability to build a standard GUI using the
>>information the plug-in provides, if we for some reason don't want to
> ah! you didn't say this *at all*. that makes all the difference in the
> world. my entire thinking has been that plugins are responsible for
> their own GUI. a note, however, if we do end up going down this

Well, I couldn't have asked for a better quote. ;) This has been
bothering me all along and have been just waiting for the right 
moment. As we are talking about open-source plugins, plugins don't 
have to "look like" plugins...:

[example 1]
- I might replace my custom filters with plugin filters and 
  just hide all plugin-related stuff from users -> from their point 
  of view everything looks the same: the actual effect, user interface,
  controllable parameters, etc ...
- with commercial plugins this is impossible (well, of course if you 
  buy a licence to use the plugin, but that's a different thing)
- to do this, I'd need to be able to build a generic GUI around 
  plugins

And also...:

[example 2]
- my library provides services for other apps
- people should be able to register new plugins and still
  be able to use the same interface for effect processing

And the normal win/mac case:

[example 3]
- we have a audio app that supports plugins
- if plugin has a custom-UI, use it, otherwise use 
  a generic-UI 

> as for the "all floats" idea. this can work - its what quasimodo does
> for example - but there is a problem if a plugin needs string
> values (say, for a soundfile name). i did a strange and somewhat

At some point we were talking about init-parameters and 
processing-parameters (I don't remember the exact terms). 
We could decide to accept string parameters only when initializing 
plugins. If you need to change a string value, you'd just 
reinitialize.

> fierce arguments on the Csound mailing list about the preferability of
> double over float ...

Hmm, why don't we just use a typedef that is required to be 
a floating-point type. 32bit machines can use floats while 
64bit machines (and precision-freaks) can use doubles or even 
long doubles...? 

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav

From - Tue Oct 12 01:08:16 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id IAA16163
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 08:55:36 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA26923 for linux-audio-dev-list; Mon, 11 Oct 1999 08:30:32 -0400
Received: from sculpcave (cvx-2-34.dyn.nic.fi [62.236.99.34]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA26913 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 08:30:18 -0400
Received: from localhost (localhost [127.0.0.1])
	by sculpcave (Postfix) with ESMTP
	id B9A3634D3E; Mon, 11 Oct 1999 14:29:41 +0300 (EEST)
Date: Mon, 11 Oct 1999 14:29:41 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
X-Sender: root@sculpcave.localdomain
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway 
In-Reply-To: <199910101710.NAA11781@renoir.op.net>
Message-ID: <Pine.LNX.4.10.9910111346140.655-100000@sculpcave.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: a242b0ec210442d6cb861ec74fe463f7

On Sun, 10 Oct 1999, Paul Barton-Davis wrote:

[inputs -> chains -> outputs -concept]
> how will you ever handle a stereo mixer strip ? it has one input, and
> gets routed to two outputs. for surround sound, you take one input,
> and output it to some variable number of outputs.

Well, this caused me a lot of headache. Finally I decided to include 
channel count into my idea of "audio signal". So in practice  
all signals are stereo in ecasound. Technically, stereo signal 
is a combination of two mono signals, but in practice these signals 
are clearly related and should be represented as a whole. 

I've made it easy to add more channels, but I don't think I need to
do this anytime soon. A lot of people talk about surround and
multichannel sound, but when I look around my home studio, all my
equipment is designed to work with stereo signals (mixers, effect
processors, synths, drum machines, etc). Of course, you still have to 
deal with mono signals, but you can easily represent them as
stereo-signals. I don't want to sound like B.Gates talking about
640kB, but I neither want to add complexity without a good reason.

I know this approach has its problems, but it also simplifies 
a lot of things. As for surround sound, I can always route my 
input signals to multiple chains and use panning/channel_amplify 
to mute individual channels ...

> hdr has low level input devices, output devices, and four higher-level
> abstractions called sources, destinations, strips and buses.
[...]
> the engine does this:
[...]
> this system allows a strip to be connected to a single input, but any
> number of buses, and thus any number of outputs, permitting surround
> sound as well as other interesting stuff.

Hmm, it looks like our designs are actually quite similar. Ecasound's 
inputs do much the same as your input_device-source-strip abstraction 
and ecasound's chains are just like your buses (hmm, where do you put 
additional effect processing... buses or strips?). Your design is
obviously more complex and thus more flexible. It remains to see, 
whether ecasound's design is flexible enough.

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav

From - Tue Oct 12 01:08:21 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA25239
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 10:02:38 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA27173 for linux-audio-dev-list; Mon, 11 Oct 1999 09:35:04 -0400
Received: from alsa.alsa-project.org (alsa.jcu.cz [160.217.1.49]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA27170 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 09:34:58 -0400
Received: from localhost (andy@localhost)
	by alsa.alsa-project.org (8.8.8/8.8.8) with ESMTP id PAA19338;
	Mon, 11 Oct 1999 15:29:57 +0200
Date: Mon, 11 Oct 1999 15:29:57 +0200 (MEST)
From: Andy Lo A Foe <andy@alsa-project.org>
To: Kai Vehmanen <kaiv@wakkanet.fi>
cc: Linux Audio Dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] plugin questions 
In-Reply-To: <Pine.LNX.4.10.9910111257250.655-100000@sculpcave.localdomain>
Message-ID: <Pine.LNX.4.05.9910111507280.18301-100000@alsa.alsa-project.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 9999fb65e7867403c5bfd02e556c547f

On Mon, 11 Oct 1999, Kai Vehmanen wrote:

> > world. my entire thinking has been that plugins are responsible for
> > their own GUI. a note, however, if we do end up going down this
> 
> Well, I couldn't have asked for a better quote. ;) This has been
> bothering me all along and have been just waiting for the right 
> moment. As we are talking about open-source plugins, plugins don't 
> have to "look like" plugins...:
 
We are at point in AlsaPlayer development where parameters for the various
plugins (input, output, scopes) need to be created/preserved :-)
One of the ideas that have been floating around the mailing is to let the
plugins return a LIST of parameters they have. A parameter can be for
example a string, float, int, color, etc. A parameter should also have
optional constraints tied to it (int, floats can have ranges). This will
allow the application to build its own User Interface -> flexiblity.
(I realize of course that not every plugin will be able to communicate its
parameters easily this way, room should be left for plugin specfic widgets
for example)

What do you think?

> Hmm, why don't we just use a typedef that is required to be 
> a floating-point type. 32bit machines can use floats while 
> 64bit machines (and precision-freaks) can use doubles or even 
> long doubles...? 

Is it that simple? Changing the type might also change the min/max values,
or require another algorithm for better accuracy!?

Andy
--
AlsaPlayer, http://www.alsa-project.org/~andy/

From - Tue Oct 12 01:08:22 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA27939
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 10:20:04 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA27197 for linux-audio-dev-list; Mon, 11 Oct 1999 09:50:33 -0400
Received: from ccrma.stanford.edu (ccrma.Stanford.EDU [36.49.0.84]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA27194 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 09:50:31 -0400
Received: from cmn14.stanford.edu (cmn14.stanford.edu [36.49.0.93])
	by ccrma.stanford.edu (8.9.3/8.9.3) with ESMTP id GAA25264;
	Mon, 11 Oct 1999 06:45:48 -0700 (PDT)
Received: (from bil@localhost)
	by cmn14.stanford.edu (8.9.3/8.9.3) id GAA19021;
	Mon, 11 Oct 1999 06:45:46 -0700 (PDT)
Message-Id: <199910111345.GAA19021@cmn14.stanford.edu>
Content-Type: text/plain
MIME-Version: 1.0 (NeXT Mail 3.3 v148.2.1)
In-Reply-To: <199910092310.TAA01929@renoir.op.net>
X-Nextstep-Mailer: Mail 3.3 [m68k] (Enhance 2.2p2)
Received: by NeXT.Mailer (1.148.2.1)
From: Bill Schottstaedt <bil@ccrma.Stanford.EDU>
Date: Mon, 11 Oct 1999 06:45:45 -0700
To: Paul Barton-Davis <pbd@Op.Net>
Subject: Re: [linux-audio-dev] Re: timing issues in a client/server enviroment
cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <199910092310.TAA01929@renoir.op.net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1bb6301456d5359dfe8ef1e4960f15f6

>>(see for example Seer Reality monopolizes the DirectX PCM audio,
>>that means if you want to play your mp3 on your 2nd soundcard, you can't)
>
> part of that problem is just braindead design. Seer are not alone in
> this - even [...] Bill Schottstaedt wrote his sndlib() code to
> open /dev/dsp when the library initializes, even though it will likely
> not use it!

I think something is confused here; when sndlib initializes, it
tries to figure out what dsps and mixers are available, and how
they are related.  This is necessary in the multi-card case because
OSS does not provide that information, but it's needed if you
want to use all available soundcards. sndlib opens /dev/dsp only as
a last resort, but releases it and all the others right away --
it's building a map of mixer->dsp choices, and once that's done,
no device is held by the library.

From - Tue Oct 12 01:09:17 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA20532
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 20:33:58 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA28602 for linux-audio-dev-list; Mon, 11 Oct 1999 18:10:31 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA28599 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 18:10:28 -0400
Received: from linuxhost.localdomain (IDENT:root@ppp24-ul.dnet.it [194.242.205.24])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id AAA15432;
	Tue, 12 Oct 1999 00:05:14 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id RAA00891;
	Mon, 11 Oct 1999 17:49:34 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] full-duplex
Date: Mon, 11 Oct 1999 17:45:29 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: linux-sound@vger.rutgers.edu
References: <199910110508.BAA20057@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101117493300.00801@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 392c8560c3b4e5d93b87c949ee0db84b

On Mon, 11 Oct 1999, Paul Barton-Davis wrote:
> >ALSA:
> >Won't compile with gcc-2.95 but it's probably similar to OSS/Free.
> 
> ALSA:
> 1) open the device O_RDWR. then use it the way you'd expect,
>    independent of the card type or anything else.
> 
> OSS/Free or OSS/Commercial:
> 1) forget about it for full-duplex. its just not reliable and/or too
> card dependent.
> 
> --p

Hi,
Paul gave me a code fragment to use the soundcard in fullduplex mode,
(My old code were not able to perform DSP_SET_FRAGMENT, because
of wrong order of soundcard initialization).

But my Turtlebeach on my P133 with Tyan Tomcat motherboard (HX)
locks up the kernel some times.
( I tried 2.2.5 and 2.2.10 )

Is this due to a hw problem of buggy mainboards (from the Audio-quality HOWTO
:-) )  ?

Is there a workaround for OSS/Free ?
Does have ALSA the same problems ?

thanks for infos.

regards,
Benno.

From - Tue Oct 12 01:08:28 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA19646
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 12:58:13 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA27565 for linux-audio-dev-list; Mon, 11 Oct 1999 12:29:48 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id MAA27562 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 12:29:46 -0400
From: est@hyperreal.org
Received: (qmail 18425 invoked by uid 162); 11 Oct 1999 16:25:25 -0000
Message-ID: <19991011162525.18424.qmail@hyperreal.org>
Subject: [linux-audio-dev] aRts in Linux Today KDE Developers Conference Report
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Mon, 11 Oct 1999 09:25:25 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 293bc31a466cfc7f23a4f7a1d7de62e6

Check out this interesting report at
http://linuxtoday.com/stories/10975.html.

Here's what it had to say about aRts:

aRts

   Stefan Westerfeld demonstrated aRts -- his next generation network
   multimedia framework. aRts uses a very modular system of CORBA
   components to achieve nearly limitless potential for multimedia
   playing and manipulation. KDE 2.0 will use an optimized subset of aRts
   to handle all audio playing. Future releases of KDE will then use the
   more advanced video and audio/video manipulation abilities available
   in aRts. The aRts server is incredible. It's synthesis and filtering
   abilities are leagues ahead of anything yet found on Unix. It will
   offer capabilities to KDE that have so far been found only on OSes
   like Windows, BeOS, etc.

From - Tue Oct 12 01:08:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA18669
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 12:50:58 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA27551 for linux-audio-dev-list; Mon, 11 Oct 1999 12:24:17 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA27548 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 12:24:15 -0400
Received: from someip.ppp.op.net (d-bm3-01.ppp.op.net [209.152.194.65]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id MAA01854; Mon, 11 Oct 1999 12:19:23 -0400 (EDT)
Message-Id: <199910111619.MAA01854@renoir.op.net>
To: Bill Schottstaedt <bil@ccrma.Stanford.EDU>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: timing issues in a client/server enviroment 
In-reply-to: Your message of "Mon, 11 Oct 1999 06:45:45 PDT."
             <199910111345.GAA19021@cmn14.stanford.edu> 
Date: Mon, 11 Oct 1999 13:14:57 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 102da6ba191b8b0bc3ee3d5cfdb3517c

>I think something is confused here; when sndlib initializes, it
>tries to figure out what dsps and mixers are available, and how

understood. but if you're calling this:

	if ((fd = open_sound_input ((char *) file)) < 0) {

and `file' is not /dev/*, then having sndlib_init() requiring access
to /dev/dsp and its friends is a little excessive. it can lead to
situations where a function call like open_sound_input() will fail due
to lack of access to a resource that is not needed, and hasn't been
requested. i've bumped into this at least once ... i think.

but, hey .. this is open source software, and if i cared enough, i'd
fix it!

--p

From - Tue Oct 12 01:08:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA25287
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 13:40:42 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA27674 for linux-audio-dev-list; Mon, 11 Oct 1999 13:21:27 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA27671 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 13:21:24 -0400
Received: from someip.ppp.op.net (d-bm3-01.ppp.op.net [209.152.194.65]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id NAA07882; Mon, 11 Oct 1999 13:16:31 -0400 (EDT)
Message-Id: <199910111716.NAA07882@renoir.op.net>
To: est@hyperreal.org
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] aRts, KDE - say it ain't so!
In-reply-to: Your message of "Mon, 11 Oct 1999 09:25:25 PDT."
             <19991011162525.18424.qmail@hyperreal.org> 
Date: Mon, 11 Oct 1999 13:16:05 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2a6a3ed66c00f58a6893857d6e297d41

>   abilities are leagues ahead of anything yet found on Unix. It will
>   offer capabilities to KDE that have so far been found only on OSes
>   like Windows, BeOS, etc.

yes, aRts is great but .... sigh - "offer capabilities to KDE" 

Windows, for all its faults, is an OS. BeOS is an OS. KDE is not an
OS! what is anyone doing "offering capabilities" to the bloody desktop
architecture. this is *insane*.

the work that Stefan has done on aRts is wonderful, but this idea of
there being a desktop, rather than an OS, that offers these
capabilities is a dangerous path, and it fractures our community. I am
not going to run KDE or GNOME for the foreseeable future, and anyone
who thinks that the way forward is to build functions into either of
these systems that are not part of the kernel or a standalone program
is not my friend.

--p

From - Tue Oct 12 01:08:27 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA19583
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 12:57:48 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA27578 for linux-audio-dev-list; Mon, 11 Oct 1999 12:30:32 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA27574 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 12:30:30 -0400
Received: from someip.ppp.op.net (d-bm3-01.ppp.op.net [209.152.194.65]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id MAA02454 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 12:25:47 -0400 (EDT)
Message-Id: <199910111625.MAA02454@renoir.op.net>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] sndlib remarks
In-reply-to: Your message of "Mon, 11 Oct 1999 06:45:45 PDT."
             <199910111345.GAA19021@cmn14.stanford.edu> 
Date: Mon, 11 Oct 1999 13:21:20 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7a6110e0fb85e9294bf505ea7cad95f2

i just want to follow up on my comments about sndlib, which sounded
somewhat depracating. 

sndlib is great! sndlib's author realized that the difference between
file formats can be split in two: the header type, and the data
type. instead of having a bunch of code to handle RIFF files, and
another to handle AIFF, Bill wrote stuff to read RIFF headers and AIFF
headers, and then "added" stuff to read little endian 16 bit samples
and big endian 16 bit samples, for example. thus, an AIFF file with
the data stored a LE16 samples can be handled easily, as can an AIFF
file with float32 samples, etc. This is easy because the header and
data formats have been separated from one another.

this is an excellent design - as far as I understand it, neither the
SGI or Michael Pruett implementations of libaudiofile do this, and I
don't know of any other similar libraries that take this approach
either. i use sndlib a lot, though often via my C++-ified version
which uses templates to optimize data conversion.

--p

From - Tue Oct 12 01:08:31 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA21477
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 13:13:09 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA27598 for linux-audio-dev-list; Mon, 11 Oct 1999 12:50:49 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA27595 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 12:50:47 -0400
Received: from someip.ppp.op.net (d-bm3-01.ppp.op.net [209.152.194.65]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id MAA04412; Mon, 11 Oct 1999 12:45:56 -0400 (EDT)
Message-Id: <199910111645.MAA04412@renoir.op.net>
To: Kai Vehmanen <kaiv@wakkanet.fi>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway 
In-reply-to: Your message of "Mon, 11 Oct 1999 14:29:41 +0300."
             <Pine.LNX.4.10.9910111346140.655-100000@sculpcave.localdomain> 
Date: Mon, 11 Oct 1999 13:41:29 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: da4237815a1ae051ea2bc5bf881e0b0f

>I've made it easy to add more channels, but I don't think I need to
>do this anytime soon. A lot of people talk about surround and
>multichannel sound, but when I look around my home studio, all my
>equipment is designed to work with stereo signals (mixers, effect
>processors, synths, drum machines, etc). 

actually, in my studio, i don't have this perspective. my mixer, for
example, can clearly handle mono signals quite well, and i use it for
quite a few: the mono inputs sources: mic, prophet-5, matrix-6
synth. 

because i had a breakout card built for my soundcards, i don't even
think of them as stereo devices anymore, but as each having two mono
input channels - i have 1/4" jacks on a 1U panel in the front of the
rack that allow me to plug something into, say, channel "1" (right) of
my Trident soundcard, and something else into channel "0"
(left). their outputs go back to separate mixer strips as well.

i spent some time talking with people who use mixers a lot, and asked
them how helpful it was to be able to use a stereo input signal on a
single strip. the verdict: as long as you can group (sync) the faders
for two strips, they didn't care, even when i pointed out that it
consumed an entire extra strip this way. ah, diehards :)

i think it depends in part on what your inputs are. if they really are
stereo signals (stereo soundfiles, devices etc.), then having audio
default to stereo is a good choice. if they are mostly mono (mono
soundfiles, devices, mics, etc), which is often true in live
recording, then it can be a bad choice, computationally.

i noticed that neundo allows both. i'm still thinking about this.

>Hmm, it looks like our designs are actually quite similar. Ecasound's 
>inputs do much the same as your input_device-source-strip abstraction 
>and ecasound's chains are just like your buses (hmm, where do you put 
>additional effect processing... buses or strips?). 

like an expensive hardware mixer: both.

this allows you to do semi-global FX and EQ on several different
inputs at the same time (e.g. add the same delay to 4 different
strips). doing this at the bus level is much more computationally
efficient than doing it 4 times (once per strip). on the other hand,
sometimes, you want an effect to just be applied to a single input,
and then you'd do it on the strip:

			                   
			           +-->    BUS2 ->  FX3 -> FX4 -> OUT1
                                   |                            
    IN1  -> STRIP1  -> FX1 -> PAN -+
    			           |
			           |
			           +-->  
			                   BUS2 ->  FX5 -> FX6 -> OUT2
			           +-->  
                                   |
                                   |
    IN2  -> STRIP2  -> FX2 -> PAN -+
	                           |
			           +-->    BUS3 ->  FX7 -> FX8 -> OUT3
			               
                              
i'm still working on optimizing the amount of data copying that goes
on in a net like the one above, but it all works just fine for
now. MIDI controllable control elements too :)    

--p

From - Tue Oct 12 01:08:34 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA22916
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 13:23:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA27622 for linux-audio-dev-list; Mon, 11 Oct 1999 13:00:12 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA27619 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 13:00:10 -0400
Received: from someip.ppp.op.net (d-bm3-01.ppp.op.net [209.152.194.65]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id MAA05346; Mon, 11 Oct 1999 12:55:17 -0400 (EDT)
Message-Id: <199910111655.MAA05346@renoir.op.net>
To: David Olofson <audiality@swipnet.se>
cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] MCS: 64 bit timestamps? 
In-reply-to: Your message of "Mon, 11 Oct 1999 11:33:19 +0200."
             <99101112065600.00454@localhost.localdomain> 
Date: Mon, 11 Oct 1999 13:50:50 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: eebc52fb06dd66754c933d4b82bc9cc5

>> this doesn't take sample clock drift into account. the engine would
>> have to deal with this by adjusting the
>> cycle_counter_at_start_of_control_loop value at appropriate intervals
>> to shift everyone's idea of the current time.
>
>(I don't think fiddling with the TSC timestamps is a good thing, as it
>makes the engine code a bit unclear...)

eh ? is this because there are going to be no function calls in the
engine or something extreme like that ?

>The engine's cycle time should be locked to a master time base -
>usually the "master" audio card - and everything else should adapt to
>that. (Slave audio cards will need sample skip/insert or something
>similar in the interface thread/plug-in/<whatever>.)
>
>That is, some other thread wanting a timestamp need only worry about
>the *master* time base - the one that's determined by the current
>sample count of the engine's timing master.
>
>Change all timestamps *outside* plug-ins to absolute time (as I
>suggested somewhere...), and:
>
>	current_cycle_counter = read_tsc ();
>	cycle_diff = current_cycle_counter -
>-		cycle_counter_at_start_of_control_loop;
>+		cycle_counter_at_last_sync_point;

		             what is the difference here, other than
		             the name ?

>	now = (msc_time_t) (samples_per_cycle * (float) cycle_diff));
>+	now += sample_count_at_last_sync_point;

heh. this is what i wrote on my first attempt, and then i said to
myself (quoting you):

>NOTE: As the code looks right now, it needs a lock! Pointer to struct?

so i tried to ensure that it didn't need a lock, thus my avoidance of
the use of two engine-stamped values.

if you believe that TSC/audio card drift will be minimal, then you
don't need to worry.

if you do need to worry about it, adjusting the cycle_counter value
from the engine is pretty simple, as you yourself pointed out a week
or so ago. if the engine notices:

        TSC       sample count
	---       ------------
 	nnn       yyy

but expected:

        nnn       xxx

it just adds to the cycle_counter_at_last_sync_point (or whatever):

   ... set cycle_counter_at_last_sync_point in the normal way ...
   cycle_counter_at_last_sync_point += (xxx - yyy) * cycles_per_sample.

and we're done. whats so unclear ?


From - Tue Oct 12 01:08:36 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA30885
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 14:19:39 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA27833 for linux-audio-dev-list; Mon, 11 Oct 1999 13:59:14 -0400
Received: from flophouse.localnet (grib.customer.jump.net [216.30.103.2]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA27830 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 13:59:12 -0400
Received: by flophouse.localnet (Postfix, from userid 1000)
	id 4045C8E3D; Mon, 11 Oct 1999 12:54:29 -0500 (CDT)
To: Paul Barton-Davis <pbd@Op.Net>
Cc: est@hyperreal.org, linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] aRts, KDE - say it ain't so!
References: <199910111716.NAA07882@renoir.op.net>
From: Bill Gribble <grib@cs.utexas.edu>
Date: 11 Oct 1999 12:54:29 -0500
In-Reply-To: Paul Barton-Davis's message of "Mon, 11 Oct 1999 13:16:05 -0400"
Message-ID: <87g0zh236y.fsf@flophouse.localnet>
Lines: 29
User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3378a004b67eb80d2f0d059557271a03

Paul Barton-Davis <pbd@Op.Net> writes:
> the work that Stefan has done on aRts is wonderful, but this idea of
> there being a desktop, rather than an OS, that offers these
> capabilities is a dangerous path, and it fractures our community. I am
> not going to run KDE or GNOME for the foreseeable future, and anyone
> who thinks that the way forward is to build functions into either of
> these systems that are not part of the kernel or a standalone program
> is not my friend.

GNOME isn't a desktop at all, and your hatred/fear of it is
reactionary (I know you mentioned KDE too but I've never used it so I
can't stick up for it).  It's a set of tools allowing applications to
communicate with each other, that's all. 

I think it's a phenomenally useful evolution of the Unix graphical
environment to have a framework like GNOME for interapplication
communication.  It works, it's getting better all the time, and it
*doesn't* tie one to a specific desktop.  "Fragmenting the community"
is a natural consequence of a distributed development model. It's not
necessarily a bad thing, especially when it promotes cross-pollination
of ideas between different groups.  Having a handful of incompatible
solutions to the same problem just isn't a big deal if it leads to a
better overall solution.

GNOME is a good thing, in my book.  

Bill Gribble


From - Tue Oct 12 01:08:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA00964
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 14:39:01 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA27881 for linux-audio-dev-list; Mon, 11 Oct 1999 14:20:25 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA27878 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 14:20:23 -0400
Received: from someip.ppp.op.net (d-bm3-01.ppp.op.net [209.152.194.65]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id OAA14082 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 14:15:40 -0400 (EDT)
Message-Id: <199910111815.OAA14082@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] aRts, KDE - say it ain't so! 
In-reply-to: Your message of "11 Oct 1999 12:54:29 CDT."
             <87g0zh236y.fsf@flophouse.localnet> 
Date: Mon, 11 Oct 1999 14:15:14 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e2b171fdb8580134c6148f76bbbe1acd

>GNOME isn't a desktop at all, and your hatred/fear of it is

I don't hate it. I don't fear it. 

>I think it's a phenomenally useful evolution of the Unix graphical
>environment 

no question of that.

But audio has no inherent connection to the Unix graphical environment.

I don't want phenomenally useful tools ending up as part of that
*graphical* environment when they should be part of *the {Li,U}nix
environment* instead.

>it *doesn't* tie one to a specific desktop.

but it does tie one to a desktop.

>GNOME is a good thing, in my book.  

in mine too. i just don't see that it has any place defining audio
standards that might have a role in non-graphical programs.

--p

From - Tue Oct 12 01:08:40 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA03510
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 14:57:10 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA27907 for linux-audio-dev-list; Mon, 11 Oct 1999 14:33:59 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA27904 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 14:33:57 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id OAA21521
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 14:27:33 -0400 (EDT)
Received: from localhost by ux02 (8.9.1b+Sun) id OAA16769; Mon, 11 Oct 1999 14:27:34 -0400 (EDT)
Date: Mon, 11 Oct 1999 14:27:34 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: "albods"
In-Reply-To: <199910082337.TAA25354@renoir.op.net>
Message-ID: <Pine.GSO.4.10.9910111423410.16696-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 0427d0f4118e92cedf07dac7ebee9da1

On Fri, 8 Oct 1999, Paul Barton-Davis wrote:

> >There was talk of supporting this on linux-fsdevel.  They were going to
> >make it so you can read() and write() a directory, like a normal file.
> >Ted T'so called them "albods", from memory.
> >I don't know what came of this.
> 
> over on linux-kernel, many people hate albods. the hate was so
> profound that my reading of the debate was that they would die before
> even being born.

1.  I'm sure there's a neat story behind such an unusual name as "albod".
Is it the name of the guy who invented them?

2.  Why would the use of albods be a kernel issue?  The whole point is
that they're normal directories.  You just name them differently so that
file managers and other MIME mappers can recognise them.  Or are we 
talking about different things?

Div.

From - Tue Oct 12 01:08:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA04124
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 15:01:14 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA27924 for linux-audio-dev-list; Mon, 11 Oct 1999 14:42:02 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA27921 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 14:42:00 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id OAA23035
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 14:35:56 -0400 (EDT)
Received: from localhost by ux02 (8.9.1b+Sun) id OAA16962; Mon, 11 Oct 1999 14:35:54 -0400 (EDT)
Date: Mon, 11 Oct 1999 14:35:54 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc.
In-Reply-To: <199910082352.TAA26300@renoir.op.net>
Message-ID: <Pine.GSO.4.10.9910111428460.16696-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: fbb716a6324ae278ab70c09c7844821a

On Fri, 8 Oct 1999, Paul Barton-Davis wrote:

> First, any program that only does I/O to /dev/midi should be shot at
> dawn. If it uses a user-selectable one of /dev/midiNN, it can live. 

Why not just let the user type in a damn filename (fifoname)?  It's
actually _easier_ to code, after all.  You can always make it default to
the common case.
 
> (clever workaround appreciated, but deleted here)

> Alas, FIFO's don't work exactly like files, devices or sockets. If you
> do the open...read and open...write sequences in the wrong order
> and/or without the correct logic, you will get errors instead of
> blocking. 

I ran into this problem with my FIFO-based MIDI toys.  The trick I
discovered was to put the open calls in a busy loop, using nonblocking
mode.  Once both ends are connected, you can fctl them back into blocking
mode.  Too bad there's no equivalent of select for open.

> Also, the beauty of this kind of scheme is one of the things I have
> against the ALSA lib API for raw MIDI devices. Anything that tries to
> obscure or complicate the fact that a MIDI "port" is just a byte sink
> and source is evil :) Thats why I never use the ALSA lib API for MIDI,
> but just stick to regular Unix open/close/read/write on /dev/snd/midiCxxDyy

Agreed.  Majorly.  I don't mind wrapping a nice API around the device as
long as I always have the option of writing to it raw.  Can't really
complain about ALSA though, since it supports both.  

On a related note, why aren't the advanced features of sound cards (in
particular, patch dumping) performed through sysex commands rather than
ioctls?  It seems a natural to me to keep everything inband.

Div.

From - Tue Oct 12 01:08:43 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA05632
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 15:10:40 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA27957 for linux-audio-dev-list; Mon, 11 Oct 1999 14:49:56 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA27954 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 14:49:54 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id OAA24539
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 14:43:48 -0400 (EDT)
Received: from localhost by ux02 (8.9.1b+Sun) id OAA17071; Mon, 11 Oct 1999 14:43:49 -0400 (EDT)
Date: Mon, 11 Oct 1999 14:43:49 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] non-destructive editing
In-Reply-To: <0003566e187af433_mailit@relay.eunet.be>
Message-ID: <Pine.GSO.4.10.9910111439270.16696-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e0a3956ac4f3105ec3394415c7459bda


> Furthermore, I would like to be able to MOVE parts of one sound to another, 
> possibly on another track,
> which makes the non-destructive stuff complex (I certainly don't wanna 
> duplicate data until necessary).

If you're attracted to the fixed-size blocks in a single file model, you
can make it work like a miniature filesystem within the file.  Keep a list
of "i-nodes" (chunk pointers) in which only the list has to be changed to
reorder or delete chunks.  You can even store the list in a progressive
manner such that it represents the history.  Upon "commit", you
essentially defragment the file.  I once worked on a database that worked
this way.

Not that I recommend this method, but it could potentially work for you.
(Yes there is the issue of edit operations that cross chunk boundaries
which complicates things quite a bit... left as an excercise to the
reader.  :-)


Div.

From - Tue Oct 12 01:08:47 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA08252
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 15:30:14 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA27968 for linux-audio-dev-list; Mon, 11 Oct 1999 14:56:19 -0400
Received: from alsa.alsa-project.org (alsa.jcu.cz [160.217.1.49]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA27965 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 14:56:16 -0400
Received: from localhost (andy@localhost)
	by alsa.alsa-project.org (8.8.8/8.8.8) with ESMTP id UAA24650;
	Mon, 11 Oct 1999 20:51:23 +0200
Date: Mon, 11 Oct 1999 20:51:22 +0200 (MEST)
From: Andy Lo A Foe <andy@alsa-project.org>
To: Paul Barton-Davis <pbd@Op.Net>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] aRts, KDE - say it ain't so! 
In-Reply-To: <199910111815.OAA14082@renoir.op.net>
Message-ID: <Pine.LNX.4.05.9910112050400.19958-100000@alsa.alsa-project.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e668ad1d8880fa3a1950e575df5a7591

On Mon, 11 Oct 1999, Paul Barton-Davis wrote:

> I don't want phenomenally useful tools ending up as part of that
> *graphical* environment when they should be part of *the {Li,U}nix
> environment* instead.

Amen...

BTW, are my mails getting through on the mailing list? I haven't gotten
anything I posted back. Sorry for the wasted bandwidth :)

Regs,

Andy

From - Tue Oct 12 01:08:44 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA07154
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 15:23:06 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA28000 for linux-audio-dev-list; Mon, 11 Oct 1999 15:03:32 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA27997 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 15:03:29 -0400
From: est@hyperreal.org
Received: (qmail 22479 invoked by uid 162); 11 Oct 1999 18:59:07 -0000
Message-ID: <19991011185907.22478.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] Re: "albods"
In-Reply-To: <Pine.GSO.4.10.9910111423410.16696-100000@ux02.CS.Princeton.EDU>
 from David Slomin at "Oct 11, 1999 02:27:34 pm"
To: David Slomin <dgslomin@CS.Princeton.EDU>
Date: Mon, 11 Oct 1999 11:59:07 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d61839bbe85fe96a8ceade3be28e5218

David Slomin discourseth:
> On Fri, 8 Oct 1999, Paul Barton-Davis wrote:
> > 
> > over on linux-kernel, many people hate albods. the hate was so
> > profound that my reading of the debate was that they would die before
> > even being born.
> 
> 1.  I'm sure there's a neat story behind such an unusual name as "albod".
> Is it the name of the guy who invented them?

Heh..application-logical-bundle-of-data..either that or something the
aliens whispered. :O

Eric

From - Tue Oct 12 01:08:45 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA07995
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 15:28:29 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA28040 for linux-audio-dev-list; Mon, 11 Oct 1999 15:06:45 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA28037 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 15:06:43 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id PAA26454
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 15:01:00 -0400 (EDT)
Received: from localhost by ux02 (8.9.1b+Sun) id PAA17263; Mon, 11 Oct 1999 15:01:01 -0400 (EDT)
Date: Mon, 11 Oct 1999 15:01:00 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc.
In-Reply-To: <37FF6367.5CD59C54@cygnus.com>
Message-ID: <Pine.GSO.4.10.9910111447330.16696-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 70580abaf90fdd9035f848e95fee1631

On Sat, 9 Oct 1999 thudson@cygnus.com wrote:

> One specific app I had in mind was KeyKit. While it does allow you to
> specify a device file, it expects to be able to read and write from
> this single device.  Unless linux pipes are different from standard
> unix ones, they can only be opened for read or write. It would be 
> nice if apps let you specify a different device file for input and 
> output, but the last time I looked at the KeyKit sources (it's been 
> a while),  it would require some work to do this. 

The "rw" program from my MIDI Toys does the reverse of this... opens a
device "file" in read/write mode, and forwards it to one FIFO in read mode
and another FIFO in write mode, so that the device can be accessed
simultaneously by two unrelated processes.  However, I never ran into a
need for the reverse operation.  Offhand, I can't see a way to do this
without resorting to driver programming (or rewriting KeyKit, but I was
looking for a general solution).
 
> Something similar to this is a pet project for me. Rather than putting
> the intelligence in every app to deal with ALSA details, I would like to
> have an ALSA kernel client w/ a gui app as a controller that would allow
> me to specify the routing between oblivious apps. However, I tend to 
> think of more fine-grained routing than ports. From a users perspective
> it would be nicer to specify:
> 
> External keybord => MidiAppegiator => MidiEcho => Sequencer:Track 1 =>
>  External Synth (responding on channel 5)
> 
> External Drum Pad => KetKit => CSound

Hmm.  If you replace those arrows with vertical lines, it looks a hell of
a lot like my MIDI Toys.  Identical, in fact.  <Grin>  I just use the
shell to set it up rather than a GUI, but it would be pretty trivial to
whip up a graphical frontend.  About 15 minutes in Tcl/Tk, I'd say.
 
> Rather than, let's see, my keyboard is set to channel one and is 
> connected to the first port of my second Midi card. I need to set
> my MidiArpeggiator,MidiEcho, and Sequencer Track one to receive on 
> channel one and output on channel 5 of the third port of my first midi
> card...

The more I think about MIDI, the more I think that channels should never
be used for routing.  They're too important as the means by which to
attach controllers to notes.  I'd like to be able to send a full 16
channels to the same patch, just in order to set the pitch bend separately
for each of the 16 notes in a cacophonous chord.

For routing, virtual (or physical too, I suppose) MIDI ports are a must.
That's why I like using FIFOs for the purpose... [practically] no limit on
the number of them you can have open at a time.

> Yes. In my above scheme, MidiArpegiator and MidiEcho are simple plugin
> applets. I just wonder about debugging such applets if I made them
> alsa kernel clients. However, if I could find a nice abstraction for the 
> building blocks of things like arpegiator and echo, perhaps a limited
> set of primitives could be written and debugged once, and be combined
> in unlimited ways by the user.

Why does everybody like plugins so much?  What's wrong with small,
coorperating, standalone apps?

Div.

From - Tue Oct 12 01:08:48 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA14244
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 16:16:36 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA28161 for linux-audio-dev-list; Mon, 11 Oct 1999 15:51:41 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA28158 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 15:51:38 -0400
Received: from someip.ppp.op.net (d-bm2-05.ppp.op.net [209.152.194.37]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id PAA23453; Mon, 11 Oct 1999 15:46:41 -0400 (EDT)
Message-Id: <199910111946.PAA23453@renoir.op.net>
To: David Slomin <dgslomin@CS.Princeton.EDU>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc. 
In-reply-to: Your message of "Mon, 11 Oct 1999 15:01:00 EDT."
             <Pine.GSO.4.10.9910111447330.16696-100000@ux02.CS.Princeton.EDU> 
Date: Mon, 11 Oct 1999 15:46:16 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5ba3b0a21380d7277e7bea4ea9bee1b1

>The "rw" program from my MIDI Toys does the reverse of this... opens a
>device "file" in read/write mode, and forwards it to one FIFO in read mode
>and another FIFO in write mode, so that the device can be accessed
>simultaneously by two unrelated processes. 

heh. the need for this is purely a result of poor design of the OSS
MIDI drivers. if you use ALSA, for example, you don't need this.

>Why does everybody like plugins so much?  What's wrong with small,
>coorperating, standalone apps?

speed. if you work with audio data, rather than MIDI, the cost of IPC
is often too high if you are doing real-time stuff. i love The Unix
Way(TM), but it was designed for tty-rate data exchange, not the
2MB/sec streaming data that audio does. For "offline" editing
purposes, pipes and stuff seem excellent, but for real-time, it just
doesn't work (well).

--p

From - Tue Oct 12 01:08:49 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA14294
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 16:17:02 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA28191 for linux-audio-dev-list; Mon, 11 Oct 1999 15:57:45 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA28188 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 15:57:43 -0400
Received: from someip.ppp.op.net (d-bm2-05.ppp.op.net [209.152.194.37]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id PAA24119; Mon, 11 Oct 1999 15:52:49 -0400 (EDT)
Message-Id: <199910111952.PAA24119@renoir.op.net>
To: David Slomin <dgslomin@CS.Princeton.EDU>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc. 
In-reply-to: Your message of "Mon, 11 Oct 1999 14:35:54 EDT."
             <Pine.GSO.4.10.9910111428460.16696-100000@ux02.CS.Princeton.EDU> 
Date: Mon, 11 Oct 1999 15:52:25 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 20ebd1501d159b1419e2f7bb98cdc670

>On a related note, why aren't the advanced features of sound cards (in
>particular, patch dumping) performed through sysex commands rather than
>ioctls?  It seems a natural to me to keep everything inband.

speed, partly, but more significantly, it involves creating a sysex
implementation in the device driver. most of the cheap soundcards
don't support actual MIDI data to control them, so the driver has to
parse a MIDI stream and then tweak bits and bytes on the card to get
it to do the right thing. sigh.

but take the example of the nicely designed Turtle Beach Tropez+. This
card has an ICS2115 wavetable synth, which very kindly runs firmware
that allows it to handle an actual MIDI data stream. so, you can, if
you want, do patch loading etc. via the MIDI port. so why not ?

because its about 100 times slower than doing Intel i/o port data
transfers, and when you're downloading a 10MB sample to the synth,
that speed difference matters *a lot*.

given that h/w implementations of MIDI are rate limited, it normally
makes no sense to use it as a communication channel for large amounts
of data *when a massively faster alternative is available*, the MIDI
SDS not withstanding :)

--p

From - Tue Oct 12 01:08:50 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA21658
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 17:04:56 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA28343 for linux-audio-dev-list; Mon, 11 Oct 1999 16:42:57 -0400
Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA28340 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 16:42:52 -0400
Received: from hendrix (cartman31.zip.com.au [61.8.20.159])
	by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id GAA21379
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 06:21:36 +1000 (EST)
Message-ID: <38024AA8.65F59B4@zip.com.au>
Date: Mon, 11 Oct 1999 20:38:00 +0000
From: Erik de Castro Lopo <erikd@zip.com.au>
Organization: Indonesian murders out of East Timor NOW!
X-Mailer: Mozilla 3.04Gold (X11; I; Linux 2.2.12 i586)
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] sndlib remarks
References: <199910111625.MAA02454@renoir.op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 30547649a9f0f6e1e2ee8db838ca7a14

Paul Barton-Davis wrote:
> 
> i just want to follow up on my comments about sndlib, which sounded
> somewhat depracating.
> 
> sndlib is great! sndlib's author realized that the difference between
> file formats can be split in two: the header type, and the data
> type. instead of having a bunch of code to handle RIFF files, and
> another to handle AIFF, Bill wrote stuff to read RIFF headers and AIFF
> headers, and then "added" stuff to read little endian 16 bit samples
> and big endian 16 bit samples, for example. thus, an AIFF file with
> the data stored a LE16 samples can be handled easily, as can an AIFF
> file with float32 samples, etc. This is easy because the header and
> data formats have been separated from one another.
> 
> this is an excellent design - as far as I understand it, neither the
> SGI or Michael Pruett implementations of libaudiofile do this, and I
> don't know of any other similar libraries that take this approach
> either. 

My libsndfile does it this way as well. All the functions to read 
LE16, BE16, signed char, unsigned char etc are generic. When the header
parsing code figures out what the file type is if stores a function
pointer to the correct reading/writing functions in its private data
section and the correct functions are then called viw this pointer.

Just in case anybody has forgotten :

    http://www.zip.com.au/~erikd/libsndfile/

Erik
-- 
+-------------------------------------------------+
     Erik de Castro Lopo     erikd@zip.com.au
+-------------------------------------------------+
"Testing can prove the presence of bugs, but never their absence."
  -- Edsger Dijkstra

From - Tue Oct 12 01:08:52 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA22902
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 17:12:34 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA28401 for linux-audio-dev-list; Mon, 11 Oct 1999 16:52:43 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA28398 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 16:52:41 -0400
Received: from someip.ppp.op.net (d-bm2-05.ppp.op.net [209.152.194.37]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id QAA29885 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 16:47:56 -0400 (EDT)
Message-Id: <199910112047.QAA29885@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] big picture, for a moment
In-reply-to: Your message of "Sun, 10 Oct 1999 23:38:16 +0200."
             <9910110013080C.00456@localhost.localdomain> 
Date: Mon, 11 Oct 1999 16:47:32 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4838b5a3fc404e6f73c8515201c2f440

I think we need to step up a level or two, and try to clarify the big
picture again.

>From my perspective, I am now agreed that we should use an event
system similar to the one David has proposed. I agree that we should
use a constant frame/sample count argument to plugins, and let them
deal with events in any way they choose. I agree that we need 64bit
timestamps. External event sources (MIDI, audio cards, mice,
keyboards, X servers, etc.) will be handled by the semantic equivalent
of "sensor threads" that are partly autonomous, and partly dependent
on the engine thread.  I think that David agrees that we will not use
shared memory directly to communicate with "clients" (other
processes), but instead will use "sensor threads" that will make
shared memory function like any other event source. Note: an
implementation may or may not use actual threads to implement this,
but the API will be defined so that threads *can* be used.

Where David and I currently disagree is the relationship between
plugins and event ports. I think of a plugin that is introduced to the
system coming into a world of many possible different event ports, and
having a clear idea of the kinds of things it wants to pay attention
to. Those may change as a result of user interaction, but I see the
plugin as "subscribing" to various event ports, and unsubscribing at
other times. Plugins may also be (un)subscribed to ports as a result
of user interaction and/or automation playback. The engine provides a
way to locate a port given its address, so that plugins can subscribe
to its ports of interest. Objects that generate events have no idea
who is subscribed to their ports. All events are timestamped using a
time base maintained by the engine, but usable without having to
preempt the engine thread (if it is indeed a distinct thread).

Next are some ideas that we have not talked about.
-------------------------------------------------

I propose removing the engine from any involvement in event
distribution. We can do this because event distribution does not
involve data copying. The engine is responsible for setting up
connections so that it can adequately grok the nets that the
interconnections create. But event sources simply post events to their
ports, and the port subscribers process the events.  The engine is
responsible for marking the last event on any given port that should
be considered during a plugin's process() call. It is also responsible
for removing all events up to and including that last event at the
appropriate time, and doing appropriate games in memory with them.

Plugins and clients are different. 

A plugin in a precompiled object file which can be dynamically linked
into any program that supports the engine-side of the API. A plugin
can subscribe to any event port known to the engine, register new
event ports, manage its own GUI (which will run in its own thread) and
consider itself closely coupled to the engine.

A client is a standalone program that uses the engine to route data,
or routes data for the engine. Clients do not have access to ordinary
event ports, but instead receive data streams and/or requests for data
from the engine. To make this point clearer, if you write an audio
sequencer as a *client* (i.e. it sends its audio data to an engine,
not directly to an audio device) it cannot receive events (say, GUI
changes or MIDI stuff) from the engine. If you write it as a *plugin*,
then you can.

However, even if the client case, you can still use the MCS library to
manage events within your own process space, and you can also host
plugins that use the API. This is the "anyone can write an audio
server" approach :) More significantly, by doing this, you can almost
certainly conveniently package the functionality of your application
in a format that can be a plugin.

Likewise, you might write an application that routes audio over a
network using some sensible protocol. Your program can be a client of
the engine, acting as one of its output destinations, and potentially
a destination for other programs that use the API as well. If you
write your program using the MCS API internally, you could probably
repackage it as a plugin as well.

Individual users of the MCS system would need to decide if they
preferred plugins or clients for certain purposes.

We have not talked about how to address ports. Strings are easy, but
speed daemons will prefer integer values formed via some scheme that
encodes the port's "name". 

However, the description I have given above, I think that this is an
API that I can and would use for all my audio/MIDI programs. 

--p

From - Tue Oct 12 01:09:10 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA18252
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 20:18:57 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA28847 for linux-audio-dev-list; Mon, 11 Oct 1999 20:03:39 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA28833 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 20:03:33 -0400
Received: from localhost.localdomain (d212-151-59-14.swipnet.se [212.151.59.14]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA19214; 
          Tue, 12 Oct 1999 01:58:40 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Kai Vehmanen <kaiv@wakkanet.fi>, Paul Barton-Davis <pbd@Op.Net>
Subject: Re: [linux-audio-dev] plugin questions
Date: Mon, 11 Oct 1999 23:43:58 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <Pine.LNX.4.10.9910111257250.655-100000@sculpcave.localdomain>
In-Reply-To: <Pine.LNX.4.10.9910111257250.655-100000@sculpcave.localdomain>
MIME-Version: 1.0
Message-Id: <99101200144700.00526@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id BAA19214
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA18252
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 8e525402fcb50eb2078e2cd04df5240a

On Mon, 11 Oct 1999, Kai Vehmanen wrote:
> [example 1]
> - I might replace my custom filters with plugin filters and 
>   just hide all plugin-related stuff from users -> from their point 
>   of view everything looks the same: the actual effect, user interface,
>   controllable parameters, etc ...

This is exactly what I had in mind. One example of "hidden" plug-ins
is the "hardcoded" infrastructure of a mixer. Input stages, faders,
effect sends and the parts of the master section could be little
plug-ins that are all controlled by one big, carefully designed UI.

Demanding power user:
"Hmm... The soft-clip limiter of this otherwise excellent mixer
simply sucks. I'll just rip the plug-in out, and throw in the warm,
analog-feel limiter from that virtual DSP rack instead!"

> And the normal win/mac case:
> 
> [example 3]
> - we have a audio app that supports plugins
> - if plugin has a custom-UI, use it, otherwise use 
>   a generic-UI 

And there's one good reason to leave out the UI for some plug-ins: If
they have only one or two simple controls, why waste time making
clumsy pop-up windows that no one will want to see anyway?

> At some point we were talking about init-parameters and 
> processing-parameters (I don't remember the exact terms). 
> We could decide to accept string parameters only when initializing 
> plugins. If you need to change a string value, you'd just 
> reinitialize.

I had this exact problem in mind when I thought up the "use the event
system for *everything*" model. There's no strict distinction between
init time and run time; only certain rules for what you can do when.
(And if you break them, the system will just yell at you, and send an
informative debug message to the UI, or some other sensible place.)

The event system supports dynamic size events - so there's no need to
treat strings as a special cases for that reason. View the event
system (and actually the whole MCS) as a slightly specialized RT-IPC
toolkit; no MIDI-style event specific crap. What we're after when we
want to restrict the number of event data types is only less API
details, and more flexibility when connecting things.

> > fierce arguments on the Csound mailing list about the preferability of
> > double over float ...
> 
> Hmm, why don't we just use a typedef that is required to be 
> a floating-point type. 32bit machines can use floats while 
> 64bit machines (and precision-freaks) can use doubles or even 
> long doubles...?

I think it's a matter of precision; not architecture. And, there's no
way you can allow anyone to change the data types! All plug-ins and
applications *must be binary compatible* with the official MCS
implementations on the supported platforms. If they're not, we'll get

1) Very bad crashes

2) Very annoyed developers

3) Even more annoyed users

4) No proprietary, closed source plug-ins or applications

No way.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Oct 12 01:09:12 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA18646
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 20:21:34 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA28831 for linux-audio-dev-list; Mon, 11 Oct 1999 20:03:32 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA28826 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 20:03:29 -0400
Received: from localhost.localdomain (d212-151-59-14.swipnet.se [212.151.59.14]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA19232; 
          Tue, 12 Oct 1999 01:58:43 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Kai Vehmanen <kaiv@wakkanet.fi>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] linux audio apps/authors behind open-plugin-whatever
Date: Tue, 12 Oct 1999 00:19:07 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <Pine.LNX.4.10.9910111216290.655-100000@sculpcave.localdomain>
In-Reply-To: <Pine.LNX.4.10.9910111216290.655-100000@sculpcave.localdomain>
MIME-Version: 1.0
Message-Id: <99101200444001.00526@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id BAA19232
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA18646
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b39925ee0547e49c611c014650e7a22a

On Mon, 11 Oct 1999, Kai Vehmanen wrote:
[...]
> One thing I've noticed about myself is that I'm more of a top-down
> designer. When you talk about the low-level details, it's been 
> hard for me to see where do these things fit in the big picture.

I think that's been a problem for us as well at times... :-D

> I usually design my software starting from top-level concepts.

I have been thinking about, and drafting designs for systems of this
kind for years. Although things like crappy OS's and hardware
restrictions have limited my motivation of coding something useful,
the big picture of the system is pretty clear in my mind by now.
(Especially the last few weeks have been incredibly productive in
that perspective!)

When I start describing some low level details, I sometimes start on
a too low level, and there we go again; "Now, how is *THAT* supposed
to work!?" :-) OTOH, these - at times somewhat chaotic - discussions
have given me a lot of inspiration, and resulted in some new, cool
ideas. I think it's time I start to turn my part of the design into a
structured document, and some more code.

> Anyway, I've had a _lot_ of fun reading linux-audio-dev recently
> and that's always a good sign! :)

Well, IMO, this is one of the most interesting places on the net
right now!

If I had been working alone on my own project, I would have had
*ages* of solving boring (it *is* boring to design alone, when the
tempo is limited by your own lack of inspiration) little problems
ahead.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Oct 12 01:09:07 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA18193
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 20:18:33 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA28844 for linux-audio-dev-list; Mon, 11 Oct 1999 20:03:37 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA28830 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 20:03:32 -0400
Received: from localhost.localdomain (d212-151-59-14.swipnet.se [212.151.59.14]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA19238; 
          Tue, 12 Oct 1999 01:58:44 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Andy Lo A Foe <andy@alsa-project.org>, Kai Vehmanen <kaiv@wakkanet.fi>
Subject: Re: [linux-audio-dev] plugin questions
Date: Tue, 12 Oct 1999 00:47:05 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: Linux Audio Dev <linux-audio-dev@ginette.musique.umontreal.ca>
References: <Pine.LNX.4.05.9910111507280.18301-100000@alsa.alsa-project.org>
In-Reply-To: <Pine.LNX.4.05.9910111507280.18301-100000@alsa.alsa-project.org>
MIME-Version: 1.0
Message-Id: <99101201060702.00526@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id BAA19238
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA18193
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c051889dc407d9f769a73f544e04cf12

On Mon, 11 Oct 1999, Andy Lo A Foe wrote:
> We are at point in AlsaPlayer development where parameters for the various
> plugins (input, output, scopes) need to be created/preserved :-)
> One of the ideas that have been floating around the mailing is to let the
> plugins return a LIST of parameters they have. A parameter can be for
> example a string, float, int, color, etc. A parameter should also have
> optional constraints tied to it (int, floats can have ranges). This will
> allow the application to build its own User Interface -> flexiblity.
> (I realize of course that not every plugin will be able to communicate its
> parameters easily this way, room should be left for plugin specfic widgets
> for example)

On the contrary, I'd suggest that event types are restricted to as
few as possible, and preferably, they should even have their ranges
defined in the API spec.

Why?

Well, it doesn't matter much to a generic GUI, and not too much to an
automotion system (sequencer) either. But it *does* start to get
messy with user defined ranges when connecting plug-ins into event
processing networks. Adapting the output events to all sorts of
inputs...

<philosophy>
Of course, this depends on what the system is going to be used for.
However, I usually try to design this kind of things with OS design
philosophy in mind - keep it clean, layered and reusable. The "hack
one API for every new situation" philosophy (empowered by a certain
company in particular) is useless in the long run, at least when
trying to design something *useful*.
</philosophy>

> > Hmm, why don't we just use a typedef that is required to be 
> > a floating-point type. 32bit machines can use floats while 
> > 64bit machines (and precision-freaks) can use doubles or even 
> > long doubles...? 
> 
> Is it that simple? Changing the type might also change the min/max values,
> or require another algorithm for better accuracy!?

Another point, apart from the compatibility one I made before... High
accuracy + high speed processing *does* involve careful selection of
temporary register/variable sizes, and ordering of operations, even
with FP. Perhaps not a big problem in most cases, but it exists, and
may matter quite a bit in some extreme situations.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Oct 12 01:08:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA08488
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 19:15:07 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA28672 for linux-audio-dev-list; Mon, 11 Oct 1999 18:58:27 -0400
Received: from zapfhahn.bone.twc.de (zapfhahn.bone.twc.de [193.158.34.194]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA28669 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 18:58:25 -0400
Received: from space.twc.de (IDENT:stefan@space.twc.de [193.158.34.195])
	by zapfhahn.bone.twc.de (8.9.3/8.9.3) with ESMTP id AAA04927;
	Tue, 12 Oct 1999 00:51:17 +0200
Received: (from stefan@localhost)
	by space.twc.de (8.8.7/8.8.7) id AAA19114;
	Tue, 12 Oct 1999 00:50:31 +0200
Message-ID: <19991012005031.48125@space.twc.de>
Date: Tue, 12 Oct 1999 00:50:31 +0200
From: Stefan Westerfeld <stefan@space.twc.de>
To: Paul Barton-Davis <pbd@Op.Net>
Cc: est@hyperreal.org, linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] aRts, KDE - say it ain't so!
References: <19991011162525.18424.qmail@hyperreal.org> <199910111716.NAA07882@renoir.op.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.85e
In-Reply-To: <199910111716.NAA07882@renoir.op.net>; from Paul Barton-Davis on Mon, Oct 11, 1999 at 01:16:05PM -0400
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ec8e175faa44346f8ddf25fc79dd3eab

   Hi!

On Mon, Oct 11, 1999 at 01:16:05PM -0400, Paul Barton-Davis wrote:
> >   abilities are leagues ahead of anything yet found on Unix. It will
> >   offer capabilities to KDE that have so far been found only on OSes
> >   like Windows, BeOS, etc.
> 
> yes, aRts is great but .... sigh - "offer capabilities to KDE" 
> 
> Windows, for all its faults, is an OS. BeOS is an OS. KDE is not an
> OS! what is anyone doing "offering capabilities" to the bloody desktop
> architecture. this is *insane*.
What is the OS? Putting it into the linux kernel, excluding every FreeBSD
and Solaris user, and making plugin crashs take down the whole system?

> the work that Stefan has done on aRts is wonderful, but this idea of
> there being a desktop, rather than an OS, that offers these
> capabilities is a dangerous path, and it fractures our community.

Does the idea that there is an X11 server, offering graphics capabilities
to almost any graphic linux application seriously fracture our community?
Have you got an alternative plan for that? I mean: having an audio server
engine is pretty much the same idea, just for audio.

> I am
> not going to run KDE or GNOME for the foreseeable future, and anyone
> who thinks that the way forward is to build functions into either of
> these systems that are not part of the kernel or a standalone program
> is not my friend.

I also think audio technology should *not* depend on the desktop. Since
starting aRts I invested an enormous amount of effort in making it work
with CORBA. If you download it, you'll see that every aRts version since
quite a lot of time comes with the --disable-kde option.

Another thing I invested work into is GUI seperation. That works. You can
write a Gtk+ frontend, or Java, or whatever else.

And if you remember how that topic came onto that list recently: It was
some ongoing discussion on the gnome-kde list, whether or not using aRts
in Gnome would be a good idea as well. So I am open to everything, it's
just that I can't write that Gtk+ stuff and that Qt stuff and maintain
the CORBA things and integrate with KDE2 and everything.

If you want it in Gnome, just do it, I'll help. If you want to use it
without desktop, just do that. If you want to use it without X11, you
can. If you want it without Linux, you can. And if you are really bored,
you can even try to get it running under NT.

For KDE2 we are working on things like KApplication::play to play a sample
so that everybody can use it really easily. Or for instance KAudioStream
which will about be the same as esd offers through their streaming
record/play API, but easier to use for KDE users, since integrated with
Qt signals&slots. However the aRts core won't depend on Qt, nor on KDE,
and I'll try to put as many lines of code in the common core as possible.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-

From - Tue Oct 12 01:08:58 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA08904
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 19:18:03 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA28691 for linux-audio-dev-list; Mon, 11 Oct 1999 19:03:38 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA28688 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 19:03:35 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id SAA21278
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 18:58:47 -0400 (EDT)
Received: from localhost by ux02 (8.9.1b+Sun) id SAA20005; Mon, 11 Oct 1999 18:58:48 -0400 (EDT)
Date: Mon, 11 Oct 1999 18:58:48 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: LAD <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] linux audio apps/authors behind open-plugin-whatever
In-Reply-To: <Pine.LNX.4.10.9910092125210.5477-100000@sculpcave.localdomain>
Message-ID: <Pine.GSO.4.10.9910111839340.19759-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3617adb34e550a43f79323df12043926

On Sat, 9 Oct 1999, Kai Vehmanen wrote:

> No answer, so let's ask again...

Umm, I didn't hear the question, so I'll throw out answers to all the
likely ones.  :-)
 
> Other list actives, are you working on some project?
> - David Slomin

My two active LAD-related projects are the NetMIDI/FIFO-MIDI Toys (small
experiments in routing raw MIDI messages over sockets and pipes) and
Songpad (a MIDI sequencer written in Java, which emphasizes powerful
editing interfaces over realtime accuracy).  Neither project is "ready for
primetime", although many of the Toys are useful and useable today, just
not polished.

I have no specific plans to jump onboard any of the New Grand Unified
Linux Audio Plugin And Event Router Architecture (TM) bandwagons, be they
ALSA, aRts, Audiality, or otherwise.  I respect the goals and skills
involved in each project, and will certainly write adapter code that
optionally lets my programs interact with whichever one[s] wins out in the
future, but for now I see no real need.  I dislike excess dependencies and
target Posix, not Linux for most of my development.

If you're looking for a download site for my stuff, I regret to say that
I'm temporarily lacking a non-firewalled IP address for my little web
server (due to a geographic move at work), so please contact me directly
if you're interested.  (/me cringes at the thought of Slashdot effect over
email...)

Did I guess the question correctly anywhere in there?
Div.

From - Tue Oct 12 01:09:08 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA18232
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 20:18:46 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA28848 for linux-audio-dev-list; Mon, 11 Oct 1999 20:03:39 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA28836 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 20:03:33 -0400
Received: from localhost.localdomain (d212-151-59-14.swipnet.se [212.151.59.14]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA19245; 
          Tue, 12 Oct 1999 01:58:45 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: est@hyperreal.org, linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] aRts in Linux Today KDE Developers Conference Report
Date: Tue, 12 Oct 1999 01:07:38 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <19991011162525.18424.qmail@hyperreal.org>
In-Reply-To: <19991011162525.18424.qmail@hyperreal.org>
MIME-Version: 1.0
Message-Id: <99101201151903.00526@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id BAA19245
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA18232
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: fb5e8dfa68ab00b9e37feb36216dc113

On Mon, 11 Oct 1999, est@hyperreal.org wrote:
> Check out this interesting report at
> http://linuxtoday.com/stories/10975.html.
> 
> Here's what it had to say about aRts:
> 
> aRts
> 
>    Stefan Westerfeld demonstrated aRts -- his next generation network
>    multimedia framework. aRts uses a very modular system of CORBA
>    components to achieve nearly limitless potential for multimedia
>    playing and manipulation. KDE 2.0 will use an optimized subset of aRts
>    to handle all audio playing. Future releases of KDE will then use the
>    more advanced video and audio/video manipulation abilities available
>    in aRts. The aRts server is incredible. It's synthesis and filtering
>    abilities are leagues ahead of anything yet found on Unix. It will
>    offer capabilities to KDE that have so far been found only on OSes
>    like Windows, BeOS, etc.

Very cool, but we're aiming even higher! ;-)

Seriously, this is one example of the incredible potential of the
Community. Add the few key technologies needed to make code *truly*
reusable - at run time - and competition is none.

Back to work... :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Oct 12 01:09:01 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA10882
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 19:31:37 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA28735 for linux-audio-dev-list; Mon, 11 Oct 1999 19:15:37 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA28732 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 19:15:35 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id TAA22264
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 19:10:29 -0400 (EDT)
Received: from localhost by ux02 (8.9.1b+Sun) id TAA20081; Mon, 11 Oct 1999 19:10:31 -0400 (EDT)
Date: Mon, 11 Oct 1999 19:10:30 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: timing issues in a client/server enviroment
In-Reply-To: <199910092310.TAA01929@renoir.op.net>
Message-ID: <Pine.GSO.4.10.9910111905520.19759-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 8910437fd1b377a4c03e6c75fbb5fbfe

On Sat, 9 Oct 1999, Paul Barton-Davis wrote:

> i don't want to force programs into using something other than the
> Unix file interface if they believe they want to use it.

Thanks Paul... there are several of us here who very much appreciate that
sentiment!  :-)  

Actually, I don't so much care if I'm writing "directly to the hardware"
as in the case of OSS, or if I'm writing to a routing system that acts
just like a hardware port, as in the case of ALSA, as long as I still have
the choice of coding using traditional file system operations.

Div.

From - Tue Oct 12 01:09:13 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA19088
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 20:24:03 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA28849 for linux-audio-dev-list; Mon, 11 Oct 1999 20:03:41 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA28843 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 20:03:36 -0400
Received: from localhost.localdomain (d212-151-59-14.swipnet.se [212.151.59.14]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA19254; 
          Tue, 12 Oct 1999 01:58:47 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>, Kai Vehmanen <kaiv@wakkanet.fi>
Subject: Re: [linux-audio-dev] a new application underway
Date: Tue, 12 Oct 1999 01:16:28 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <199910111645.MAA04412@renoir.op.net>
In-Reply-To: <199910111645.MAA04412@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101201455804.00526@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id BAA19254
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA19088
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1388b770bbeb7ea0e8f3ab616d978514

On Mon, 11 Oct 1999, Paul Barton-Davis wrote:
> i spent some time talking with people who use mixers a lot, and asked
> them how helpful it was to be able to use a stereo input signal on a
> single strip. the verdict: as long as you can group (sync) the faders
> for two strips, they didn't care, even when i pointed out that it
> consumed an entire extra strip this way. ah, diehards :)

Actually, I agree with them to some extent. I don't like stereo
plug-ins, unless they have a decent excuse to be stereo. What if I
want to up the treble a little on the left channel of that stereo
strip? These things happen...

> i think it depends in part on what your inputs are. if they really are
> stereo signals (stereo soundfiles, devices etc.), then having audio
> default to stereo is a good choice.

On the contrary, it's usually in that particular case it makes sense
to be able to control the channels independently.

> if they are mostly mono (mono
> soundfiles, devices, mics, etc), which is often true in live
> recording, then it can be a bad choice, computationally.

Yes. However, sooner or later they have to go stereo one way or
another... (Assuming we're playing back from disk/RAM, or monitoring.)

> i noticed that neundo allows both. i'm still thinking about this.

Sounds pretty sensible to me, at least on a digital system where
processing takes power from a common pool. (In an analog system it's
different; either you have enough channels, or you don't.)

> >Hmm, it looks like our designs are actually quite similar. Ecasound's 
> >inputs do much the same as your input_device-source-strip abstraction 
> >and ecasound's chains are just like your buses (hmm, where do you put 
> >additional effect processing... buses or strips?). 
> 
> like an expensive hardware mixer: both.

Yep. That's a very simple but still efficient way to get the plug-ins
where you want them.

> i'm still working on optimizing the amount of data copying that goes
> on in a net like the one above, but it all works just fine for
> now. MIDI controllable control elements too :)

VST uses the process() and processReplacing() plug-in calls as a
part of that optimization. I suggest process() to be our replacing
method, and process_mix() to add data to the output buffers. The big
difference: process_mix() is *required* to support a linear gain
parameter for each output channel.

But, is the cost of clearing a buffer really significant these days,
when some plug-ins can eat a whole P-II 400 using a single instance?

IMO, it *is* still significant when using lots of simple plug-ins to
build modular synths, so I'd suggest:

"It's *strongly* recommended that fast plug-ins that are
 likely to be used in many instances, provide *both*
 process() and process_mix().  More CPU intensive plug-ins
 may leave out one of them; preferably process(), as that
 can be handled by the engine just clearing the buffer
 when necessary."

OK? Any other process_*() version that might be even more useful?
(And, hey! Keep in mind that this isn't for audio alone...)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Oct 12 01:09:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA09321
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 19:20:54 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA28665 for linux-audio-dev-list; Mon, 11 Oct 1999 18:54:01 -0400
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA28662 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 18:53:58 -0400
Received: from d1o43.telia.com (d1o43.telia.com [194.22.195.241])
	by mailb.telia.com (8.9.3/8.9.3) with ESMTP id AAA04857
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 00:49:13 +0200 (CEST)
Received: from skelleftea.mail.telia.com (t8o43p56.telia.com [194.237.168.236])
	by d1o43.telia.com (8.8.8/8.8.5) with ESMTP id AAA07467
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 00:49:12 +0200 (CEST)
Message-ID: <380273A9.73FA2B44@skelleftea.mail.telia.com>
Date: Tue, 12 Oct 1999 00:32:57 +0100
From: Roger Larsson <roger.larsson@skelleftea.mail.telia.com>
X-Mailer: Mozilla 4.6 [en] (Win95; I)
X-Accept-Language: sv,en
MIME-Version: 1.0
CC: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] API design again [MORE code]
References: <199910101638.MAA10195@renoir.op.net> <99101021222707.00456@localhost.localdomain>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by mailb.telia.com id AAA04857
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA09321
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c35fec758de6c1bcd2281e3d8849ca8b



David Olofson wrote:
> 
> On Sun, 10 Oct 1999, Paul Barton-Davis wrote:
> > [ ... sleeping ... ]
> >
> > >So where do you get the CPU time for other tasks, if the engine never
> > >sleeps...? Or am I missing what you're actually saying here?
> >
> > (for a moment there, i thought i had fallen into my "i have a dual CPU
> > box and so does everyone else" trap. but fortunately, no ... )
> 
> Scary... *hehe*
> 
> > the engine sleeps whenever it calls a plugin that calls
> > read/write. how long it sleeps depends on the i-node it reads/writes.
> > if it never calls read/write, it will never sleep.
> 
> Ok, that's exactly the sleep point I had in mind...
> 
> > "nothing is calling read/write" is actually a pathological situation,
> > but relatively easily dealt with. quasimodo and hdr both have to do
> > this. for quasimodo, a plugin must be able to tell us if it does
> > input. for hdr, if there are no inputs active then we stall the
> > engine. we focus on input because output is handled in these programs
> > by the "engine" itself. in MCS, this may not be true, so the
> > work_to_do() test has to include active ins OR active outs.
> 
> Yep. However, there's one thing to keep in mind here (at least with
> the kernel MCS implementation I have in mind); it's perfectly
> possible that the *engine* never calls an I/O plug-in, and therefore
> never sleeps that way. Instead, it'll have to sleep on the MCS
> connection it's supposed to be sync'ed with, after each finished
> cycle. (Like Benno's client/server interface.)
> 
> > sensor threads should run with SCHED_FIFO, but its not clear to me if
> > they should have a priority above or below or equal to that of the
> > engine thread.
> 
> Above, as they have to be able to preempt the engine to get correct
> timestamps.
> 

Thumb rule for priority:
  The shorter run the higher priority.
  The longer run the lower priority.
  Then the short run can interfere with the long but not the opposite.

But there are exceptions:
  To avoid filling up processor queues it might be better to
  run producer threads with lower prio. - consumer threads will
  then be able to empty their input queues before new ones are
  created.
  This is not a good solution if you can not combine inputs, or
  ignore some.

  Example:
    suppose that engine threads have lower prio. than sensor threads.
    and that each sensor tread is "connected" (1-1) to a plugin.
    then data may build up, and overflow, on the input to the engine
    by using more sensor threads than expected.
    
  With a fast engine, the jitter in time stamps might be worth it...
  (Much time stamping will be done in kernel drivers anyway, or?)


/RogerL

-- 

The Internet interprets Windows as damage, 
             and routes around it.

Roger Larsson
Skellefte
Sweden

From - Tue Oct 12 01:09:15 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA20108
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 20:30:53 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA28894 for linux-audio-dev-list; Mon, 11 Oct 1999 20:15:26 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA28891 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 20:15:23 -0400
Received: from localhost.localdomain (d212-151-59-14.swipnet.se [212.151.59.14]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA10562; 
          Tue, 12 Oct 1999 02:10:35 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>
Subject: Re: [linux-audio-dev] MCS: 64 bit timestamps?
Date: Tue, 12 Oct 1999 01:46:38 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
References: <199910111655.MAA05346@renoir.op.net>
In-Reply-To: <199910111655.MAA05346@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101202173005.00526@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id CAA10562
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA20108
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7e675faeafe2a7a9b7c52b750c1b3fb6

On Mon, 11 Oct 1999, Paul Barton-Davis wrote:
> >> this doesn't take sample clock drift into account. the engine would
> >> have to deal with this by adjusting the
> >> cycle_counter_at_start_of_control_loop value at appropriate intervals
> >> to shift everyone's idea of the current time.
> >
> >(I don't think fiddling with the TSC timestamps is a good thing, as it
> >makes the engine code a bit unclear...)
> 
> eh ? is this because there are going to be no function calls in the
> engine or something extreme like that ?

No, I just think that "cycle_counter_at_start_of_control_loop"
suggests that it's really a TSC timestamp, and not some manipulated
pseudo-TSC. No big deal, though...

[...]
> >	current_cycle_counter = read_tsc ();
> >	cycle_diff = current_cycle_counter -
> >-		cycle_counter_at_start_of_control_loop;
> >+		cycle_counter_at_last_sync_point;
> 
> 		             what is the difference here, other than
> 		             the name ?

"last sync point" can be just any time... Doesn't need to have any
direct relation to engine cycles.

> so i tried to ensure that it didn't need a lock, thus my avoidance of
> the use of two engine-stamped values.
> 
> if you believe that TSC/audio card drift will be minimal, then you
> don't need to worry.

That's not the case for most users. It's pretty close for high quality
cards, but some "consumer quality" cards even use ultra cheap ceramic
resonators or something for CODEC time base... Heard figures like
44100300 Hz *flutter*!

> if you do need to worry about it, adjusting the cycle_counter value
> from the engine is pretty simple, as you yourself pointed out a week
> or so ago. if the engine notices:
> 
>         TSC       sample count
> 	---       ------------
>  	nnn       yyy
> 
> but expected:
> 
>         nnn       xxx
> 
> it just adds to the cycle_counter_at_last_sync_point (or whatever):
> 
>    ... set cycle_counter_at_last_sync_point in the normal way ...
>    cycle_counter_at_last_sync_point += (xxx - yyy) * cycles_per_sample.
> 
> and we're done. whats so unclear ?

Nothing, really... Just not sexy enough for me, I guess. ;-)

But there's one problem: How do you know what engine cycle the
timestamp belongs to? The sensor thread runs asynchronously, just as
you wanted it to... You never know how many cycles have passed since
last time you were awake, and what if you grab a timestamp, and miss
the deadline for the next cycle? (Note: That's OK! The fixed latency
is say, 3 cycles, so there's plenty of time.)

(My previous patch backed out first)
-----8<------------------------------
	current_cycle_counter = read_tsc ();
	cycle_diff = current_cycle_counter -
-		cycle_counter_at_start_of_control_loop;
+		cycle_counter_at_engine_zero_time;
	now = (msc_time_t) (samples_per_cycle * (float) cycle_diff));
------------------------------>8-----

Solved.

Engine::timestamp() now returns the time in samples relative to the
engine's idea of global time==0. Adjust
cycle_counter_at_engine_zero_time as you described above, and it's as
accurate as it gets, and we need only one shared variable.

(Well, perhaps cycle_counter_at_engine_zero_time could be something
else in a somewhat nicer unit, but that's a final implementation
detail.)

Unless I missed something, this is more like what I call sexy... :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Oct 12 01:09:03 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA11374
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 19:35:25 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA28740 for linux-audio-dev-list; Mon, 11 Oct 1999 19:16:01 -0400
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA28737 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 19:15:58 -0400
Received: from d1o43.telia.com (d1o43.telia.com [194.22.195.241])
	by mailb.telia.com (8.9.3/8.9.3) with ESMTP id BAA11966
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 01:11:14 +0200 (CEST)
Received: from skelleftea.mail.telia.com (t8o43p56.telia.com [194.237.168.236])
	by d1o43.telia.com (8.8.8/8.8.5) with ESMTP id BAA14920
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 01:11:13 +0200 (CEST)
Message-ID: <380278D3.FA7AB2F0@skelleftea.mail.telia.com>
Date: Tue, 12 Oct 1999 00:54:59 +0100
From: Roger Larsson <roger.larsson@skelleftea.mail.telia.com>
X-Mailer: Mozilla 4.6 [en] (Win95; I)
X-Accept-Language: sv,en
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] aRts, KDE - say it ain't so! [it ain't]
References: <199910111716.NAA07882@renoir.op.net>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by mailb.telia.com id BAA11966
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA11374
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b88218e315cc87596f4ba226e15f4759

Hi all,

The only part of aRts plugin does not care about what window system
you use.

But to be able to connect the plugins in a nice and easy way
there is a GUI written in and using KDE.

A few notes from arts one year history page:
  http://www.stud.uni-hamburg.de/~arts/doc/1styear/index.html

"Besides other reasons, that was the motive why CORBA came into aRts. It
 would allow the synthesizer to simply do its work, alone, independent
from the
 toolkit. Anyone who liked to do something with the synthesizer then
could write a
 GUI in his/her favourite programming language, or a scriping system, or
whatever
 else."

"And others could develop a Gnome frontend parallely - until now there
just never
 happened to be someone who did that..."

Happy porting/developing!

BTW, we should take a good look into this interface IMHO.

/RogerL

Paul Barton-Davis wrote:
> 
> >   abilities are leagues ahead of anything yet found on Unix. It will
> >   offer capabilities to KDE that have so far been found only on OSes
> >   like Windows, BeOS, etc.
> 
> yes, aRts is great but .... sigh - "offer capabilities to KDE"
> 
> Windows, for all its faults, is an OS. BeOS is an OS. KDE is not an
> OS! what is anyone doing "offering capabilities" to the bloody desktop
> architecture. this is *insane*.
> 
> the work that Stefan has done on aRts is wonderful, but this idea of
> there being a desktop, rather than an OS, that offers these
> capabilities is a dangerous path, and it fractures our community. I am
> not going to run KDE or GNOME for the foreseeable future, and anyone
> who thinks that the way forward is to build functions into either of
> these systems that are not part of the kernel or a standalone program
> is not my friend.
> 
> --p

-- 

The Internet interprets Windows as damage, 
             and routes around it.

Roger Larsson
Skellefte
Sweden

From - Tue Oct 12 01:09:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA25051
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 21:02:17 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA28965 for linux-audio-dev-list; Mon, 11 Oct 1999 20:42:39 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA28962 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 20:42:36 -0400
Received: from localhost.localdomain (d212-151-59-14.swipnet.se [212.151.59.14]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA10806; 
          Tue, 12 Oct 1999 02:37:46 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>, est@hyperreal.org
Subject: Re: [linux-audio-dev] aRts, KDE - say it ain't so!
Date: Tue, 12 Oct 1999 02:18:06 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <199910111716.NAA07882@renoir.op.net>
In-Reply-To: <199910111716.NAA07882@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101202444106.00526@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id CAA10806
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA25051
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d4e40fe46ed1bf08687a78ebb11af455

On Mon, 11 Oct 1999, Paul Barton-Davis wrote:
> >   abilities are leagues ahead of anything yet found on Unix. It will
> >   offer capabilities to KDE that have so far been found only on OSes
> >   like Windows, BeOS, etc.
> 
> yes, aRts is great but .... sigh - "offer capabilities to KDE" 
> 
> Windows, for all its faults, is an OS. BeOS is an OS. KDE is not an
> OS! what is anyone doing "offering capabilities" to the bloody desktop
> architecture. this is *insane*.

Uhm... I really have to agree there. System services should be
*system* services - not something you can have if you use some
special applications and/or daemons that need lots of other stuff to
work.

> the work that Stefan has done on aRts is wonderful,

Indeed. :-)

> but this idea of
> there being a desktop, rather than an OS, that offers these
> capabilities is a dangerous path, and it fractures our community.

Yep...

> I am
> not going to run KDE or GNOME for the foreseeable future, and anyone
> who thinks that the way forward is to build functions into either of
> these systems that are not part of the kernel or a standalone program
> is not my friend.

I use KDE because I like it, and because it does a good job as a
rather complete desktop environment. But if it's about to turn my
Linux box into SuperWindoze or MegaMac, I'm going to run something
else on my *GNU/Linux* system soon.

Sorry for sounding harsh and negative for a moment, but this *is* a
dangerous path that all too many skilled and motivated hackers seem
to be going down.

Keep it modular, flexible and generic. The most reusable and
efficient parts could go into the kernel, maybe even as an extension
of the OS standard. UN*X is a *very* powerful design, and IMO, the
Right Thing (tm) is to stay close to that standard, possibly
improving on it, and avoid building high towers of layered APIs and
"subsystems". High buildings are hard to move around, and even
harder to combine with other such structures...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Oct 12 01:09:22 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA27220
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 21:14:52 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA28990 for linux-audio-dev-list; Mon, 11 Oct 1999 20:58:08 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA28987 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 20:58:05 -0400
Received: from localhost.localdomain (d212-151-59-14.swipnet.se [212.151.59.14]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA01533; 
          Tue, 12 Oct 1999 02:53:17 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] aRts, KDE - say it ain't so!
Date: Tue, 12 Oct 1999 02:46:43 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910111815.OAA14082@renoir.op.net>
In-Reply-To: <199910111815.OAA14082@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101203000507.00526@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id CAA01533
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA27220
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b5b3e2e13a894faf62d24302090f902d

On Mon, 11 Oct 1999, Paul Barton-Davis wrote:
> But audio has no inherent connection to the Unix graphical
> environment.
> 
> I don't want phenomenally useful tools ending up as part of that
> *graphical* environment when they should be part of *the {Li,U}nix
> environment* instead.

Or; does my dedicated Linux based sampler/recorder rack box have to
run X, Qt, Corba/Mico etc, just because I want to base it's software
on aRts? Sorry, but it would *possibly* run SVGAlib and a clean,
simple, custom GUI.

> >GNOME is a good thing, in my book.  
> 
> in mine too. i just don't see that it has any place defining audio
> standards that might have a role in non-graphical programs.

...and meanwhile, *I'm* trying to turn this new API into something
that's generally useful in complex, high bandwidth, real time
streaming systems. It should require only the Linux kernel and the
most basic stuff around it. I'd be disappointed if a basic engine
and some plug-ins wouldn't fit on a bootable Linux floppy.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Oct 12 01:09:18 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA24956
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 21:01:47 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA28957 for linux-audio-dev-list; Mon, 11 Oct 1999 20:40:24 -0400
Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA28954 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 20:40:21 -0400
Received: from d1o43.telia.com (d1o43.telia.com [194.22.195.241])
	by mailf.telia.com (8.9.3/8.9.3) with ESMTP id CAA04424
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 02:35:33 +0200 (CEST)
Received: from skelleftea.mail.telia.com (t8o43p56.telia.com [194.237.168.236])
	by d1o43.telia.com (8.8.8/8.8.5) with ESMTP id CAA11345
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 02:35:32 +0200 (CEST)
Message-ID: <38028C96.DBA0F98E@skelleftea.mail.telia.com>
Date: Tue, 12 Oct 1999 02:19:18 +0100
From: Roger Larsson <roger.larsson@skelleftea.mail.telia.com>
X-Mailer: Mozilla 4.6 [en] (Win95; I)
X-Accept-Language: sv,en
MIME-Version: 1.0
CC: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] MCS: 64 bit timestamps? [simplified]
References: <199910110404.AAA17257@renoir.op.net>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by mailf.telia.com id CAA04424
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA24956
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1d9913cdb50daff934efab644cfefdd3

Hmm...

There are some problems here, I think.

Paul Barton-Davis wrote:
> 
> >> another word about timestamps though. you suggested that in order to
> >> call engine->timestamp(), a sensor thread would have to preempt the
> >       ^^^^^^^^^^^^^^^^^^^
> >What does this function do, exactly?
> 
> msc_time_t
> Engine::timestamp ()
> 
> {
>         /* greatly un-inlined to make function clear ... */
> 
>         tsc_t current_cycle_counter;
>         tsc_t cycle_diff;
>         msc_time_t now;
> 
>         current_cycle_counter = read_tsc ();
>         cycle_diff = current_cycle_counter -
>                      cycle_counter_at_start_of_control_loop;

What happens when the cycle_diff starts to wrap :-)
Ok, we have 2^64 bits, but wery soon we have 2^32 cycles/s CPUs.
1 GHz next year, and increasing rapidly (typing on a 180 MHz PPro
3 years old, assume 10 GHz in another 3 years, ...)

Why subtract the 'cycle_counter_at_start_of_control_loop' anyway?

>         now = (msc_time_t) (samples_per_cycle * (float) cycle_diff));

What 'samples_per_cycle' the requesting plugins, or a master, or ...

Do we really like to have float calculations here? At least we should
make it double to handle the 64 bit cycle_diff. 

Suggestion:
 Treat the tsc as a sample-driven-unit by itself (started at cycle 0),
 but scale it to wrap in a week or so... for debug purposes
 SCALE should be a power of 2, 1 is ok!

#define SCALE 1
msc_time_t
Engine::timestamp ()
{
        /* greatly un-inlined to make function clear ... */
	return read_tsc() / SCALE;
}

msc_time_t
Engine::convert (double secs)
{
	return secs * (read_cycles_per_second_tsc() / SCALE);
}

msc_time_t
Plugin::convert (unsigned sample)
{
	return Engine::convert( sample / this->samples_per_second ) -
this->start_timestamp;
}

Plugin::init (...)
{
	this->start_timestamp = Engine::timestamp();
}
#undef SCALE

Note: this is not SMP safe if people uses processors with
different speeds... some are...
And I think there have been some issues with unsynchronised
cycle counters...


/RogerL
-- 

The Internet interprets Windows as damage, 
             and routes around it.

Roger Larsson
Skellefte
Sweden

From - Tue Oct 12 01:09:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA23343
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 01:00:07 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA29486 for linux-audio-dev-list; Tue, 12 Oct 1999 00:39:43 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA29475 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 00:39:38 -0400
Received: from localhost.localdomain (d212-151-86-72.swipnet.se [212.151.86.72]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id GAA11591; 
          Tue, 12 Oct 1999 06:34:50 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: David Slomin <dgslomin@CS.Princeton.EDU>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc.
Date: Tue, 12 Oct 1999 03:20:01 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <Pine.GSO.4.10.9910111428460.16696-100000@ux02.CS.Princeton.EDU>
In-Reply-To: <Pine.GSO.4.10.9910111428460.16696-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Message-Id: <99101203325108.00526@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id GAA11591
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id BAA23343
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 64e69daaa9ed281f72680579d3d3433a

On Mon, 11 Oct 1999, David Slomin wrote:
> On a related note, why aren't the advanced features of sound cards (in
> particular, patch dumping) performed through sysex commands rather than
> ioctls?  It seems a natural to me to keep everything inband.

Pleeeeezzz, not *more* of that SysEx mess, *especially* not in the
APIs!

IMHO, a more powerful protocol that's *not* crippled by 7 bit data
bytes or similar things, should be used for *all* "internal"
communication. Ok, stream MIDI events if you like (if you feel like a
device driver ;-), but the standard way should be using a generic
event system. (And I'm really trying to design one!)

"Everything inband" it exactly what I want, but MIDI should never
have made it's way into the computer in the first place. (Well, OK,
it was pretty appropriate in the 8 bit days... :-) It's an old,
simple, limited protocol for low bit rate serial lines w/o
handshaking! It still serves it's purpose quite well where it
belongs, but that's about it.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Oct 12 01:09:25 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA01796
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 22:00:14 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA29086 for linux-audio-dev-list; Mon, 11 Oct 1999 21:39:39 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA29083 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 21:39:36 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id VAA04021
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 21:34:05 -0400 (EDT)
Received: from localhost by ux02 (8.9.1b+Sun) id VAA21337; Mon, 11 Oct 1999 21:34:07 -0400 (EDT)
Date: Mon, 11 Oct 1999 21:34:07 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc. 
In-Reply-To: <199910111952.PAA24119@renoir.op.net>
Message-ID: <Pine.GSO.4.10.9910112117400.19759-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 21240f8f68093ade8d45808de9f6191d

On Mon, 11 Oct 1999, Paul Barton-Davis wrote:

> (snip: patch dumps via sysex)
>
> given that h/w implementations of MIDI are rate limited, it normally
> makes no sense to use it as a communication channel for large amounts
> of data *when a massively faster alternative is available*, the MIDI
> SDS not withstanding :)

Oops, I was a little unclear.  I was trying to refer to the app-to-driver
interface, not the driver-to-card one.  Of course the driver should speak
to the card in an optimized manner.  However, when the driver is talking
to an app, it's certainly not limited to the 3.2 kbaud (did I remember
that right?) MIDI cable transfer rate.  Remember that the data in question
never does go out over the wire.

True, you get an automatic 1/8 performance hit (sysex only gives you 
seven bits), but it's nowhere's near as ugly a picture as you painted.

The motivation for this, of course, is that driver-specific ioctls can't
be rerouted over pipes and sockets anywhere near as easily as inband data.
By now, I certainly don't need to reiterate why I'm interested in that.
:-)

Div.

From - Tue Oct 12 01:09:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA23238
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 00:58:55 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA29488 for linux-audio-dev-list; Tue, 12 Oct 1999 00:39:44 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA29477 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 00:39:39 -0400
Received: from localhost.localdomain (d212-151-86-72.swipnet.se [212.151.86.72]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id GAA11606; 
          Tue, 12 Oct 1999 06:34:52 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: David Slomin <dgslomin@CS.Princeton.EDU>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] non-destructive editing
Date: Tue, 12 Oct 1999 03:34:12 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <Pine.GSO.4.10.9910111439270.16696-100000@ux02.CS.Princeton.EDU>
In-Reply-To: <Pine.GSO.4.10.9910111439270.16696-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Message-Id: <99101203443209.00526@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id GAA11606
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id AAA23238
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1a50fc9d214e230d11200811ef6ae9f2

On Mon, 11 Oct 1999, David Slomin wrote:
> If you're attracted to the fixed-size blocks in a single file model, you
> can make it work like a miniature filesystem within the file.  Keep a list
> of "i-nodes" (chunk pointers) in which only the list has to be changed to
> reorder or delete chunks.  You can even store the list in a progressive
> manner such that it represents the history.  Upon "commit", you
> essentially defragment the file.  I once worked on a database that worked
> this way.
> 
> Not that I recommend this method, but it could potentially work for you.
> (Yes there is the issue of edit operations that cross chunk boundaries
> which complicates things quite a bit... left as an excercise to the
> reader.  :-)

Hmm... This method is nice for (dedicated) systems that have to work
very close to the hardware limits, but PLEASE *KILL* that "commit"
operation! It's probably the *one* thing that users hate most about
digital recording systems.

"Commit!"
Bzz...
Rattle, rattle...
Zrrr...
(A few seconds or more later:) "Done!"

This is not how to do things with the crazy HD performance you can
get for a few $100 (at most!) these days. Use the new technology to
save *time* and nerves, not money.

But of course, if you're going to get rich on selling overpriced HDR
units that cost you close to nothing to build, the "commit" style
might be a way to save some on the HDs... :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Oct 12 01:09:24 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA01699
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 21:59:39 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA29092 for linux-audio-dev-list; Mon, 11 Oct 1999 21:44:10 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA29089 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 21:44:08 -0400
Received: from someip.ppp.op.net (d-bm3-0b.ppp.op.net [209.152.194.75]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id VAA24049 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 21:39:23 -0400 (EDT)
Message-Id: <199910120139.VAA24049@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway 
In-reply-to: Your message of "Tue, 12 Oct 1999 01:16:28 +0200."
             <99101201455804.00526@localhost.localdomain> 
Date: Mon, 11 Oct 1999 21:39:02 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: a36e8d50d96069dfccc35ae555d25d58

>> i'm still working on optimizing the amount of data copying that goes
>> on in a net like the one above, but it all works just fine for
>> now. MIDI controllable control elements too :)
>
>VST uses the process() and processReplacing() plug-in calls as a
>part of that optimization. I suggest process() to be our replacing
>method, and process_mix() to add data to the output buffers. The big
>difference: process_mix() is *required* to support a linear gain
>parameter for each output channel.
>
>But, is the cost of clearing a buffer really significant these days,
>when some plug-ins can eat a whole P-II 400 using a single instance?

this is not the cost. 

specifically, i'm looking at a situation where i've got N channels of
interleaved data read from a soundcard, sitting in a buffer. a mixer
strip picks up 1 channel from this buffer, and mixes it into 1 channel
of the output buffer.

the simplest way to route input to output would be to have each node
in the processing net act like a proxy, and have it additively combine
the relevant (think interleaved) data from the input buffer with the
relevant (again think interleaved) data of the output buffer.

i say proxy because i'm talking about using function calls that hide
the additive combination. this prevents the node from seeing the data
that constitutes its input.

it can do this if the only thing to be done to the data is to scale it
(think volume and panning) - we just pass the scale factor into the
additive combine function.  In many common cases of mixing, this is
all we will be doing.

but even in the common cases, we'd like to know, for example, the RMS
level of a strip's input. if it only has the mix function, it has to
compute the RMS level of the output buffer beforehand, then recompute
it again after the mix. not good.

so, this is what i'm carefully considering how to avoid in a
multitrack mixer.

From - Tue Oct 12 01:09:27 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA01901
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 22:00:57 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA29104 for linux-audio-dev-list; Mon, 11 Oct 1999 21:46:37 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA29101 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 21:46:35 -0400
Received: from someip.ppp.op.net (d-bm3-0b.ppp.op.net [209.152.194.75]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id VAA24252 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 21:41:49 -0400 (EDT)
Message-Id: <199910120141.VAA24252@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] aRts, KDE - say it ain't so! [it ain't] 
In-reply-to: Your message of "Tue, 12 Oct 1999 00:54:59 BST."
             <380278D3.FA7AB2F0@skelleftea.mail.telia.com> 
Date: Mon, 11 Oct 1999 21:41:28 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 95e519c0e75dd0b7e9cb3a1159d29393

Thanks to Stefan and Roger for clarifying some aspects of the
relationship between aRts and KDE.

I want to make it very clear that the target of my criticism was not
Stefan or Roger, but the kind of people who write the breathless prose
that Eric forwarded, and promote that kind of thinking.

--p

From - Tue Oct 12 01:09:36 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA23242
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 00:58:55 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA29490 for linux-audio-dev-list; Tue, 12 Oct 1999 00:39:44 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA29482 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 00:39:40 -0400
Received: from localhost.localdomain (d212-151-86-72.swipnet.se [212.151.86.72]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id GAA11614; 
          Tue, 12 Oct 1999 06:34:53 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: David Slomin <dgslomin@CS.Princeton.EDU>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc.
Date: Tue, 12 Oct 1999 03:51:02 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <Pine.GSO.4.10.9910111447330.16696-100000@ux02.CS.Princeton.EDU>
In-Reply-To: <Pine.GSO.4.10.9910111447330.16696-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Message-Id: <9910120354050A.00526@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id GAA11614
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id AAA23242
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5aa91bc0b822f20946fa817616150564

On Mon, 11 Oct 1999, David Slomin wrote:
> Why does everybody like plugins so much?  What's wrong with small,
> coorperating, standalone apps?

Performance. Context switches are expensive and timewise
undeterministic, at least in non-hard real time systems...

But the MCS (is there going to be an official name this year!?) API
will be available in both forms, so don't worry. :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Oct 12 01:09:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA04708
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 22:18:35 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA29120 for linux-audio-dev-list; Mon, 11 Oct 1999 21:59:38 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA29117 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 21:59:36 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id VAA05452
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 21:53:48 -0400 (EDT)
Received: from localhost by ux02 (8.9.1b+Sun) id VAA21491; Mon, 11 Oct 1999 21:53:49 -0400 (EDT)
Date: Mon, 11 Oct 1999 21:53:49 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: LAD <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] full-duplex
In-Reply-To: <01BF1365.475A7B40@default>
Message-ID: <Pine.GSO.4.10.9910112142420.21413-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: bdd2ecb16617e79d53de9ed433dd116d

On Sun, 10 Oct 1999, Rafael Flister Monteiro wrote:

> I am a graduate student from Brazil and I am starting to work with
> sound programming under Linux. I would like to know if you could help
> me.  I have been having problems with full-duplex operation, I created
> two processes, the first reads 16 milliseconds of sound samples from
> de microphone and sends them to the second process using an UDP
> socket. The second process receives these samples and writes them on
> the soundcard.  I opened the device for reading and writing (O_RDWR),
> set the full-duplex option and set the fragment size (0x7fff0007). But
> I am not able to read and write the amount of data that I ask. What
> are the problems involved in full-duplex operation?

As has already been suggested, ALSA stands a much better chance than
OpenSound of allowing separate processes to simultaneously open /dev/dsp,
one for reading and one for writing.  However, if installing ALSA is not
an option for you (due to complexity of installation, lack of support for
your sound card, or lack of compatibility with other apps you care about),
there is a higher latency but still viable solution...

Write a little app that opens /dev/dsp for both reading and writing, then
forwards incoming and outgoing data to/from separate FIFOs (or sockets,
but FIFOs are easier to code and, more importantly, run faster).  The
FIFOs can then be opened by separate processes.  I've written a little
program called "rw" which does this for MIDI messages, but it could be
adapted for audio by enlarging the size of its internal buffers and
sending the proper ioctls at startup to initialize the driver (you can't
forward the ioctls blindly over the FIFOs, like you can with the actual
audio data).  Just ask, and I'll send you a copy.

Div.

From - Tue Oct 12 01:09:28 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA04526
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 22:17:23 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA29139 for linux-audio-dev-list; Mon, 11 Oct 1999 22:03:13 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA29136 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 22:03:10 -0400
Received: from someip.ppp.op.net (d-bm3-0b.ppp.op.net [209.152.194.75]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id VAA25447; Mon, 11 Oct 1999 21:58:22 -0400 (EDT)
Message-Id: <199910120158.VAA25447@renoir.op.net>
To: Stefan Westerfeld <stefan@space.twc.de>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] aRts, KDE - say it ain't so! 
In-reply-to: Your message of "Tue, 12 Oct 1999 00:50:31 +0200."
             <19991012005031.48125@space.twc.de> 
Date: Mon, 11 Oct 1999 21:58:02 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 6def814a3525f4ab83ff8213f7b9a087

>What is the OS? Putting it into the linux kernel, excluding every FreeBSD
>and Solaris user, and making plugin crashs take down the whole system?

if it *has* to go into the kernel, then sure, we end up excluding
FreeBSD and Solaris. but i think we all know that it doesn't need to,
and shouldn't be in the kernel. what most people mean by "the OS"
under Linux is both the kernel, a set of system calls, one or more
filesystems, and some basic programs. When you build programs that use
these capabilities and those of a programming language, I think its OK
to say that "its a {Linux|FreeBSD|POSIX} program". When you write
programs that require the presence of a myriad of other subsystems, I
think you have to say "its a {KDE|GNOME|CDE} program".

>Does the idea that there is an X11 server, offering graphics capabilities
>to almost any graphic linux application seriously fracture our community?
>Have you got an alternative plan for that? I mean: having an audio server
>engine is pretty much the same idea, just for audio.

sure. but basing the access to the audio engine on some KDE API is not
the same idea. it would be the same as saying that the way to access
the graphics engine is via Motif. actually, it would be worse, since
at least Motif has some explicit link with the graphics engine. For
KDE to try to take over the definition of a "universal" audio API for
applications is putting that API in the wrong place, IMHO. It belongs
at the same level as the X11 server, which is not part of KDE at all.

>For KDE2 we are working on things like KApplication::play to play a sample
>so that everybody can use it really easily. Or for instance KAudioStream
>which will about be the same as esd offers through their streaming
>record/play API, but easier to use for KDE users, since integrated with
>Qt signals&slots. 

this is an example of exactly what i'm worried about. instead of
pushing for an audio server that has the same status as X11, you're
going to end up encouraging people to write applications that use the
KDE audio server (presumably aRts from the sound of it). I think this
is a mistake.

although it has gotten lost in the technical details of the discussion
about the API, the whole purpose of the API we're talking about here
is to create a standard that applications can use whether they run
with KDE, GNOME, Xt, Motif, SVGAlib, text consoles, or whatever.  

sure, the KDE audio API can just be a convenient layer over something
else for KDE apps to use, but it steals possible momentum from a more
universal API (albeit one that we haven't even written yet :)))

--p

From - Tue Oct 12 01:09:31 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA05233
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 22:22:09 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA29159 for linux-audio-dev-list; Mon, 11 Oct 1999 22:07:16 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA29156 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 22:07:14 -0400
Received: from someip.ppp.op.net (d-bm3-0b.ppp.op.net [209.152.194.75]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id WAA26047; Mon, 11 Oct 1999 22:02:29 -0400 (EDT)
Message-Id: <199910120202.WAA26047@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: Re: [linux-audio-dev] full-duplex 
In-reply-to: Your message of "Mon, 11 Oct 1999 17:45:29 +0200."
             <99101117493300.00801@linuxhost.localdomain> 
Date: Mon, 11 Oct 1999 22:02:08 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 60977093af03730bf1e68e68372fb27b

   [ ... full duplex audio ... OSS ... ALSA ]

>But my Turtlebeach on my P133 with Tyan Tomcat motherboard (HX)
>locks up the kernel some times.
>( I tried 2.2.5 and 2.2.10 )
>
>Is this due to a hw problem of buggy mainboards (from the Audio-quality HOWTO
>:-) )  ?
>
>Is there a workaround for OSS/Free ?
>Does have ALSA the same problems ?

i have used ALSA in full duplex mode for very long periods, and it
never locks up my 2.2.10 kernel, or any other kernel i have tried it
with.

on the other hand, some time back, i thought i had done the same with
OSS and not had problems either, so i don't know where the problem
might be.

--p

From - Tue Oct 12 01:09:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA23347
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 01:00:10 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA29493 for linux-audio-dev-list; Tue, 12 Oct 1999 00:39:47 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA29489 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 00:39:44 -0400
Received: from localhost.localdomain (d212-151-86-72.swipnet.se [212.151.86.72]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id GAA11630; 
          Tue, 12 Oct 1999 06:34:54 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] big picture, for a moment
Date: Tue, 12 Oct 1999 04:13:24 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910112047.QAA29885@renoir.op.net>
In-Reply-To: <199910112047.QAA29885@renoir.op.net>
MIME-Version: 1.0
Message-Id: <9910120641440C.00526@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id GAA11630
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id BAA23347
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 049272950b737fb9f895cc6666493625

On Mon, 11 Oct 1999, Paul Barton-Davis wrote:
> I think we need to step up a level or two, and try to clarify the big
> picture again.

Yes, that's a good idea, I think... :-)

I also think that your description indicates that we're close to
getting a very nice design together. I don't agree fully with all
parts, but it seems rather close.

> >From my perspective, I am now agreed that we should use an event
> system similar to the one David has proposed. I agree that we should
> use a constant frame/sample count argument to plugins, and let them
> deal with events in any way they choose. I agree that we need 64bit
> timestamps. External event sources (MIDI, audio cards, mice,
> keyboards, X servers, etc.) will be handled by the semantic equivalent
> of "sensor threads" that are partly autonomous, and partly dependent
> on the engine thread.

I would like to add that it's also possible to make device drivers in
the form of plug-ins, which makes a lot of sense in the kernel. That
is, unless Jaroslav dislikes our API too much, the ALSA drivers could
gradually turn into plug-ins, running in a basic kernel implementation
of an MCS plug-in host. That would make it pretty easy for him to
move code around in the driver architecture, and even move parts to
user space if desired. Would that be a nice thing for the 3D sound
rendering and similar stuff, perhaps?

> I think that David agrees that we will not use
> shared memory directly to communicate with "clients" (other
> processes), but instead will use "sensor threads" that will make
> shared memory function like any other event source. Note: an
> implementation may or may not use actual threads to implement this,
> but the API will be defined so that threads *can* be used.

Yes, the power of a carefully designed API; inherent abstraction on
the binary level, so that the API implementation can do pretty much
what it wants without uggly workarounds.

> Where David and I currently disagree is the relationship between
> plugins and event ports. I think of a plugin that is introduced to the
> system coming into a world of many possible different event ports, and
> having a clear idea of the kinds of things it wants to pay attention
> to. Those may change as a result of user interaction, but I see the
> plugin as "subscribing" to various event ports, and unsubscribing at
> other times. Plugins may also be (un)subscribed to ports as a result
> of user interaction and/or automation playback. The engine provides a
> way to locate a port given its address, so that plugins can subscribe
> to its ports of interest. Objects that generate events have no idea
> who is subscribed to their ports. All events are timestamped using a
> time base maintained by the engine, but usable without having to
> preempt the engine thread (if it is indeed a distinct thread).

...while I view a plug-in as a black box with a number of inputs and
outputs, in the form of audio ports and event ports. The average
plug-in would have >=0 audio inputs, >=0 audio outputs, one event
input, and possibly one event output. During initialization, the
plug-in will tell the host what events it understands (little more
than info for the UI), and if it has an output port; what events it
might send through it. The plug-in doesn't care (or know) who listens
to it's output, nor does it know where the events it recieves come
from. _It processes events in the same manner as it processes audio;
as an input -> output black box._

In order to connect event ports in a useful way, the engine may
remap events (of compatible types), so that for example, a plug-in
sending "float #1" can be set up to control another plug-in that
listens to (among other things) "float #5". Of course, if "float #2"
is to be connected to "float #2", no remapping is needed! OTOH, if
"float #2" is to be sent to a third plug-in, the engine will start to
_reroute_ those events to the event port of that plug-in. Neither of
the plug-ins need to know anything about this; they just do their job.

The remapping can be carefully optimized in the inner workings of the
engine implementation for maximum performance, or handled by a basic
event router in the MCI "Engine Toolkit" library. As this is kept
entirely separate from the plug-in side of the API, it's even
possible to build special event filters and operators right into the
engine, so that users that want to handle ektreme event traffic can
do so with minimum overhead. (However, the normal and *flexible* way
of adding detailed event processing would be using event-only
plug-ins, much like some systems use special MIDI plug-ins.)

Finally: What about event routing overhead?

Well, compare that to the overhead involved when handling the number
of event ports needed to get the same flexibility.

Input from multiple senders:

 * The engine has to merge the events into one list,
   and they must be sorted according to the timestamps.

 * _ALL_ events that are output from every subscribed
   source must be merged in, as the engine doesn't
   know which ones the listening plug-in cares about.

 * Event remapping *still* has to be done, as events
   from multiple sources *may* collide otherwise.

 * The plug-in not only has to subscribe to ports to
   get events, it also has to keep track of how the
   "anti-collision" remapping affects the events it
   wants.

 * The alternative is to check multiple input ports,
   which would pretty much kill the event system's
   efficiency, and make the code quite complex.

Output to multiple destinations:

 * _ALL_ events will have to be copied to _ALL_
   destinaiton ports by the engine, as the sending
   plug-in has no idea who's listening to what. And
   neither does the engine...

 * The engine would have to remap all events, unless
   every destination has a dedicated port for the
   sending plug-in.

Well, my design has a few problems as well, of course... For example,
event remapping. But by structuring the event codes (32 bits in my
examples so far) in a sensible way should reduce that to one or two
levels of lookup tables in the optimized implementation. Perhaps
there are even better ways? I think we might find interesting
solutions in IP routers and similar systems. I bet there are
interesting parts of The Kernel to study!

Now, lets find the flaws in my version! :-)


> Next are some ideas that we have not talked about.
> -------------------------------------------------
> 
> I propose removing the engine from any involvement in event
> distribution. We can do this because event distribution does not
> involve data copying.

This is true for point-to-point connections, while subscribing to
multiple event sources put you in a network...

> The engine is responsible for setting up
> connections so that it can adequately grok the nets that the
> interconnections create.

Yes.

> But event sources simply post events to their
> ports, and the port subscribers process the events.  The engine is
> responsible for marking the last event on any given port that should
> be considered during a plugin's process() call.

Very handy... However, I wonder if it's really a win, performance
wise. How much does it cost the engine to put that end-of-cycle
marker in, compared to the plug-in checking the timestamps?

What I'm thinking about is that it's not necessarily true that there
are no events after the last one to be processed during the current
cycle. There may be events to be processed later on... This happens
when interfacing between sub nets with different buffer sizes, and
when communicating accross threads.

> It is also responsible
> for removing all events up to and including that last event at the
> appropriate time, and doing appropriate games in memory with them.

Yep. (Better make sure to grab as much info as possible whenever the
engine's close to the events, or there may be a lot of traversing
overhead.)

> Plugins and clients are different.

Yes, but slightly less different, IMO.

> A plugin in a precompiled object file which can be dynamically linked
> into any program that supports the engine-side of the API. A plugin
> can subscribe to any event port known to the engine, register new
> event ports, manage its own GUI (which will run in its own thread) and
> consider itself closely coupled to the engine.

As long as the GUI is also in its own *file*, OK. I can load ELF into
kernel space and similar weird places, but I don't feel like cleaning
out "irrelevant" code on the fly...

(See above re the subscription.)

> A client is a standalone program that uses the engine to route data,
> or routes data for the engine. Clients do not have access to ordinary
> event ports,

Why? That's *exactly* where the intermediate FIFO hidden behind the
shadow ports come in handy. If sensor threads can do it, so can
clients, *and*, it makes them a lot more similar to plug-ins. A
client is to MCS what a plug-in is to an engine... To some extent at
least; clients can do lots of cool stuff that plug-ins cannot.

> but instead receive data streams and/or requests for data
> from the engine.

How does it recieve requests, if not through an event port? Using the
client/server model proposed by Benno, a client behaves pretty much
like a plug-in - it just sleeps instead of returning to the host.

However, it might do other tricks as well, and it can even
completely drop out of the communication for a while - and then jump
back in when it has something to say. The cycle is flexible and
optional, as opposed to the plug-in case, but the concept is still
there. Why break it?

> To make this point clearer, if you write an audio
> sequencer as a *client* (i.e. it sends its audio data to an engine,
> not directly to an audio device) it cannot receive events (say, GUI
> changes or MIDI stuff) from the engine. If you write it as a *plugin*,
> then you can.

The engine *is* a client to the *MCS*, as I see it. Or, call it a
"local domain"; a performance optimized model of the MCS. Hang a
gateway onto the client interface, and your local processing is all
of a sudden *publicly* available to any MCS client with permissions!
Plug-ins in your engine can be connected to things in another engine
inside another application. THAT's my idea of integration.

> However, even if the client case, you can still use the MCS library to
> manage events within your own process space, and you can also host
> plugins that use the API. This is the "anyone can write an audio
> server" approach :) More significantly, by doing this, you can almost
> certainly conveniently package the functionality of your application
> in a format that can be a plugin.

Not using event ports as a natural part of the client API makes that
a bit harder, I think... But other that that; yes, this is the idea
with the uniform API. However, I want to be able to get that
*functionality* by hooking things up at run time as well. "Plug" an
application into another, without requiring an extra API layer. A
client adaptor plug-in could be used, in case that simplifies things.
BTW, hint: sensor threads...

> Likewise, you might write an application that routes audio over a
> network using some sensible protocol.

Yes, but why not passing along events as well? IMO, they're not very
different from audio data - or video data for that matter - on this
level.

> Individual users of the MCS system would need to decide if they
> preferred plugins or clients for certain purposes.

Yes, basically;
	speed & latency ==> plug-in
	incredible flexibility ==> client

> We have not talked about how to address ports. Strings are easy, but
> speed daemons will prefer integer values formed via some scheme that
> encodes the port's "name".

With my model, it would probably make sense with integer port
handles, and strings to initially look up ports. OTOH, reconfiguring
the event routing in a heavily optimized engine might be relativily
expensive... (IMO, changing the processing net - the event routing
included - in real time with guaranteed latency isn't such a high
priority, as it can't be done in the middle of a cycle anyway. But
why waste CPU time if it could be avoided?)

> However, the description I have given above, I think that this is an
> API that I can and would use for all my audio/MIDI programs. 

It's a nice design, but I accept no limitations! >;-D


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Oct 12 01:09:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA07883
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 22:40:59 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA29184 for linux-audio-dev-list; Mon, 11 Oct 1999 22:20:01 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA29181 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 22:19:59 -0400
Received: from someip.ppp.op.net (d-bm3-0b.ppp.op.net [209.152.194.75]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id WAA28064 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 22:15:14 -0400 (EDT)
Message-Id: <199910120215.WAA28064@renoir.op.net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] MCS: 64 bit timestamps? [simplified] 
In-reply-to: Your message of "Tue, 12 Oct 1999 02:19:18 BST."
             <38028C96.DBA0F98E@skelleftea.mail.telia.com> 
Date: Mon, 11 Oct 1999 22:14:53 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0fa5e0823841932dcf95a76f429749f5

>Suggestion:
> Treat the tsc as a sample-driven-unit by itself (started at cycle 0),
> but scale it to wrap in a week or so... for debug purposes
> SCALE should be a power of 2, 1 is ok!
>
>#define SCALE 1
>msc_time_t
>Engine::timestamp ()
>{
>        /* greatly un-inlined to make function clear ... */
>	return read_tsc() / SCALE;
>}

	[ ... other code elided ... ]

yes, this is simple and convenient, but it defers and multiples the
number of floating point computation that has to be done
elsewhere. why ? because we want events timestamped with sample
accuracy, and passing around the time in units that are not samples
forces each user of the timestamp to scale it to samples.

that is, your example:


msc_time_t
Plugin::convert (unsigned sample)
{
        return Engine::convert( sample / this->samples_per_second ) -
				       this->start_timestamp;
}
 
is actually the opposite of what most plugins would need to do:

sample_count_t
Plugin::convert (event_timestamp_t foo)

{
	... convert event timestamp to samples ...
}

because most of them will be using event timestamps.

right ?

--p

ps. i haven't seen any reports on cycle counters running at different
speeds - i thought that the Intel SMP spec didn't allow processors to
run at different speeds. i did see some reports on counters that are
skewed wrt each other. i believe someone figured out a way to resync
them.

From - Tue Oct 12 01:09:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA07958
	for <slinkp@ulster.net>; Mon, 11 Oct 1999 22:41:42 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA29194 for linux-audio-dev-list; Mon, 11 Oct 1999 22:27:37 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA29191 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 22:27:35 -0400
Received: from someip.ppp.op.net (d-bm3-0b.ppp.op.net [209.152.194.75]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id WAA29192 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 11 Oct 1999 22:22:50 -0400 (EDT)
Message-Id: <199910120222.WAA29192@renoir.op.net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] cycle counter wrapping
In-reply-to: Your message of "Tue, 12 Oct 1999 02:19:18 BST."
             <38028C96.DBA0F98E@skelleftea.mail.telia.com> 
Date: Mon, 11 Oct 1999 22:22:30 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 811ff361a93b8bdd21f4262eb953a1d2

>What happens when the cycle_diff starts to wrap :-)
>Ok, we have 2^64 bits, but wery soon we have 2^32 cycles/s CPUs.
>1 GHz next year, and increasing rapidly (typing on a 180 MHz PPro
>3 years old, assume 10 GHz in another 3 years, ...)

even if we assume 10GHz, the cycle counter won't wrap for 58 years.

	2^64 / 10^10 = 1844674407 seconds till wrap
	1844674407 / (3600 * 24 * 365) = 58 years till wrap

even Linux might not be up for that kind of uninterrupted uptime :)

also, Moore's Law is supposed to bottom out in 3 to 5 years due to
the fundamental physics of semiconductors.

--p

From - Tue Oct 12 01:48:05 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA26000
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 01:38:23 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id BAA03420 for linux-audio-dev-list; Tue, 12 Oct 1999 01:20:40 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA03417 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 01:20:36 -0400
Received: from localhost.localdomain (d212-151-100-234.swipnet.se [212.151.100.234]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id HAA00932; 
          Tue, 12 Oct 1999 07:15:46 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Roger Larsson <roger.larsson@skelleftea.mail.telia.com>
Subject: Re: [linux-audio-dev] API design again [MORE code]
Date: Tue, 12 Oct 1999 07:06:18 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
References: <199910101638.MAA10195@renoir.op.net> <99101021222707.00456@localhost.localdomain> <380273A9.73FA2B44@skelleftea.mail.telia.com>
In-Reply-To: <380273A9.73FA2B44@skelleftea.mail.telia.com>
MIME-Version: 1.0
Message-Id: <9910120722400E.00526@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id HAA00932
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id BAA26000
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: fb2dad6a7612f3d691efce505acf3cb1

On Tue, 12 Oct 1999, Roger Larsson wrote:
> Thumb rule for priority:
>   The shorter run the higher priority.
>   The longer run the lower priority.
>   Then the short run can interfere with the long but not the opposite.

Exactly. Add one rule for real time systems:
    Higher scheduling rate should have higher priority.

Without that one, the whole point with sceduling the higher rate task
for every external event is lost if the lower rate task delays the
higher rate task for a few wakes every now and then.

> But there are exceptions:
>   To avoid filling up processor queues it might be better to
>   run producer threads with lower prio. - consumer threads will
>   then be able to empty their input queues before new ones are
>   created.
>   This is not a good solution if you can not combine inputs, or
>   ignore some.
> 
>   Example:
>     suppose that engine threads have lower prio. than sensor threads.
>     and that each sensor tread is "connected" (1-1) to a plugin.
>     then data may build up, and overflow, on the input to the engine
>     by using more sensor threads than expected.

System overload ==> automatic engine shutdown. (To avoid hanging the
system, as the engine might well be running SCHED_FIFO.)

If the engine fails to handle incoming data because of the sensor
thread CPU load, it will also fail to do it's processing before the
deadline. That's a very severe error condition in a real time system,
and it makes no sense trying to handle it nicely. If a deadline is
missed, all is lost anyway...

>   With a fast engine, the jitter in time stamps might be worth it...

No. Almost by *definition*, the engine should work correctly until
the CPU is overloaded. That is, the engine thread may well be working
90% of the cycle time slice.

>   (Much time stamping will be done in kernel drivers anyway, or?)

That's the way I want it, anyway... Precision timestamping and
simulating missing hardware features is *not* a user space job.
However, as current drivers don't timestamp, that'll have to do for
now.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Oct 12 02:28:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id CAA27975
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 02:12:28 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id BAA03451 for linux-audio-dev-list; Tue, 12 Oct 1999 01:47:59 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA03448 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 01:47:56 -0400
Received: from localhost.localdomain (d212-151-100-234.swipnet.se [212.151.100.234]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id HAA15870; 
          Tue, 12 Oct 1999 07:43:09 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Roger Larsson <roger.larsson@skelleftea.mail.telia.com>
Subject: Re: [linux-audio-dev] MCS: 64 bit timestamps? [simplified]
Date: Tue, 12 Oct 1999 07:38:14 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
References: <199910110404.AAA17257@renoir.op.net> <38028C96.DBA0F98E@skelleftea.mail.telia.com>
In-Reply-To: <38028C96.DBA0F98E@skelleftea.mail.telia.com>
MIME-Version: 1.0
Message-Id: <9910120750040G.00526@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id HAA15870
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id CAA27975
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 28cadce7eb4558f02b9985d7103dd112

On Tue, 12 Oct 1999, Roger Larsson wrote:
> >         tsc_t current_cycle_counter;
> >         tsc_t cycle_diff;
> >         msc_time_t now;
> > 
> >         current_cycle_counter = read_tsc ();
> >         cycle_diff = current_cycle_counter -
> >                      cycle_counter_at_start_of_control_loop;
> 
> What happens when the cycle_diff starts to wrap :-)

As long as we make sure to use the right data types, the wrapping
will magically disappear from the result! Ever programmed Amiga mice
or other quadrature encoders with hardware counters? :-)

> What 'samples_per_cycle' the requesting plugins, or a master, or ...

The timing master audio card. That is, the one that the engine is
synchronized to.

> Do we really like to have float calculations here? At least we should
> make it double to handle the 64 bit cycle_diff.

Clever integer manipulation works fine as well. However, it's easier
to do in asm than in C...

> Note: this is not SMP safe if people uses processors with
> different speeds... some are...

Hmm... *S*MP is not the correct term in that case. :-)

Anyway, that's why the OS should provide wrappers for this kind of
things.

> And I think there have been some issues with unsynchronised
> cycle counters...

If both CPUs are clocked from the same osc, it shouldn't be a
problem. Unless it's caused by a flawed APM implementation or
something. (Lowering the clock frequency when sleeping...)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Oct 12 02:28:12 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id CAA28158
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 02:15:48 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id BAA03458 for linux-audio-dev-list; Tue, 12 Oct 1999 01:55:39 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA03455 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 01:55:36 -0400
Received: from localhost.localdomain (d212-151-100-234.swipnet.se [212.151.100.234]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id HAA15593; 
          Tue, 12 Oct 1999 07:50:49 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: David Slomin <dgslomin@CS.Princeton.EDU>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc.
Date: Tue, 12 Oct 1999 07:50:56 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <Pine.GSO.4.10.9910112117400.19759-100000@ux02.CS.Princeton.EDU>
In-Reply-To: <Pine.GSO.4.10.9910112117400.19759-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Message-Id: <9910120757390H.00526@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id HAA15593
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id CAA28158
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e8601ace1d60484635d9ca32ead64766

On Tue, 12 Oct 1999, David Slomin wrote:
> to an app, it's certainly not limited to the 3.2 kbaud (did I remember

<mode nitpick=on>
31250 Hz bit rate. And then you have a start bit and a stop bit as
well, so it's even below 31.25k! ;-)
</mode>

> True, you get an automatic 1/8 performance hit (sysex only gives you 
> seven bits), but it's nowhere's near as ugly a picture as you painted.

Hmm... Who reorganizes the data bits then? Twice, for that matter!
That's the *really* uggly part of SysEx programming...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Oct 12 03:15:03 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id DAA30539
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 03:02:37 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id CAA03552 for linux-audio-dev-list; Tue, 12 Oct 1999 02:45:04 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA03549 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 02:45:01 -0400
Received: from localhost.localdomain (d212-151-100-234.swipnet.se [212.151.100.234]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id IAA04027; 
          Tue, 12 Oct 1999 08:40:12 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway
Date: Tue, 12 Oct 1999 08:00:49 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910120139.VAA24049@renoir.op.net>
In-Reply-To: <199910120139.VAA24049@renoir.op.net>
MIME-Version: 1.0
Message-Id: <9910120847070K.00526@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id IAA04027
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id DAA30539
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: aa3a73f57add8db6a4757ad8c01e6726

On Tue, 12 Oct 1999, Paul Barton-Davis wrote:
> specifically, i'm looking at a situation where i've got N channels of
> interleaved data read from a soundcard, sitting in a buffer. a mixer
> strip picks up 1 channel from this buffer, and mixes it into 1 channel
> of the output buffer.

The nice little data format problem again...

> the simplest way to route input to output would be to have each node
> in the processing net act like a proxy, and have it additively combine
> the relevant (think interleaved) data from the input buffer with the
> relevant (again think interleaved) data of the output buffer.
> 
> i say proxy because i'm talking about using function calls that hide
> the additive combination. this prevents the node from seeing the data
> that constitutes its input.

Not quite following... Matrix operations? Anyway, why not inline
macros or functions, if it's "just" a matter of interleaved samples?

> but even in the common cases, we'd like to know, for example, the RMS
> level of a strip's input. if it only has the mix function, it has to
> compute the RMS level of the output buffer beforehand, then recompute
> it again after the mix.

No. Just simulate the replacing version as usual - using a separate
buffer that you clear before you call process_mix(). (The same buffer
can be reused a whole lot, as it's contents are not needed anymore
after the last reader has accessed it during the current cycle.)

However, it *does* mean that you need to do the *actual* mixing using
the standard, built-in mixer "plug-in"... So the replacing process()
function makes a lot of sense after all, in cases where you want to
connect an output to multiple inputs.

So, replacing process() is in. process_mix() is still little more
than a low level, DSP code performance hack. Now, is *that* version
actually useful, or does it just mean extra code?

BTW, buffers and the cache: Use a LIFO stack as a heap of buffers.
balloc() (*hehe*) picks the top one, and bfree() puts one back. That
way, balloc() will in most cases give you a buffer that has been used
not long ago.

> so, this is what i'm carefully considering how to avoid in a
> multitrack mixer.

That's a bit hard without building the VU (or whatever) into the
plug-in... Careful combination of standard functions into a set of
basic plug-ins is the most efficient way I can think of right now.
But that doesn't help much if you hit this problem directly after
some alien plug-in.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Oct 12 03:08:10 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id CAA30331
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 02:58:54 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id CAA03537 for linux-audio-dev-list; Tue, 12 Oct 1999 02:40:13 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA03533 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 02:40:10 -0400
Received: from localhost.localdomain (d212-151-100-234.swipnet.se [212.151.100.234]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id IAA12708; 
          Tue, 12 Oct 1999 08:35:21 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] MCS: 64 bit timestamps? [simplified]
Date: Tue, 12 Oct 1999 08:33:31 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910120215.WAA28064@renoir.op.net>
In-Reply-To: <199910120215.WAA28064@renoir.op.net>
MIME-Version: 1.0
Message-Id: <9910120842150I.00526@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id IAA12708
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id CAA30331
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 38b428cfb14aaa557bbaf010db60b586

On Tue, 12 Oct 1999, Paul Barton-Davis wrote:
> ps. i haven't seen any reports on cycle counters running at different
> speeds - i thought that the Intel SMP spec didn't allow processors to
> run at different speeds. i did see some reports on counters that are
> skewed wrt each other. i believe someone figured out a way to resync
> them.

It's actually possible to run CPUs with different core clocks
together, as long as they run at the same *bus* clock, and it doesn't
make the chipset or something else freak out. (Which is the case on
some, but not all SMP boards, obviously.)

BTW, the scheduler will probably have some trouble doing a good
job on such a machine... Some parts of the goodness() calculation
(used to find the best thread to switch to) depend on the thread's
CPU usage, IIRC. Probably not noticeable unless the difference is
very big, though.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Oct 12 03:08:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id CAA30316
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 02:58:31 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id CAA03544 for linux-audio-dev-list; Tue, 12 Oct 1999 02:43:23 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA03541 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 02:43:20 -0400
Received: from localhost.localdomain (d212-151-100-234.swipnet.se [212.151.100.234]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id IAA10579; 
          Tue, 12 Oct 1999 08:38:32 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] cycle counter wrapping
Date: Tue, 12 Oct 1999 08:42:55 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910120222.WAA29192@renoir.op.net>
In-Reply-To: <199910120222.WAA29192@renoir.op.net>
MIME-Version: 1.0
Message-Id: <9910120845260J.00526@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id IAA10579
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id CAA30316
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ea2ad3a73b10c583c72737f323619677

On Tue, 12 Oct 1999, Paul Barton-Davis wrote:
> also, Moore's Law is supposed to bottom out in 3 to 5 years due to
> the fundamental physics of semiconductors.

What about optical cirquits then? :-) Any recent news? (I heard quite
a while ago they had some setup that allowed light to directly
modulatate light...)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Oct 12 03:38:08 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id DAA31690
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 03:23:42 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id DAA03600 for linux-audio-dev-list; Tue, 12 Oct 1999 03:06:57 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA03597 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 03:06:55 -0400
Received: from ulster.net (port40.ts2.ulster.net [208.242.164.40])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id DAA30502;
	Tue, 12 Oct 1999 03:02:08 -0400
Message-ID: <3802DE3F.7DFA5F23@ulster.net>
Date: Tue, 12 Oct 1999 03:07:43 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Benno Senoner <sbenno@gardena.net>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] full-duplex
References: <199910110508.BAA20057@renoir.op.net> <99101117493300.00801@linuxhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f3281ef05309b557bfa87225b34c3a16

Benno Senoner wrote:
> But my Turtlebeach on my P133 with Tyan Tomcat motherboard (HX)
> locks up the kernel some times.
> ( I tried 2.2.5 and 2.2.10 )
> 
> Is this due to a hw problem of buggy mainboards (from the Audio-quality HOWTO
> :-) )  ?

It certainly could be. The A-Q-HT has all information I have about
this subject. If you solve your problem or learn more, please send
info to me so I can include it!

I had frequent full-duplex lockups on my intel-mobo system until
some revision number of OSS-Linux when they announced a workaround;
not a single lockup since then.
 
> Is there a workaround for OSS/Free ?

No idea.

> Does have ALSA the same problems ?

At the time I had my problems, it was said on the ALSA mailing list
that nobody had any docs on how to fix the problem. Maybe they've
found some since then, maybe not. I haven't used ALSA lately (though
I will eventually come around to it again).
 
> thanks for infos.
> 
> regards,
> Benno.

-- 

----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.

zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
http://www.ulster.net/~abigoo/
======================================================

From - Wed Oct 13 01:09:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA03475
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 10:31:48 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA04342 for linux-audio-dev-list; Tue, 12 Oct 1999 09:52:42 -0400
Received: from sculpcave (ppp-12.wakkanet.fi [194.157.35.220]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA04333 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 09:52:34 -0400
Received: from localhost (localhost [127.0.0.1])
	by sculpcave (Postfix) with ESMTP
	id 8484034D42; Tue, 12 Oct 1999 15:03:49 +0300 (EEST)
Date: Tue, 12 Oct 1999 15:03:49 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
X-Sender: root@sculpcave.localdomain
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] plugin questions
In-Reply-To: <99101200144700.00526@localhost.localdomain>
Message-ID: <Pine.LNX.4.10.9910121424340.1086-100000@sculpcave.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 61a1c64b096f3697adf8b03e9591b92f

On Mon, 11 Oct 1999, David Olofson wrote:

>> We could decide to accept string parameters only when initializing 
>> plugins. If you need to change a string value, you'd just 
> The event system supports dynamic size events - so there's no need to
> treat strings as a special cases for that reason. View the event
> system (and actually the whole MCS) as a slightly specialized RT-IPC
> toolkit; no MIDI-style event specific crap. What we're after when we

How is this actually done in practice? If I know what kind of events 
some plugin accepts, constructing and sending them will be easy.
What is still unclear to me is  how do I get the type-info? I imagine 
that creating a usable API for this won't be easy.  

A few thoughts...

- how do we limit what kind of information plugin can ask?
  	- booleans, floats (values between [0.0,1.0]), text, 
          sample rate, compression ratio (= difficult to represent 
	  with [0.0,1.0] floats), etc
  	- should we make a difference between realtime-controllable 
	  (filter cutoff) and rt-uncontrollable (channel count, 
	  sample rate) parameters
	- should plugin provide info about valid parameter
	  values (min-max isn't always enough)
	- what if plugin asks for 1024 bytes of floats and says 
          it represents a volume envelope -> no way to create 
          a generic UI for this (not necessarily a problem, but it
          should made be clear whether these are accepted or not)
	- or should we just decide on all these and force all 
	  plugins to use standard types and value ranges ... 
	  although this can quickly get out of hands

... and so on.

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav
 . http://www.wakkanet.fi/kerttulin_listat/ - music&movies (in Finnish)

From - Wed Oct 13 01:09:31 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA03016
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 10:28:36 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA04344 for linux-audio-dev-list; Tue, 12 Oct 1999 09:52:43 -0400
Received: from sculpcave (ppp-12.wakkanet.fi [194.157.35.220]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA04332 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 09:52:33 -0400
Received: from localhost (localhost [127.0.0.1])
	by sculpcave (Postfix) with ESMTP
	id 4B4B134D43; Tue, 12 Oct 1999 16:08:53 +0300 (EEST)
Date: Tue, 12 Oct 1999 16:08:53 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
X-Sender: root@sculpcave.localdomain
To: David Slomin <dgslomin@CS.Princeton.EDU>
Cc: LAD <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] linux audio apps/authors behind open-plugin-whatever
In-Reply-To: <Pine.GSO.4.10.9910111839340.19759-100000@ux02.CS.Princeton.EDU>
Message-ID: <Pine.LNX.4.10.9910121545410.1086-100000@sculpcave.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5070e41d131aeb4ec2676ed1dd8b0710

On Mon, 11 Oct 1999, David Slomin wrote:

>> No answer, so let's ask again...
> Umm, I didn't hear the question, so I'll throw out answers to all the
> likely ones.  :-)

Well, that's even better! ;) Seriously, I just wanted to find out who
are behind this project. If we could get all major linux audio apps behind
this, it would...
	a) speed up the development as we'd have more people working on
	   it and sharing their knowledge
        b) add motivation as we could be sure that this API is really 
           going to be used

For instance, if aRts is going to be the KDE2-audio server, it's IMHO 
important that we could get aRts to join our project. KDE is really going
strong and its importance (whether we like it or not) shouldn't be 
underestimated. Stefan, what do you think about this? 

Another imporant app is Xmms. If I've understood correctly, it's
currently the most well-known linux audio app. ... hhm, what did I 
forget... oh, of course Mix!

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav


From - Wed Oct 13 01:09:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA03213
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 10:30:01 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA04347 for linux-audio-dev-list; Tue, 12 Oct 1999 09:52:45 -0400
Received: from sculpcave (ppp-12.wakkanet.fi [194.157.35.220]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA04335 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 09:52:34 -0400
Received: from localhost (localhost [127.0.0.1])
	by sculpcave (Postfix) with ESMTP
	id 9533234D44; Tue, 12 Oct 1999 16:38:10 +0300 (EEST)
Date: Tue, 12 Oct 1999 16:38:10 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
X-Sender: root@sculpcave.localdomain
To: Paul Barton-Davis <pbd@Op.Net>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway 
In-Reply-To: <199910111645.MAA04412@renoir.op.net>
Message-ID: <Pine.LNX.4.10.9910121611370.1086-100000@sculpcave.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ea39faf1747681b55c38ccb01b2b57f6

On Mon, 11 Oct 1999, Paul Barton-Davis wrote:

>>multichannel sound, but when I look around my home studio, all my
>>equipment is designed to work with stereo signals (mixers, effect
> actually, in my studio, i don't have this perspective. my mixer, for
> example, can clearly handle mono signals quite well, and i use it for
> quite a few: the mono inputs sources: mic, prophet-5, matrix-6
> synth. 

Actually I was thinking about mono-stereo vs. multichannel setups. 
Currently most studio gear is designed to handle stereo-data 
(controls for left-right panning etc.).

> them how helpful it was to be able to use a stereo input signal on a
> single strip. the verdict: as long as you can group (sync) the faders
> for two strips, they didn't care, even when i pointed out that it
[...]
> i think it depends in part on what your inputs are. if they really are
> stereo signals (stereo soundfiles, devices etc.), then having audio
> default to stereo is a good choice. if they are mostly mono (mono
> soundfiles, devices, mics, etc), which is often true in live
> recording, then it can be a bad choice, computationally.

Yes, both have problems. Using mono-signals is more flexible and
allows more efficient implementation, but in some cases it makes 
handling stereo-signals too complicated. For instance, I don't 
want my engine to know about the data it is routing. It mix streams
of audio from inputs to chains, applies chain operators and mixes to 
outputs. If I'd start to use mono-signals, I'd have to separate mono 
and multichannel effects and add support for channel routing. And
what's even worse, it would complicate user-interface as users would 
have to specify what tracks are logically related.

> sometimes, you want an effect to just be applied to a single input,
> and then you'd do it on the strip:
> 			                   
> 			           +-->    BUS2 ->  FX3 -> FX4 -> OUT1
>                                    |                            
>     IN1  -> STRIP1  -> FX1 -> PAN -+
>     			           |
> 			           |
> 			           +-->  
> 			                   BUS2 ->  FX5 -> FX6 -> OUT2

... why stop here? :) I've been playing around with the idea of 
connecting chains to each other.. This way I could easily simulate 
strip-bus combination or go even further... 

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav


From - Wed Oct 13 01:09:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA02827
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 10:27:08 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA04343 for linux-audio-dev-list; Tue, 12 Oct 1999 09:52:42 -0400
Received: from sculpcave (ppp-12.wakkanet.fi [194.157.35.220]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA04334 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 09:52:34 -0400
Received: from localhost (localhost [127.0.0.1])
	by sculpcave (Postfix) with ESMTP
	id 0E6EA34D45; Tue, 12 Oct 1999 16:42:50 +0300 (EEST)
Date: Tue, 12 Oct 1999 16:42:49 +0300 (EEST)
From: Kai Vehmanen <kaiv@wakkanet.fi>
X-Sender: root@sculpcave.localdomain
To: David Olofson <audiality@swipnet.se>
Cc: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway
In-Reply-To: <99101201455804.00526@localhost.localdomain>
Message-ID: <Pine.LNX.4.10.9910121640520.1086-100000@sculpcave.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 049a8d01171ff41138565749a109859a

On Tue, 12 Oct 1999, David Olofson wrote:

> VST uses the process() and processReplacing() plug-in calls as a
> part of that optimization. I suggest process() to be our replacing

Hmm, most plugin/effect designs seem to be based on copying from 
input buffer, processing and writing to output. I've always 
done processing in-place (effects get a pointer to the sample data). 
Am I missing something here? 

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav

From - Wed Oct 13 01:09:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA19567
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 12:17:59 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA04672 for linux-audio-dev-list; Tue, 12 Oct 1999 11:21:03 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA04669 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 11:21:00 -0400
Received: from someip.ppp.op.net (d-bm3-02.ppp.op.net [209.152.194.66]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id LAA03973 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 11:16:12 -0400 (EDT)
Message-Id: <199910121516.LAA03973@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway 
In-reply-to: Your message of "Tue, 12 Oct 1999 16:42:49 +0300."
             <Pine.LNX.4.10.9910121640520.1086-100000@sculpcave.localdomain> 
Date: Tue, 12 Oct 1999 11:15:59 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ca72302f5cd0f6e0231be81926e74183

>Hmm, most plugin/effect designs seem to be based on copying from 
>input buffer, processing and writing to output. I've always 
>done processing in-place (effects get a pointer to the sample data). 
>Am I missing something here? 

if the plugin/effect can do simple pointer walks through its input
buffer, then what you describe will always work. but if the original
data source has interleaved channels (as many do!), and the plugin is
only working one channel, then you either have to (1) first copy the
channel data into a single non-interleaved buffer or (2) provide a
special function that understands how to walk through the interleaved
buffer or (3) make the plugin understand that.

these all have their costs. (1) implies a data copy (2) prevents the
plugin/effect from looking directly at its input data which prevents
certain things from being done and (3) seems like poor, though not
unworkable design.

so for me, the choice is between (1) and (3). In (3), we'd pass a
"pointer increment" argument to the plugin, telling it how far its
data pointer should increment each time it is moved in order to stay
in the right channel. Then it can do:

   for (ptr = input_buffer; ptr < input_buffer_end; ptr += pointer_increment) {
	      ... process *ptr ...
   }	    

this avoids the data copy.

on the other hand, since its likely that the input data will not be in
the right format (e.g. we want to use 32 bit floating point, and the
data arrives as 16 bit integers), we normally *have* to do one data
"copy" anyway (of course, it isn't a copy per se).

so it may all come out in the wash ...

--p



--p

From - Wed Oct 13 01:09:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA16689
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 11:58:21 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA04699 for linux-audio-dev-list; Tue, 12 Oct 1999 11:27:36 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA04696 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 11:27:32 -0400
Received: from someip.ppp.op.net (d-bm3-02.ppp.op.net [209.152.194.66]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id LAA04637 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 11:22:44 -0400 (EDT)
Message-Id: <199910121522.LAA04637@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway 
In-reply-to: Your message of "Tue, 12 Oct 1999 16:38:10 +0300."
             <Pine.LNX.4.10.9910121611370.1086-100000@sculpcave.localdomain> 
Date: Tue, 12 Oct 1999 11:22:32 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b80b8de3b07d350a418bbc7deb37e56c

>Actually I was thinking about mono-stereo vs. multichannel setups. 
>Currently most studio gear is designed to handle stereo-data 
>(controls for left-right panning etc.).

yes. and this is going to look very old fashioned in a very short
time as computer-based (read: unlimited by conventional h/w
constraints) solutions become more prevalent. nuendo is a clear
demonstration of that.

>... why stop here? :) I've been playing around with the idea of 
>connecting chains to each other.. This way I could easily simulate 
>strip-bus combination or go even further... 

on lesson i've learned in 13 years of programming is not to push for
too much abstraction at the expense of usability. juhana has certainly
talked and written and coded some interesting stuff about arbitrary
processing nets, and David's proposed engine does some of the same
stuff.

but i'm trying to write a highly useful mixer that will be mostly
finished (except for FX, which will be plugins using our new API, or
something approximating what it might be) by the end of this
week. when i was at AES, it was striking to me how excited people were
by "special purpose" hardware. yes, it would be nice if every audio
processing/generation program was capable of establishing any possible
internal processing net. but i want a mixer right now :) so i'll
settle for something that provides more flexibility that any current
hardware mixer, and will accept plugins for EQ, FX and panning. yes, i
can't create loops in the internal routing, but hey, i can live with
that :)

--regards
--p

From - Wed Oct 13 01:09:37 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA18927
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 12:13:45 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA04726 for linux-audio-dev-list; Tue, 12 Oct 1999 11:35:44 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA04723 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 11:35:42 -0400
Received: from someip.ppp.op.net (d-bm3-02.ppp.op.net [209.152.194.66]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id LAA05470 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 11:30:55 -0400 (EDT)
Message-Id: <199910121530.LAA05470@renoir.op.net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] cycle counter wrapping 
In-reply-to: Your message of "Tue, 12 Oct 1999 08:42:55 +0200."
             <9910120845260J.00526@localhost.localdomain> 
Date: Tue, 12 Oct 1999 11:30:42 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: bed8e78cdcbcac270e36e38fc59f1a10

>What about optical cirquits then? :-) Any recent news? (I heard quite
>a while ago they had some setup that allowed light to directly
>modulatate light...)

yep. but the best verdict on optical computing that i've heard is that
it will be like supersonic flight: ie. it works, we know how to do it,
but it will cost so much that only the very rich and the military will
use it. the rest of us get by pretty well with subsonic flight. the
person who made this comment also pointed out that today's passenger
aircraft actually fly a little *slower* than those that were around
before the sound barrier was broken ...

From - Wed Oct 13 01:09:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA25931
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 13:01:36 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA04819 for linux-audio-dev-list; Tue, 12 Oct 1999 12:23:20 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA04816 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 12:23:17 -0400
Received: from someip.ppp.op.net (d-bm3-02.ppp.op.net [209.152.194.66]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id MAA10597 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 12:18:25 -0400 (EDT)
Message-Id: <199910121618.MAA10597@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] big picture, for a moment 
In-reply-to: Your message of "Tue, 12 Oct 1999 04:13:24 +0200."
             <9910120641440C.00526@localhost.localdomain> 
Date: Tue, 12 Oct 1999 12:18:13 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f8048a291e2113af9e1ab0bf8c20c033

Getting closer ...

>...while I view a plug-in as a black box with a number of inputs and
>outputs, in the form of audio ports and event ports. The average
>plug-in would have >=0 audio inputs, >=0 audio outputs, one event
>input, and possibly one event output. During initialization, the
>plug-in will tell the host what events it understands (little more
>than info for the UI), and if it has an output port; what events it
>might send through it. 
			
=======================================================================
>			The plug-in doesn't care (or know) who listens
>to it's output, nor does it know where the events it recieves come
>from. 
=======================================================================

we both absolutely agree on this key point.

i think that our difference is small here. i look at the address of a
port as being a statement about the events the port will "send". if
you make this concession for a moment, i think you'll find we're
saying something very similar. the plugin tells the engine what it
understands. you say that it says "i understand float #5", whereas in
my view, its says "i understand midi cc 34". the only difference here
is what the semantics of an address are, for perhaps float 5 *is* midi
cc 34 ! in both cases, the engine will subscribe the plugin to a
particular port, right ?

more precisely, i think that event ports should be able to declare
themselves more strongly typed than you are thinking. a plugin's
output port might not be very strongly typed, but the MIDI sensor
thread, for example, might declare many different ports each of which
would *only* ever contain events connected to the ports
"name/address". 

why does this matter ? imagine a plugin that is a MIDI data
viewer. it says "i understand raw MIDI data". another plugin says "i
understand float #5". another says "i understand MIDI CC 34". 

you do *not* want to hook all these plugins up to a single port from
the MIDI sensor thread. instead, the first plugin gets connected to
the rawMIDI port, the second to some time-dependent port that happens
to be synonymous with "float #5" for now, and the third to a port that
contains messages about changes to MIDI CC 34.

this will cut down a lot on the amount of iterating over meaningless
events that plugins have to do.

essentially, i want *more* flexibility than you in that i want event
sources to be able to *restrict* the engine's view of the kinds of
events that will be posted to their port(s). 

most plugins might only declare a single port, but others might
declare many ports. consider a plugin that provided a GUI for a mixing
console (its on my mind:). instead of mux-ing all the events for
parameters for every strip into a single port, it would declare N
ports, one for each strip. Then the plugins that were implementing
strip-level FX/EQ would just be subscribed to that port, not a port
that would contain a bunch of events they didn't care about at all.

in essence, i imagine a heterarchy of ports, some completely generic,
some totally specific: "this port posts byte events describing the
state of the I-Cube tap sensor". 

any "input port" (really, just a pointer to a port, since there is no
data copying) that could handle byte data could be connected to this
port, but in addition, a plugin that listed a set of possible sources
for its displays could show "I-Cube tap sensor", and connect directly
to that port.

and imagine being able to dynamically describe all the ports in the
system:

	Port Description     Data Type			Source
        --------------------------------------------------------
	#13 generic	     float			pluginNN
	I-Cube tap sensor    byte			pluginNM
	#14 generic          string                     pluginXX
	#15 pluginNN_t       struct          		pluginNN
        #16 audio            audio                      sensor4
	MIDI CC 34           byte			sensor5

and so on. I regard this as equally generic as your system, but also
potentially much more efficient. What do you think ?

A last comment on this. None of the above is supposed to change the
basic notion that event sources have no idea who is listening, and
event receivers have no idea of the event source. From a plugin's
perspective all that matters is the *address* of a port, which also
tells us something about its usefulness to the plugin. The plugin, in
subscribing to port XXXXX has no idea where events on that port come
from. 

>Well, compare that to the overhead involved when handling the number
>of event ports needed to get the same flexibility.
>
>Input from multiple senders:
>
> * The engine has to merge the events into one list,
>   and they must be sorted according to the timestamps.

yes, but what is the problem with that ? 

the plugin process() call looks like:

     /* build a Lisp-like sorted list of all events on each
        subscribed port that occured before the current deadline.

	*NOTE* NO DATA COPYING: the list is just a set of pointers
	       to the event_t's still in the ports event lists.
      */

     mcs_build_event_list (&plugin->ev_list, &plugin->ports);
     plugin->process (..., event_list_t *events, ...) 

>Output to multiple destinations:
>
> * _ALL_ events will have to be copied to _ALL_
>   destinaiton ports by the engine, as the sending
>   plug-in has no idea who's listening to what. And
>   neither does the engine...

no. events are never copied at all. they exist on a port's event
list. things that listen to the port will find them there.

>Now, lets find the flaws in my version! :-)

since mine is simpler, mine first :)

>This is true for point-to-point connections, while subscribing to
>multiple event sources put you in a network...

not if you accept that plugins receive events from multiple ports.

>Very handy... However, I wonder if it's really a win, performance
>wise. How much does it cost the engine to put that end-of-cycle
>marker in, compared to the plug-in checking the timestamps?

right, its not necessary, now that we have timestamping worked out. 

>What I'm thinking about is that it's not necessarily true that there
>are no events after the last one to be processed during the current
>cycle. There may be events to be processed later on... This happens
>when interfacing between sub nets with different buffer sizes, and
>when communicating accross threads.

leaving aside the subnets with different buffer sizes, i thought that
the whole point of the design here was something like this:

events arrive during one pass through the plugins' process()
functions. they are timestamped with the sample on which they
occured. during the next pass through the plugins, the plugins get to
process the events, because the sample timestamps will correspond to
samples they will generate/process during that or a later call to
process(). 

>As long as the GUI is also in its own *file*, OK. I can load ELF into
>kernel space and similar weird places, but I don't feel like cleaning
>out "irrelevant" code on the fly...

sounds fine.

>Why? That's *exactly* where the intermediate FIFO hidden behind the
>shadow ports come in handy. If sensor threads can do it, so can
>clients, *and*, it makes them a lot more similar to plug-ins. A
>client is to MCS what a plug-in is to an engine... To some extent at
>least; clients can do lots of cool stuff that plug-ins cannot.

fine. its more complex, and it will involve more overhead on both
sides of the communication link, but fine. i don't buy any of this
shadow port stuff - i think its a totally unnecessary concept. i think
that ports should just be event FIFO's: posted to by event sources,
read from by port subscribers, and cleaned out by the engine. 

--p



From - Wed Oct 13 01:09:44 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA12532
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 15:05:22 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA05054 for linux-audio-dev-list; Tue, 12 Oct 1999 14:31:32 -0400
Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA05051 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 14:31:29 -0400
Received: from d1o43.telia.com (d1o43.telia.com [194.22.195.241])
	by mailc.telia.com (8.9.3/8.9.3) with ESMTP id UAA27706
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 20:26:41 +0200 (CEST)
Received: from skelleftea.mail.telia.com (t7o43p33.telia.com [194.237.168.153])
	by d1o43.telia.com (8.8.8/8.8.5) with ESMTP id UAA20308
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 20:26:39 +0200 (CEST)
Message-ID: <38038799.8520AA20@skelleftea.mail.telia.com>
Date: Tue, 12 Oct 1999 20:10:17 +0100
From: Roger Larsson <roger.larsson@skelleftea.mail.telia.com>
X-Mailer: Mozilla 4.6 [en] (Win95; I)
X-Accept-Language: sv,en
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] aRts, KDE - say it ain't so! [it ain't]
References: <199910120141.VAA24252@renoir.op.net>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by mailc.telia.com id UAA27706
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id PAA12532
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2c12cb86fa077c590fb76a839a75454f



Paul Barton-Davis wrote:
> 
> Thanks to Stefan and Roger for clarifying some aspects of the
> relationship between aRts and KDE.
> 
> I want to make it very clear that the target of my criticism was not
> Stefan or Roger, but the kind of people who write the breathless prose
> that Eric forwarded, and promote that kind of thinking.
> 

Just a clarification, I have not written a line of aRts code.
I am just another impressed person...

/RogerL

-- 

The Internet interprets Windows as damage, 
             and routes around it.

Roger Larsson
Skellefte
Sweden

From - Wed Oct 13 01:09:45 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA12675
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 15:06:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA05069 for linux-audio-dev-list; Tue, 12 Oct 1999 14:41:11 -0400
Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA05066 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 14:41:07 -0400
Received: from d1o43.telia.com (d1o43.telia.com [194.22.195.241])
	by mailc.telia.com (8.9.3/8.9.3) with ESMTP id UAA03030
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 20:36:20 +0200 (CEST)
Received: from skelleftea.mail.telia.com (t7o43p33.telia.com [194.237.168.153])
	by d1o43.telia.com (8.8.8/8.8.5) with ESMTP id UAA24234
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 20:36:19 +0200 (CEST)
Message-ID: <380389DD.FD6E4738@skelleftea.mail.telia.com>
Date: Tue, 12 Oct 1999 20:19:57 +0100
From: Roger Larsson <roger.larsson@skelleftea.mail.telia.com>
X-Mailer: Mozilla 4.6 [en] (Win95; I)
X-Accept-Language: sv,en
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] cycle counter wrapping
References: <199910120222.WAA29192@renoir.op.net>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by mailc.telia.com id UAA03030
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id PAA12675
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ded61c9332125da45ed0c24537313a4c



Paul Barton-Davis wrote:
> 
> >What happens when the cycle_diff starts to wrap :-)
> >Ok, we have 2^64 bits, but wery soon we have 2^32 cycles/s CPUs.
> >1 GHz next year, and increasing rapidly (typing on a 180 MHz PPro
> >3 years old, assume 10 GHz in another 3 years, ...)
> 
> even if we assume 10GHz, the cycle counter won't wrap for 58 years.
> 
>         2^64 / 10^10 = 1844674407 seconds till wrap
>         1844674407 / (3600 * 24 * 365) = 58 years till wrap
> 
> even Linux might not be up for that kind of uninterrupted uptime :)
> 
> also, Moore's Law is supposed to bottom out in 3 to 5 years due to
> the fundamental physics of semiconductors.
> 

Only future will tell...

But my point is that we should avoid code that can't handle
wraps correctly, it can be done without too much effort.
Like David's resyncronisation points (you do the resync when
no plugins run)

> --p

-- 

The Internet interprets Windows as damage, 
             and routes around it.

Roger Larsson
Skellefte
Sweden

From - Wed Oct 13 01:09:46 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA15446
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 15:23:48 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA05102 for linux-audio-dev-list; Tue, 12 Oct 1999 15:01:35 -0400
Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA05099 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 15:01:30 -0400
Received: from d1o43.telia.com (d1o43.telia.com [194.22.195.241])
	by mailg.telia.com (8.9.3/8.9.3) with ESMTP id UAA08659
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 20:56:36 +0200 (CEST)
Received: from skelleftea.mail.telia.com (t7o43p33.telia.com [194.237.168.153])
	by d1o43.telia.com (8.8.8/8.8.5) with ESMTP id UAA01692
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 20:56:35 +0200 (CEST)
Message-ID: <38038E9B.90D423C7@skelleftea.mail.telia.com>
Date: Tue, 12 Oct 1999 20:40:11 +0100
From: Roger Larsson <roger.larsson@skelleftea.mail.telia.com>
X-Mailer: Mozilla 4.6 [en] (Win95; I)
X-Accept-Language: sv,en
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] API design again [MORE code]
References: <199910101638.MAA10195@renoir.op.net> <99101021222707.00456@localhost.localdomain> <380273A9.73FA2B44@skelleftea.mail.telia.com> <9910120722400E.00526@localhost.localdomain>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by mailg.telia.com id UAA08659
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id PAA15446
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 86231c10c41de0cbf49e82ac92263e67



David Olofson wrote:
> 
> On Tue, 12 Oct 1999, Roger Larsson wrote:
> > Thumb rule for priority:
> >   The shorter run the higher priority.
> >   The longer run the lower priority.
> >   Then the short run can interfere with the long but not the opposite.
> 
> Exactly. Add one rule for real time systems:
>     Higher scheduling rate should have higher priority.
> 
> Without that one, the whole point with sceduling the higher rate task
> for every external event is lost if the lower rate task delays the
> higher rate task for a few wakes every now and then.
> 

Well, we are not designing a hard real time system here, are we?
What would be more frustrating to the user?
Something happens that make the sound engine miss a deadline:
a) It closes down. All sound disappears until it is restarted.
b) It lose some data. Sound is disturbed for a short time.

Maybe it should be a configurable option... During testing you
probably want it to stop, but not close.

> > But there are exceptions:
> >   To avoid filling up processor queues it might be better to
> >   run producer threads with lower prio. - consumer threads will
> >   then be able to empty their input queues before new ones are
> >   created.
> >   This is not a good solution if you can not combine inputs, or
> >   ignore some.
> >
> >   Example:
> >     suppose that engine threads have lower prio. than sensor threads.
> >     and that each sensor tread is "connected" (1-1) to a plugin.
> >     then data may build up, and overflow, on the input to the engine
> >     by using more sensor threads than expected.
> 
> System overload ==> automatic engine shutdown. (To avoid hanging the
> system, as the engine might well be running SCHED_FIFO.)
> 
> If the engine fails to handle incoming data because of the sensor
> thread CPU load, it will also fail to do it's processing before the
> deadline. That's a very severe error condition in a real time system,
> and it makes no sense trying to handle it nicely. If a deadline is
> missed, all is lost anyway...
> 

If you schedules all sensor threads uncoordinated I assume you could
get into a situation where all sensors want to run at once.
(but it should not make you run out of RAM...)

Anyway I would like a unthreaded event dispatcher... I have some
ideas...

> >   With a fast engine, the jitter in time stamps might be worth it...
> 
> No. Almost by *definition*, the engine should work correctly until
> the CPU is overloaded. That is, the engine thread may well be working
> 90% of the cycle time slice.
> 

Ok, ok, I give up...


-- 

The Internet interprets Windows as damage, 
             and routes around it.

Roger Larsson
Skellefte
Sweden

From - Wed Oct 13 01:09:48 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA04918
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 17:33:22 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA05411 for linux-audio-dev-list; Tue, 12 Oct 1999 17:10:14 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA05408 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 17:10:09 -0400
Received: from localhost.localdomain (d212-151-100-184.swipnet.se [212.151.100.184]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id XAA25342; 
          Tue, 12 Oct 1999 23:05:03 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Kai Vehmanen <kaiv@wakkanet.fi>
Subject: Re: [linux-audio-dev] a new application underway
Date: Tue, 12 Oct 1999 23:05:17 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
References: <Pine.LNX.4.10.9910121640520.1086-100000@sculpcave.localdomain>
In-Reply-To: <Pine.LNX.4.10.9910121640520.1086-100000@sculpcave.localdomain>
MIME-Version: 1.0
Message-Id: <99101223115900.00718@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id XAA25342
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id RAA04918
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 55fd45f8983f3697f7e4cc04e6fc046f

On Tue, 12 Oct 1999, Kai Vehmanen wrote:
> Hmm, most plugin/effect designs seem to be based on copying from 
> input buffer, processing and writing to output. I've always 
> done processing in-place (effects get a pointer to the sample data). 
> Am I missing something here? 

Another thing apart from what Paul pointed out; There's nothing that
says that num_of_inputs == num_of_outputs... That would be far too
restrictive, IMO at least.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Oct 13 01:09:59 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA11412
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 21:29:51 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA05831 for linux-audio-dev-list; Tue, 12 Oct 1999 21:15:18 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA05828 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 21:15:15 -0400
Received: from localhost.localdomain (d212-151-110-138.swipnet.se [212.151.110.138]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id DAA24647; 
          Wed, 13 Oct 1999 03:10:22 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Kai Vehmanen <kaiv@wakkanet.fi>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] plugin questions
Date: Tue, 12 Oct 1999 23:14:02 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <Pine.LNX.4.10.9910121424340.1086-100000@sculpcave.localdomain>
In-Reply-To: <Pine.LNX.4.10.9910121424340.1086-100000@sculpcave.localdomain>
MIME-Version: 1.0
Message-Id: <99101223573301.00718@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id DAA24647
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA11412
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5caefd715c2c79b8d3a5d1f7637603a3

On Tue, 12 Oct 1999, Kai Vehmanen wrote:
> On Mon, 11 Oct 1999, David Olofson wrote:
> 
> >> We could decide to accept string parameters only when initializing 
> >> plugins. If you need to change a string value, you'd just 
> > The event system supports dynamic size events - so there's no need to
> > treat strings as a special cases for that reason. View the event
> > system (and actually the whole MCS) as a slightly specialized RT-IPC
> > toolkit; no MIDI-style event specific crap. What we're after when we
> 
> How is this actually done in practice? If I know what kind of events 
> some plugin accepts, constructing and sending them will be easy.
> What is still unclear to me is  how do I get the type-info? I imagine 
> that creating a usable API for this won't be easy.  

No dynamic typing! It's hard-coded in the API.

Using the defines from my first suggestions...

----8<--------------------------------------
typedef unsigned int event_code_t;
#define EV_CLASS_MASK    0xff000000 /* TIMING, SYSTEM, CONTROL,... */
#define EV_FLAGS_MASK    0x00ff0000 /* EVENT, REQUEST, REPLY... */
#define EV_KIND_MASK     0x0000ffff /* Exactly what event is this? */
-------------------------------------->8----

...the type of an event is determined by the bits in the
EV_CLASS_MASK field. For the standard events (ie *not* custom
events), EV_KIND_MASK is where the event "number" goes.

> A few thoughts...
> 
> - how do we limit what kind of information plugin can ask?
>   	- booleans, floats (values between [0.0,1.0]), text, 
>           sample rate, compression ratio (= difficult to represent 
> 	  with [0.0,1.0] floats), etc
>   	- should we make a difference between realtime-controllable 
> 	  (filter cutoff) and rt-uncontrollable (channel count, 
> 	  sample rate) parameters

The distinction is vague. Carefully designed plug-ins and engines
*can* support changing just about anything in real time, or at least
between cycles. It might even make sense to change the number of
channels in real time in some applications... So, I don't think
dictating this in the API is a good idea.

> 	- should plugin provide info about valid parameter
> 	  values (min-max isn't always enough)

No, they should stick to the rules. An integer parameter could
*possibly* be allowed to have a user defined range, but if it's
really impossible to stick to the basic types, the event should
probably be private anyway.

Note that a lot can be done when telling the engine about the "soft"
properties of an event! For example, an event that allows only
power-of-2 values should still be an integer type with boundaries.
The properties that describe the event to things like generic UIs,
will provide the details.

> 	- what if plugin asks for 1024 bytes of floats and says 
>           it represents a volume envelope -> no way to create 
>           a generic UI for this (not necessarily a problem, but it
>           should made be clear whether these are accepted or not)

That's probably an example of a private type... Or perhaps we should
include a standard for handling arrays?

And BTW, I don't think it's a good idea to send single events that
big. The event system's memory allocator does support variable size
event, but it's not really designed events that big. (I guess we have
to figure out a way to send big blocks somehow. I have a feeling it's
pretty useful...)

Anyway, in this case, the events to fill in the envelope should
carry a single point each. That way, it's possible to connect things
to individual points, just as if they were ordinary parameters.

> 	- or should we just decide on all these and force all 
> 	  plugins to use standard types and value ranges ... 
> 	  although this can quickly get out of hands

I know one thing that's bound to get out of hands before we even know
what happened: Supporting dozens of fancy features as lots of special
cases.

The support for all this would *have* to be implemented, and it
would *have* to be supported by every single implementation that
gets in touch with those parts - or we'll have no standard in the
end.

Hack a Win32 compatible API, anyone? ;-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Oct 13 01:09:51 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA08589
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 17:55:54 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA05456 for linux-audio-dev-list; Tue, 12 Oct 1999 17:31:10 -0400
Received: from icemserv.folkwang.uni-essen.de (icemserv.folkwang.uni-essen.de [132.252.170.129]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA05451 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 17:31:06 -0400
Received: from folkwang.uni-essen.de (nettings@dialup4.folkwang.uni-essen.de [132.252.170.4]) by icemserv.folkwang.uni-essen.de (8.8.8/8.7.3) with ESMTP id WAA18938 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 22:41:54 +0200 (CEST)
Message-ID: <3803B682.A930C7D4@folkwang.uni-essen.de>
Date: Tue, 12 Oct 1999 22:30:26 +0000
From: =?iso-8859-1?Q?J=F6rn?= Nettingsmeier <nettings@folkwang.uni-essen.de>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] a new application underway
References: <199910111645.MAA04412@renoir.op.net> <99101201455804.00526@localhost.localdomain>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c5b6e181f2ea65d55c24f89d006b1f6b

[mono or stereo]

> On Mon, 11 Oct 1999, Paul Barton-Davis wrote:

> > i think it depends in part on what your inputs are. if they really are
> > stereo signals (stereo soundfiles, devices etc.), then having audio
> > default to stereo is a good choice.

from my mixing experience i'd prefer to have all plugins, mixer
strips etc. default to mono.
one source, one stream.
two mono channels can easily be grouped should the need arise, but a
stereo pair is hard to separate.
moreover, with surround systems coming along, stereo is no longer
the end-user standard. it would be equally justified to have all 5.1
channels, which appears a little awkward.

btw, not every stereo signal does actually carry spatial
information. all the intensity stereo can be reduced to one channel
plus pan position [iirc, michael jackson engineer bruce swedien
calls this "two channel mono" :]
only phasing stereo deserves two channels. (hope i made myself
clear, not sure about the correct terms in english)

i feel grouping should be done on a gui level, that is, make them
look like a group if the users so desires, but handle them
independently underneath. 

[not really api relevant:
a feature to link controls for stereo pairs would be nice: have each
eq, aux etc. affect both channels simultaneously unless you need
individual treatment, at which point the link must be broken and an
additional channel strip should appear.
]

regards,

jrn

-- 
Jrn Nettingsmeier     
Kurfrstenstr. 49        
45138 Essen, Germany


From - Wed Oct 13 01:10:02 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA11905
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 21:33:03 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA05836 for linux-audio-dev-list; Tue, 12 Oct 1999 21:15:27 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA05833 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 21:15:24 -0400
Received: from localhost.localdomain (d212-151-110-138.swipnet.se [212.151.110.138]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id DAA24668; 
          Wed, 13 Oct 1999 03:10:24 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] big picture, for a moment
Date: Wed, 13 Oct 1999 01:44:42 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910121618.MAA10597@renoir.op.net>
In-Reply-To: <199910121618.MAA10597@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101303171702.00718@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id DAA24668
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA11905
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 42f038d9abb11e9447f33233f7d976cc

On Tue, 12 Oct 1999, Paul Barton-Davis wrote:
> Getting closer ...
> 
> >...while I view a plug-in as a black box with a number of inputs and
> >outputs, in the form of audio ports and event ports. The average
> >plug-in would have >=0 audio inputs, >=0 audio outputs, one event
> >input, and possibly one event output. During initialization, the
> >plug-in will tell the host what events it understands (little more
> >than info for the UI), and if it has an output port; what events it
> >might send through it. 
> 			
> =======================================================================
> >			The plug-in doesn't care (or know) who listens
> >to it's output, nor does it know where the events it recieves come
> >from. 
> =======================================================================
> 
> we both absolutely agree on this key point.

Yes. I just want to go one step further and get the subscribe() call
out of the plug-ins.

> i think that our difference is small here. i look at the address of a
> port as being a statement about the events the port will "send".

Ok. That makes a very big difference.

> if
> you make this concession for a moment, i think you'll find we're
> saying something very similar. the plugin tells the engine what it
> understands. you say that it says "i understand float #5", whereas in
> my view, its says "i understand midi cc 34". the only difference here
> is what the semantics of an address are, for perhaps float 5 *is* midi
> cc 34 ! in both cases, the engine will subscribe the plugin to a
> particular port, right ?

Yes, but does that mean that one event source == one event? (As
opposed to my "send all through the same output port" mess.)

And what happens if you have multiple ports sending MIDI CC 34, or
whatever? And how do you route events so that it doesn't become
hardcoded in the plug-ins which outputs can be connected to wich
inputs? Where's the remapping done?

[...]
> essentially, i want *more* flexibility than you in that i want event
> sources to be able to *restrict* the engine's view of the kinds of
> events that will be posted to their port(s). 

"be able to *restrict*"? What if they don't? If it's *required* that
event sources send only one event, or possibly a few related event on
each port, OK. Doing the event dispatching before the events even get
a chance to be mixed up sounds reasonable to me.

> most plugins might only declare a single port, but others might
> declare many ports. consider a plugin that provided a GUI for a mixing
> console (its on my mind:). instead of mux-ing all the events for
> parameters for every strip into a single port, it would declare N
> ports, one for each strip. Then the plugins that were implementing
> strip-level FX/EQ would just be subscribed to that port, not a port
> that would contain a bunch of events they didn't care about at all.

Ok. (However, in the system I proposed, the engine would de-MUX the
events *before* they reached the subscribers - and it would do
remapping at that point as well.)

> in essence, i imagine a heterarchy of ports, some completely generic,
> some totally specific: "this port posts byte events describing the
> state of the I-Cube tap sensor". 
> 
> any "input port" (really, just a pointer to a port, since there is no
> data copying)

There *is* still some data shuffling, even if it's possibly only
building a list. If you don't build a new list before the listening
plug-in is called, how would you subscribe to multiple ports?

> that could handle byte data could be connected to this
> port, but in addition, a plugin that listed a set of possible sources
> for its displays could show "I-Cube tap sensor", and connect directly
> to that port.
> 
> and imagine being able to dynamically describe all the ports in the
> system:
> 
> 	Port Description     Data Type			Source
>         --------------------------------------------------------
> 	#13 generic	     float			pluginNN
> 	I-Cube tap sensor    byte			pluginNM
> 	#14 generic          string                     pluginXX
> 	#15 pluginNN_t       struct          		pluginNN
>         #16 audio            audio                      sensor4
> 	MIDI CC 34           byte			sensor5
> 
> and so on. I regard this as equally generic as your system, but also
> potentially much more efficient. What do you think ?

It looks fine, but there's still the remapping issue, and the
sorting/merging of event lists.

> A last comment on this. None of the above is supposed to change the
> basic notion that event sources have no idea who is listening, and
> event receivers have no idea of the event source. From a plugin's
> perspective all that matters is the *address* of a port, which also
> tells us something about its usefulness to the plugin. The plugin, in
> subscribing to port XXXXX has no idea where events on that port come
> from.

Ok, but it *will* get all events in the *single* input buffer, right?

> 
> >Well, compare that to the overhead involved when handling the number
> >of event ports needed to get the same flexibility.
> >
> >Input from multiple senders:
> >
> > * The engine has to merge the events into one list,
> >   and they must be sorted according to the timestamps.
> 
> yes, but what is the problem with that ? 

It's expensive... Hopefully not *too* expensive, as it cannot be
avoided with any system - only made harder or simpler to do.

> the plugin process() call looks like:
> 
>      /* build a Lisp-like sorted list of all events on each
>         subscribed port that occured before the current deadline.
> 
> 	*NOTE* NO DATA COPYING: the list is just a set of pointers
> 	       to the event_t's still in the ports event lists.
>       */
> 
>      mcs_build_event_list (&plugin->ev_list, &plugin->ports);
>      plugin->process (..., event_list_t *events, ...) 
> 
> >Output to multiple destinations:
> >
> > * _ALL_ events will have to be copied to _ALL_
> >   destinaiton ports by the engine, as the sending
> >   plug-in has no idea who's listening to what. And
> >   neither does the engine...
> 
> no. events are never copied at all. they exist on a port's event
> list. things that listen to the port will find them there.

...but pointers will have to be moved around when building the
listeners' lists. However, as long os it's only for events that are
actually used, it's probably not that bad. The average even isn't all
that much bigger than a pointer, though...

[...]
> >What I'm thinking about is that it's not necessarily true that
> >there are no events after the last one to be processed during
> >the current cycle. There may be events to be processed later
> >on... This happens when interfacing between sub nets with
> >different buffer sizes, and when communicating accross threads.
> 
> leaving aside the subnets with different buffer sizes, i thought that
> the whole point of the design here was something like this:
> 
> events arrive during one pass through the plugins' process()
> functions.

Yes.

> they are timestamped with the sample on which they
> occured.

...and the time stamps must in that case be adjusted by adding the
fixed latency. Timestamps on input events should tell exactly when
they occured, while timestamps on output events should indicate when
to perform an action.

However, I think "cheating" here i pretty OK; if you record
something, you probably want the playback to sound identical to the
monitor mix while recording. That means the events that go into the
sequencer should have the same timestamps as the evets that reached
the plug-ins while recording, *not* the exact timestamps of the input
events!

> during the next pass through the plugins, the plugins get to
> process the events, because the sample timestamps will correspond to
> samples they will generate/process during that or a later call to
> process(). 

Yes...? That's what I was trying to say; "or a later call to
process()", in particular.

> >As long as the GUI is also in its own *file*, OK. I can load ELF into
> >kernel space and similar weird places, but I don't feel like cleaning
> >out "irrelevant" code on the fly...
> 
> sounds fine.

Makes it possible to run the GUI as a separate task, to keep it from
taking the (user srace) engine with it as well, and also enforces
better programming style.

> >Why? That's *exactly* where the intermediate FIFO hidden behind the
> >shadow ports come in handy. If sensor threads can do it, so can
> >clients, *and*, it makes them a lot more similar to plug-ins. A
> >client is to MCS what a plug-in is to an engine... To some extent at
> >least; clients can do lots of cool stuff that plug-ins cannot.
> 
> fine. its more complex, and it will involve more overhead on both
> sides of the communication link, but fine.

Nothing comes for free... But the cost in this case is very low
considering the flexibility that the event system brings, IMO. And
BTW, counting per event, how many IPC systems are more efficient
than this event system? We can allocate memory for an event, fill it
in and post it without *one single* function call. A thread can send
hundreds of events doing only a few calls to qm_new_buffer().

> i don't buy any of this
> shadow port stuff - i think its a totally unnecessary concept. i think
> that ports should just be event FIFO's: posted to by event sources,
> read from by port subscribers, and cleaned out by the engine. 

As long as the event ports stay as simple as they are now, you're
right; shadow ports are pointless. The "events" field becomes the
FIFO write pointer, and the reader will only change the FIFO read
pointer. The heap will only be used by the writer. Unless there's
anything more a port should be able to do, that's about all there is
to it...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Oct 13 01:10:05 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA14371
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 21:49:17 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA05868 for linux-audio-dev-list; Tue, 12 Oct 1999 21:35:53 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA05865 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 21:35:50 -0400
Received: from localhost.localdomain (d212-151-110-138.swipnet.se [212.151.110.138]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id DAA19319; 
          Wed, 13 Oct 1999 03:30:57 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Roger Larsson <roger.larsson@skelleftea.mail.telia.com>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] API design again [MORE code]
Date: Wed, 13 Oct 1999 03:20:12 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910101638.MAA10195@renoir.op.net> <9910120722400E.00526@localhost.localdomain> <38038E9B.90D423C7@skelleftea.mail.telia.com>
In-Reply-To: <38038E9B.90D423C7@skelleftea.mail.telia.com>
MIME-Version: 1.0
Message-Id: <99101303375103.00718@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id DAA19319
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA14371
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c2437bbdbf9704f5ae43f2b4d3ba9e5e

On Tue, 12 Oct 1999, Roger Larsson wrote:
> Well, we are not designing a hard real time system here, are we?

On the contrary, we are.

> What would be more frustrating to the user?
> Something happens that make the sound engine miss a deadline:
> a) It closes down. All sound disappears until it is restarted.
> b) It lose some data. Sound is disturbed for a short time.

Both are fatal and must never happen. But b) is of course a nicer way
of taking care of the error condition, if the user fails to realize
that it's impossible to use 98% of the CPU time reliably...

> Maybe it should be a configurable option... During testing you
> probably want it to stop, but not close.

Well, closing it down is of course a bit brutal. After all, this is
not the lab intstrument I'm programming at work, where a controller
failure can wreck the air bearing that carries the motor and
measurument system. Cost: $1000 + work.

[...]
> If you schedules all sensor threads uncoordinated I assume you could
> get into a situation where all sensors want to run at once.
> (but it should not make you run out of RAM...)

Yes. But real time is real time. The only way to stay out of trouble
is to make sure all RT threads do their job correctly. Of course, you
can have various watchdog systems, but getting them to work, and do
anything useful about a critical condition is usually rather
complicated. Easier to makie sure the sensor threads don't freak out
in the first place.

> Anyway I would like a unthreaded event dispatcher... I have some
> ideas...

Only possible with timestamping drivers, or devices that inherently
deliver timing info through the data.

> > >   With a fast engine, the jitter in time stamps might be worth it...
> > 
> > No. Almost by *definition*, the engine should work correctly until
> > the CPU is overloaded. That is, the engine thread may well be working
> > 90% of the cycle time slice.
> > 
> 
> Ok, ok, I give up...

Well, time is a mean beast; not much to do about that... :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Oct 13 01:10:07 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA19195
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 22:20:48 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA05927 for linux-audio-dev-list; Tue, 12 Oct 1999 22:07:42 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA05924 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 22:07:40 -0400
Received: from someip.ppp.op.net (d-bm3-1a.ppp.op.net [209.152.194.90]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id WAA07606 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 22:02:50 -0400 (EDT)
Message-Id: <199910130202.WAA07606@renoir.op.net>
To: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] a new application underway 
In-reply-to: Your message of "Tue, 12 Oct 1999 22:30:26 -0000."
             <3803B682.A930C7D4@folkwang.uni-essen.de> 
Date: Tue, 12 Oct 1999 22:02:44 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: db31aba9874e37ee67d4653cb7821705

>a feature to link controls for stereo pairs would be nice: have each
>eq, aux etc. affect both channels simultaneously unless you need
>individual treatment, at which point the link must be broken and an
>additional channel strip should appear.

done in my new program, hdr, except that the channel strips don't
disappear. that part might be easy to make happen though, given the
way that GTK works.

From - Wed Oct 13 01:10:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA28259
	for <slinkp@ulster.net>; Tue, 12 Oct 1999 23:28:54 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA06029 for linux-audio-dev-list; Tue, 12 Oct 1999 23:13:54 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA06025 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 23:13:52 -0400
Received: from someip.ppp.op.net (d-bm3-1a.ppp.op.net [209.152.194.90]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id XAA12354 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 23:09:02 -0400 (EDT)
Message-Id: <199910130309.XAA12354@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] cycle counter wrapping 
In-reply-to: Your message of "Tue, 12 Oct 1999 20:19:57 BST."
             <380389DD.FD6E4738@skelleftea.mail.telia.com> 
Date: Tue, 12 Oct 1999 23:08:57 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 696327ab2cb6cd9821bf1f46481afa5b

>Only future will tell...
>
>But my point is that we should avoid code that can't handle
>wraps correctly, it can be done without too much effort.
>Like David's resyncronisation points (you do the resync when
>no plugins run)

alas, if it were that easy. but it isn't. by introducing this, you
introduce the need for a lock around the timestamp code. 

when the cycle counter can overflow the hardware set aside for it by
the chip manufacturer, there are much more serious problems in
store for us.

for now, i think we can take it as a given that the cycle counter, if
used in full, and its associated data type (long long for gcc) will
not wrap in any reasonable amount of time.

From - Wed Oct 13 01:10:11 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA32413
	for <slinkp@ulster.net>; Wed, 13 Oct 1999 00:07:28 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA06091 for linux-audio-dev-list; Tue, 12 Oct 1999 23:47:12 -0400
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id XAA06088 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 12 Oct 1999 23:47:10 -0400
Message-Id: <199910130347.XAA06088@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] MCS: 64 bit timestamps?
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Tue, 12 Oct 1999 23:41:47 -0400 (EDT)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
In-Reply-To: <99101202173005.00526@localhost.localdomain> from "David Olofson" at Oct 12, 99 01:46:38 am
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 030924fe1f09869ec28892d8afb6b3ae

As to Kai's question, I ain't no active list member right now -- what
I'm working on is a thesis proposal. :-)  Just lurking.  Thanks for
pushing forward, folks (notably Paul and David O.).

David Olofson wrote:
> On Mon, 11 Oct 1999, Paul Barton-Davis wrote:
> > if you believe that TSC/audio card drift will be minimal, then you
> > don't need to worry.
> 
> That's not the case for most users. It's pretty close for high quality
> cards, but some "consumer quality" cards even use ultra cheap ceramic
> resonators or something for CODEC time base... Heard figures like
> 44100 +/- 300 Hz *flutter*!

Recently I did a little poking around about timebase stability --
might be of interest.  For pro gear, AES defines two classes, +/-1ppm
and (I think it was) 10ppm.  So even with the high-class gear, that's
a few samples per minute of drift, which can't be considered minimal
assuming we want sample-precise timing.

Your basic uncompensated quartz crystal is speced at about 100ppm over
its operating range.  This is what most sound cards have.  I looked at
a few cheap cards and found crystals on them, but I too have heard
that some use ceramic resonators, which are rate 1000ppm and worse.

I don't know much about the time course of clock drift/flutter.  I did
some measurements of a sound card relative to CPU clock (didn't have a
really good timebase), and didn't see a lot of fast activity.  They
had an offset, and then drifted back and forth about 80 ppm overnight.
I think power-supply stability is going to be a factor.

> >    ... set cycle_counter_at_last_sync_point in the normal way ...
> >    cycle_counter_at_last_sync_point +=3D (xxx - yyy) * cycles_per_sampl=
> e.
> >=20
> > and we're done. whats so unclear ?
> 
> Nothing, really... Just not sexy enough for me, I guess. ;-)

And if I understand how this is used, doesn't this mean time can go
backwards at update boundaries?  If so, just fudge it so it stays flat
for a bit instead.  I really like monotonicity in my timebase --
preserve ordering.

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Thu Oct 14 00:47:46 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA18750
	for <slinkp@ulster.net>; Wed, 13 Oct 1999 11:00:12 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA10846 for linux-audio-dev-list; Wed, 13 Oct 1999 10:27:09 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA10843 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 13 Oct 1999 10:27:06 -0400
Received: from someip.ppp.op.net (d-bm3-16.ppp.op.net [209.152.194.86]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id KAA17897 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 13 Oct 1999 10:22:13 -0400 (EDT)
Message-Id: <199910131422.KAA17897@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MCS: 64 bit timestamps? 
In-reply-to: Your message of "Tue, 12 Oct 1999 23:41:47 EDT."
             <199910130347.XAA06088@ginette.musique.umontreal.ca> 
Date: Wed, 13 Oct 1999 11:17:40 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b450176e02889dd86bd71564113643d2

>Recently I did a little poking around about timebase stability --
>might be of interest.  For pro gear, AES defines two classes, +/-1ppm
>and (I think it was) 10ppm.

and then they added a third class: "apogee" :) their clock oscillators
have +/- 25ppm, but the clock jitter itself (which i think is the
important part) is "<< 50 picoseconds". yow. also yow is the price. 

thanks for the very interesting and useful post Eli.

--p

From - Thu Oct 14 00:47:49 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA08148
	for <slinkp@ulster.net>; Wed, 13 Oct 1999 13:24:30 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA11022 for linux-audio-dev-list; Wed, 13 Oct 1999 12:51:23 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA11019 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 13 Oct 1999 12:51:21 -0400
Received: from op.net (d-bm2-05.ppp.op.net [209.152.194.37]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id MAA03857 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 13 Oct 1999 12:46:28 -0400 (EDT)
Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id NAA03650; Wed, 13 Oct 1999 13:41:48 -0400
Date: Wed, 13 Oct 1999 13:41:48 -0400
Message-Id: <199910131741.NAA03650@op.net>
From: Paul Barton-Davis <pbd@Op.Net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] atomic xchg
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: b393dcef3ccb6bf4349ccce0ff5404e8

can someone point me to a gcc asm macro to do atomic pointer swaps ? 

From - Thu Oct 14 00:47:50 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA20848
	for <slinkp@ulster.net>; Wed, 13 Oct 1999 14:48:33 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA11153 for linux-audio-dev-list; Wed, 13 Oct 1999 14:05:42 -0400
Received: from math.mit.edu (MATH.MIT.EDU [18.87.0.8]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA11150 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 13 Oct 1999 14:05:39 -0400
Received: from schauder (SCHAUDER.MIT.EDU [18.87.0.69])
	by math.mit.edu (8.9.3/8.9.3) with ESMTP id OAA29313
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 13 Oct 1999 14:00:45 -0400 (EDT)
Date: Wed, 13 Oct 1999 14:00:45 -0400 (EDT)
From: Christopher Jeris <cjeris@math.mit.edu>
X-Sender: cjeris@schauder.mit.edu
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Linux-friendly MIDI interface boxes?
Message-ID: <Pine.GSU.4.10.9910131353470.29101-100000@schauder.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 4565dab4a286b0439a69a9a9d60af650


Has anyone out there had experience using any of the common MIDI interface
boxes (Midiman, Mark of the Unicorn, Emagic, etc) with Linux?  Are any of
them even sufficiently documented to write free software that supports
them?  My studio is rapidly growing beyond the size for which a
single-port MIDI loop is manageable; in particular since I am working on
an "Emacs for patches and sequences" it would be nice to be able to have
an in/out loop to every device from the computer, and this requires an
interface.  I was hoping for USB stuff to come out faster so as not to
have to invest in disappearing hardware, but music stuff seems to have
longer lifetime than computer stuff anyway, so I guess a parallel one
would be ok too.

I have contacted Midiman tech support but they were less than helpful
(read: clueless).  There seem to be a lot of sequencers out there but I
have not found mention of interface boxes in any of their documentation...
maybe I am missing something transparent?

thanks for any help you can give me,
Chris Jeris

From - Thu Oct 14 00:47:55 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA02335
	for <slinkp@ulster.net>; Wed, 13 Oct 1999 16:12:00 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA11284 for linux-audio-dev-list; Wed, 13 Oct 1999 15:32:21 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA11281 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 13 Oct 1999 15:32:18 -0400
From: est@hyperreal.org
Received: (qmail 25801 invoked by uid 162); 13 Oct 1999 19:27:12 -0000
Message-ID: <19991013192711.25800.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] Linux-friendly MIDI interface boxes?
In-Reply-To: <Pine.GSU.4.10.9910131353470.29101-100000@schauder.mit.edu> from
 Christopher Jeris at "Oct 13, 1999 02:00:45 pm"
To: Christopher Jeris <cjeris@math.mit.edu>
Date: Wed, 13 Oct 1999 12:27:11 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f027ed2862a5dc62482709743468eeed

Christopher Jeris discourseth:
> 
> Has anyone out there had experience using any of the common MIDI interface
> boxes (Midiman, Mark of the Unicorn, Emagic, etc) with Linux?  Are any of
> them even sufficiently documented to write free software that supports
> them?  My studio is rapidly growing beyond the size for which a
> single-port MIDI loop is manageable; in particular since I am working on
> an "Emacs for patches and sequences" [...]

That sounds interesting.  How are you doing it?  What will your
extension language be?  I'm afraid I can't help you with your
question. :|

Eric

From - Thu Oct 14 00:47:57 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA08025
	for <slinkp@ulster.net>; Wed, 13 Oct 1999 16:47:36 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA11350 for linux-audio-dev-list; Wed, 13 Oct 1999 16:07:05 -0400
Received: from math.mit.edu (MATH.MIT.EDU [18.87.0.8]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA11347 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 13 Oct 1999 16:07:02 -0400
Received: from schauder (SCHAUDER.MIT.EDU [18.87.0.69])
	by math.mit.edu (8.9.3/8.9.3) with ESMTP id QAA05323;
	Wed, 13 Oct 1999 16:02:05 -0400 (EDT)
Date: Wed, 13 Oct 1999 16:02:04 -0400 (EDT)
From: Christopher Jeris <cjeris@math.mit.edu>
X-Sender: cjeris@schauder.mit.edu
To: est@hyperreal.org
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Linux-friendly MIDI interface boxes?
In-Reply-To: <19991013192711.25800.qmail@hyperreal.org>
Message-ID: <Pine.GSU.4.10.9910131543410.29101-100000@schauder.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2246a0dc9dd707be4bbe1afa9c810a94

>> (mention of my secret "Emacs for patches and sequences" project)
> That sounds interesting.  How are you doing it?  What will your
> extension language be?  I'm afraid I can't help you with your
> question. :|

It's a project I've mentioned before, a long time ago - maybe on
alsa-devel ?  I'm a little leery of talking about it because I'm a long
way from working code and don't want anyone to mind if this doesn't go
anywhere.  Basically I want to take an Objective Caml interpreter
(http://caml.inria.fr/) and extend it with the ALSA sequencer API, then
build a set of higher-order functional operations for manipulating synth
patches and midi sequences.  Eventually there would be visual editing
facilities together with an interactive top-level interpreter, that you
could converse with to express more complicated operations that don't
reduce to single mouse clicks, like "take this whole bank of patches and
remap control knob 4 to Overdrive with depth +63 in all of them, moving
any previous routing to Control Change #nn."  (Look Ma! Instant Controlled
Bleeding!)

O'Caml is the fastest implementation of a "civilized" (read: strongly
typed with higher-order functions and polymorphism) language that I know
of, which is why I chose it.  I am hoping the MIDI protocol is slow enough
in relation to current processors that I might not even have to
micromanage the garbage collector too much when it comes time to handle
sequences.  Having a hardware interface to handle timing would be nice,
but PBD's reply makes the situation look pretty grim on that front.

peace,
Chris Jeris

From - Thu Oct 14 00:47:54 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA00888
	for <slinkp@ulster.net>; Wed, 13 Oct 1999 16:03:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA11253 for linux-audio-dev-list; Wed, 13 Oct 1999 15:12:46 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA11250 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 13 Oct 1999 15:12:41 -0400
Received: from someip.ppp.op.net (d-bm2-05.ppp.op.net [209.152.194.37]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id PAA19471 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 13 Oct 1999 15:07:48 -0400 (EDT)
Message-Id: <199910131907.PAA19471@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Linux-friendly MIDI interface boxes? 
In-reply-to: Your message of "Wed, 13 Oct 1999 14:00:45 EDT."
             <Pine.GSU.4.10.9910131353470.29101-100000@schauder.mit.edu> 
Date: Wed, 13 Oct 1999 16:03:10 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3f3048365c344dbdde733ad019268154

>Has anyone out there had experience using any of the common MIDI interface
>boxes (Midiman, Mark of the Unicorn, Emagic, etc) with Linux?  

if they have windows or mac software to run them, they don't work
under linux. MOTU and Midiman have refused to provide specs. The USB
stuff should work at some point, but the last i heard, the
kernel/driver USB group were still trying to get hold of some Opcode
USB devices to test.

there are some standalone MIDI interface boxes that don't interact
with a computer. A german company called Miditemp makes a very nice
for one for about 1000 Euro's. Its the next midi interface that i will
be buying. it is basically a matrix midi router - you can do any
routing you can imagine. it comes with a hand-held remote controller, too.

you can also get lucky with older standalone (2nd hand) MIDI patch
bays - i paid $100 for an ensoniq KMX-16 which has 16 ins and 15
outs. it won't do simultaneous routing of all inputs to one output
like the Miditemp, but it can merge any pair of inputs to any set of
outputs. it has no software to control it, but does have sysex
control. i like it.

--p

From - Thu Oct 14 00:48:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA12246
	for <slinkp@ulster.net>; Wed, 13 Oct 1999 17:13:09 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA11381 for linux-audio-dev-list; Wed, 13 Oct 1999 16:39:19 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id QAA11378 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 13 Oct 1999 16:39:08 -0400
From: est@hyperreal.org
Received: (qmail 25152 invoked by uid 162); 13 Oct 1999 20:34:15 -0000
Message-ID: <19991013203415.25151.qmail@hyperreal.org>
Subject: [linux-audio-dev] MIDI and civilized languages
In-Reply-To: <Pine.GSU.4.10.9910131543410.29101-100000@schauder.mit.edu> from
 Christopher Jeris at "Oct 13, 1999 04:02:04 pm"
To: Christopher Jeris <cjeris@math.mit.edu>
Date: Wed, 13 Oct 1999 13:34:15 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 1343486a12df7d95bb87c24c8443690c

Christopher Jeris discourseth:
> >> (mention of my secret "Emacs for patches and sequences" project)
> > That sounds interesting.  How are you doing it?  What will your
> > extension language be?  I'm afraid I can't help you with your
> > question. :|
> 
> It's a project I've mentioned before, a long time ago - maybe on
> alsa-devel ?  I'm a little leery of talking about it because I'm a long
> way from working code and don't want anyone to mind if this doesn't go
> anywhere.  Basically I want to take an Objective Caml interpreter
> (http://caml.inria.fr/) and extend it with the ALSA sequencer API, then
> build a set of higher-order functional operations for manipulating synth
> patches and midi sequences.

Very nice..I hope you *do* do this. :)

> Eventually there would be visual editing
> facilities together with an interactive top-level interpreter, that you
> could converse with to express more complicated operations that don't
> reduce to single mouse clicks, like "take this whole bank of patches and
> remap control knob 4 to Overdrive with depth +63 in all of them, moving
> any previous routing to Control Change #nn."  (Look Ma! Instant Controlled
> Bleeding!)

Heh..if the mouse is too low bandwidth there's always midi events to
trigger operations. :)

> O'Caml is the fastest implementation of a "civilized" (read: strongly
> typed with higher-order functions and polymorphism) language that I know
> of, which is why I chose it.

Indeed..kind of at the trojan point of Scheme and C++.  One nifty
implementation detail is that the byte-code interpreter uses gcc's
computed gotos.  Oh..and the winner (or maybe it was just a high
scorer?) of last year's ICFP programming contest was coded in ocaml.

> I am hoping the MIDI protocol is slow enough
> in relation to current processors that I might not even have to
> micromanage the garbage collector too much when it comes time to handle
> sequences.

Sigh..the achilles heel of civilization.  If that gc isn't built for
resonably hard real-time, I don't think you're going to get it.

Eric

From - Thu Oct 14 00:47:58 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA11733
	for <slinkp@ulster.net>; Wed, 13 Oct 1999 17:10:33 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA11391 for linux-audio-dev-list; Wed, 13 Oct 1999 16:43:46 -0400
Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA11388 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 13 Oct 1999 16:43:44 -0400
Received: from d1o43.telia.com (root@d1o43.telia.com [194.22.195.241])
	by maile.telia.com (8.9.3/8.9.3) with ESMTP id WAA16902
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 13 Oct 1999 22:38:48 +0200 (CEST)
Received: from skelleftea.mail.telia.com (t2o43p23.telia.com [194.22.195.83])
	by d1o43.telia.com (8.8.8/8.8.5) with ESMTP id WAA00207
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 13 Oct 1999 22:38:47 +0200 (CEST)
Message-ID: <3804F80B.64C9B251@skelleftea.mail.telia.com>
Date: Wed, 13 Oct 1999 22:22:19 +0100
From: Roger Larsson <roger.larsson@skelleftea.mail.telia.com>
X-Mailer: Mozilla 4.6 [en] (Win95; I)
X-Accept-Language: sv,en
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] cycle counter wrapping
References: <199910130309.XAA12354@renoir.op.net>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by maile.telia.com id WAA16902
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id RAA11733
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 89df46e46a6a611a63e587f45b49d063



Paul Barton-Davis wrote:
> 
> >Only future will tell...
> >
> >But my point is that we should avoid code that can't handle
> >wraps correctly, it can be done without too much effort.
> >Like David's resyncronisation points (you do the resync when
> >no plugins run)
> 
> alas, if it were that easy. but it isn't. by introducing this, you
> introduce the need for a lock around the timestamp code.
> 

I wondered why, since it would only be one thread that writes to it.
But since it is a 'long long' the CPU would need two writes
and then another process might step in... or a rescheduling might
interfere.

So, yes I think this is a bigger problem than the wrap...

> when the cycle counter can overflow the hardware set aside for it by
> the chip manufacturer, there are much more serious problems in
> store for us.
> 

And if they go for 128 bits we could handle it then by scaling.
But there should be a note about this in the comments...

> for now, i think we can take it as a given that the cycle counter, if
> used in full, and its associated data type (long long for gcc) will
> not wrap in any reasonable amount of time.

Shouldn't it be 'unsigned long long'?

/RogerL
-- 

The Internet interprets Windows as damage, 
             and routes around it.

Roger Larsson
Skellefte
Sweden

From - Thu Oct 14 00:48:15 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA05798
	for <slinkp@ulster.net>; Wed, 13 Oct 1999 19:58:48 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA11705 for linux-audio-dev-list; Wed, 13 Oct 1999 19:26:33 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA11702 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 13 Oct 1999 19:26:31 -0400
Received: from localhost.localdomain (d212-151-41-87.swipnet.se [212.151.41.87]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA10037; 
          Thu, 14 Oct 1999 01:21:35 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] cycle counter wrapping
Date: Thu, 14 Oct 1999 00:40:48 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910130309.XAA12354@renoir.op.net>
In-Reply-To: <199910130309.XAA12354@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101400541000.00721@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id BAA10037
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA05798
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 57b9d7f74ec1ae03f141b2167ccfc848

On Wed, 13 Oct 1999, Paul Barton-Davis wrote:
> >Like David's resyncronisation points (you do the resync when
> >no plugins run)
> 
> alas, if it were that easy. but it isn't. by introducing this, you
> introduce the need for a lock around the timestamp code. 

...but we *have* atomic pointer read/write, right? So it would be
possible for the resync code to fill in a struct and then change the
shared pointer to it. Note that it's a "soft" sync requirement, as
the old sync point struct is still valid - only a little less
accurate than the new one.

OK, it *is* possible that a thread that grabs the pointer, then
gets blocked, and wakes up just when the resync code is overwriting
the old struct. That is, the struct pointer you grab is only valid
for one resync cycle. However, if a sensor thread is scheduled out
for that long, that means that 1) it will get a very useless
timestamp anyway, and 2) the engine will sustain a drop out, as it's
supposed to have lower priority than the sensor thread...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Thu Oct 14 00:48:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA32477
	for <slinkp@ulster.net>; Wed, 13 Oct 1999 19:22:44 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA11630 for linux-audio-dev-list; Wed, 13 Oct 1999 18:51:33 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA11627 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 13 Oct 1999 18:51:30 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id SAA26390;
	Wed, 13 Oct 1999 18:42:38 -0400 (EDT)
Received: from localhost by ux02 (8.9.1b+Sun) id SAA14616; Wed, 13 Oct 1999 18:42:39 -0400 (EDT)
Date: Wed, 13 Oct 1999 18:42:39 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: David Olofson <audiality@swipnet.se>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc.
In-Reply-To: <9910120757390H.00526@localhost.localdomain>
Message-ID: <Pine.GSO.4.10.9910131831370.13933-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e0ae670b6e7090845ed8819455ae7b28

On Tue, 12 Oct 1999, David Olofson wrote:

> <mode nitpick=on>
> 31250 Hz bit rate. And then you have a start bit and a stop bit as
> well, so it's even below 31.25k! ;-)
> </mode>

Dang, off by an order of magnitude.  I'm not old enough to be senile...
 
> Hmm... Who reorganizes the data bits then? Twice, for that matter!
> That's the *really* uggly part of SysEx programming...

Well, if your source and target both expect seven bit data, then a seven
bit transport is just fine.  Still, I never heard of a card that filled
its patch memory in seven bit "bytes", so you're right.

You've convinced me, I guess.  An eight-bit, generalized event protocol
would be a very good thing to have.  You lose many of the advantages that
MIDI gives you in terms of standardization, but the potential flexibility
may make it worthwhile anyway.  Just make sure that it remains accessible
was a simple, unidirectional, non-handshaking, realtime stream with all
operations inband, and I'll be happy.

Div.

From - Thu Oct 14 00:48:10 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA05596
	for <slinkp@ulster.net>; Wed, 13 Oct 1999 19:57:42 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA11720 for linux-audio-dev-list; Wed, 13 Oct 1999 19:26:43 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA11716 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 13 Oct 1999 19:26:40 -0400
Received: from localhost.localdomain (d212-151-41-87.swipnet.se [212.151.41.87]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA10067; 
          Thu, 14 Oct 1999 01:21:36 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: eli+@cs.cmu.edu, Eli Brandt <eli@v.gp.cs.cmu.edu>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MCS: 64 bit timestamps?
Date: Thu, 14 Oct 1999 00:57:31 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910130347.XAA06088@ginette.musique.umontreal.ca>
In-Reply-To: <199910130347.XAA06088@ginette.musique.umontreal.ca>
MIME-Version: 1.0
Message-Id: <99101401060401.00721@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id BAA10067
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA05596
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 63ff9dfbd68eb4397f04493dc0667e9c

On Wed, 13 Oct 1999, Eli Brandt wrote:
> Recently I did a little poking around about timebase stability --
> might be of interest.  For pro gear, AES defines two classes, +/-1ppm
> and (I think it was) 10ppm.  So even with the high-class gear, that's
> a few samples per minute of drift, which can't be considered minimal
> assuming we want sample-precise timing.

True. There's no such thing as two devices that don't need to be
actively kept in sync one way or another.

> Your basic uncompensated quartz crystal is speced at about 100ppm over
> its operating range.  This is what most sound cards have.

Some 10 resyncs/second to stay within .5 samples then... (Unless I
did some miscalculation, that is. :-)

> > >    ... set cycle_counter_at_last_sync_point in the normal way ...
> > >    cycle_counter_at_last_sync_point +=3D (xxx - yyy) * cycles_per_sampl=
> > e.
> > >=20
> > > and we're done. whats so unclear ?
> > 
> > Nothing, really... Just not sexy enough for me, I guess. ;-)
> 
> And if I understand how this is used, doesn't this mean time can go
> backwards at update boundaries?  If so, just fudge it so it stays flat
> for a bit instead.  I really like monotonicity in my timebase --
> preserve ordering.

Yes. If we stick to sample accuracy, this is safe as long as the
resyncs are done frequently enough. But with higher timestamp
resolutions, some other solution is needed...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Thu Oct 14 00:48:05 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA03299
	for <slinkp@ulster.net>; Wed, 13 Oct 1999 19:43:50 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA11686 for linux-audio-dev-list; Wed, 13 Oct 1999 19:13:22 -0400
Received: from CS.Princeton.EDU (CS.Princeton.EDU [128.112.136.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA11683 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 13 Oct 1999 19:13:19 -0400
Received: from ux02 (dgslomin@ux02 [128.112.169.22])
	by CS.Princeton.EDU (8.9.3/8.9.3) with ESMTP id TAA28496
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 13 Oct 1999 19:07:39 -0400 (EDT)
Received: from localhost by ux02 (8.9.1b+Sun) id TAA14706; Wed, 13 Oct 1999 19:07:43 -0400 (EDT)
Date: Wed, 13 Oct 1999 19:07:42 -0400 (EDT)
From: David Slomin <dgslomin@CS.Princeton.EDU>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Linux-friendly MIDI interface boxes?
In-Reply-To: <Pine.GSU.4.10.9910131543410.29101-100000@schauder.mit.edu>
Message-ID: <Pine.GSO.4.10.9910131903480.13933-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4a5b2199d0a455828ac9df7be1f920ef

On Wed, 13 Oct 1999, Christopher Jeris wrote:

> O'Caml is the fastest implementation of a "civilized" (read: strongly
> typed with higher-order functions and polymorphism) language that I know
> of, which is why I chose it.  

Is Caml as utterly painful to work in as traditional ML (such as SML/NJ)?
I liked the high-order functions and polymorphism, but despised the
overall syntax. 

Still, the project sounds very promising.  Sort of like a non-gui-centric
jMax which uses a generic language rather than a proprietary one.

Div.

From - Thu Oct 14 00:48:08 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA05225
	for <slinkp@ulster.net>; Wed, 13 Oct 1999 19:55:47 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA11712 for linux-audio-dev-list; Wed, 13 Oct 1999 19:26:38 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA11707 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 13 Oct 1999 19:26:35 -0400
Received: from localhost.localdomain (d212-151-41-87.swipnet.se [212.151.41.87]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA10095; 
          Thu, 14 Oct 1999 01:21:38 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Christopher Jeris <cjeris@math.mit.edu>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Linux-friendly MIDI interface boxes?
Date: Thu, 14 Oct 1999 01:09:21 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <Pine.GSU.4.10.9910131353470.29101-100000@schauder.mit.edu>
In-Reply-To: <Pine.GSU.4.10.9910131353470.29101-100000@schauder.mit.edu>
MIME-Version: 1.0
Message-Id: <99101401130902.00721@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id BAA10095
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA05225
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c5ac0f2a2a6eaebd89ea9530ae162478

On Wed, 13 Oct 1999, Christopher Jeris wrote:
> I have contacted Midiman tech support but they were less than helpful
> (read: clueless).

I was in touch with thew as well a year ago or so, trying to get the
specs for that 4 ch audio card (whatever it's called...) they had. No
way. "We don't *have* any specs." I could get specs for the MIDI
interfaces though... NDA required. :-(


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Thu Oct 14 00:48:07 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA05221
	for <slinkp@ulster.net>; Wed, 13 Oct 1999 19:55:45 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA11717 for linux-audio-dev-list; Wed, 13 Oct 1999 19:26:40 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA11711 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 13 Oct 1999 19:26:37 -0400
Received: from localhost.localdomain (d212-151-41-87.swipnet.se [212.151.41.87]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA10121; 
          Thu, 14 Oct 1999 01:21:39 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Christopher Jeris <cjeris@math.mit.edu>, est@hyperreal.org
Subject: Re: [linux-audio-dev] Linux-friendly MIDI interface boxes?
Date: Thu, 14 Oct 1999 01:17:48 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <Pine.GSU.4.10.9910131543410.29101-100000@schauder.mit.edu>
In-Reply-To: <Pine.GSU.4.10.9910131543410.29101-100000@schauder.mit.edu>
MIME-Version: 1.0
Message-Id: <99101401230103.00721@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id BAA10121
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA05221
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2f1b4fe03aceaf45d069c2274a6a5821

On Wed, 13 Oct 1999, Christopher Jeris wrote:
> Having a hardware interface to handle timing would be nice,
> but PBD's reply makes the situation look pretty grim on that front.

Hopefully, the MCS effort will somehow result in drivers, clients or
plug-ins that can handle MIDI timing. Just add support for the new
API, connect to some MIDI driver via the MCS, and all you have to do
is make sure the events you send are sent before they should be
played. Buffer as much as you need for reliability.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Thu Oct 14 00:48:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA08038
	for <slinkp@ulster.net>; Wed, 13 Oct 1999 20:11:15 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA11740 for linux-audio-dev-list; Wed, 13 Oct 1999 19:41:42 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA11737 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 13 Oct 1999 19:41:38 -0400
Received: from localhost.localdomain (d212-151-41-87.swipnet.se [212.151.41.87]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA27099; 
          Thu, 14 Oct 1999 01:36:39 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: David Slomin <dgslomin@CS.Princeton.EDU>
Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc.
Date: Thu, 14 Oct 1999 01:31:24 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <Pine.GSO.4.10.9910131831370.13933-100000@ux02.CS.Princeton.EDU>
In-Reply-To: <Pine.GSO.4.10.9910131831370.13933-100000@ux02.CS.Princeton.EDU>
MIME-Version: 1.0
Message-Id: <99101401433404.00721@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id BAA27099
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA08038
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e6331bca9acd51bfeed719e5443b750b

On Thu, 14 Oct 1999, David Slomin wrote:
> Just make sure that it remains accessible
> was a simple, unidirectional, non-handshaking, realtime stream with all
> operations inband, and I'll be happy.

That's a bit outside the scope of the MCS event system, I'm afraid...
It's not a serial line communication protocol. Even though we're
dealing with a highly optimized design with inline code to handle
dynamic memory allocation and that kind of stuff, we're still worried
about performance. It's not MIDI on steroids. It's custom shared
memory IPC turned into a flexible real time communication system,
hopefully without losing too much performance.

You can't have it all. But there is always the possibility of making
a network/serial/parallel link protocol a part of the official MCS
spec... It has to be designed and implemented anyway.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Thu Oct 14 00:48:22 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA26014
	for <slinkp@ulster.net>; Wed, 13 Oct 1999 21:53:49 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA11867 for linux-audio-dev-list; Wed, 13 Oct 1999 21:08:40 -0400
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id VAA11864 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 13 Oct 1999 21:08:37 -0400
Message-Id: <199910140108.VAA11864@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Linux-friendly MIDI interface boxes?
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Wed, 13 Oct 1999 21:03:17 -0400 (EDT)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
In-Reply-To: <199910131907.PAA19471@renoir.op.net> from "Paul Barton-Davis" at Oct 13, 99 04:03:10 pm
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f8f5e588473ecaacf472599ed8207524

Paul Barton-Davis wrote:
> The USB stuff should work at some point, but the last i heard, the
> kernel/driver USB group were still trying to get hold of some Opcode
> USB devices to test.

Not Linux-related yet, but has anybody done timing tests on USB MIDI
interfaces?  The Roland/Microsoft proposal for MIDI on USB (dunno if
Opcode uses it; I know MOTU doesn't) worries me.  It sends MIDI as
`bulk transport'.

Each ~1500-byte USB frame has slots allocated for isochronous
(guaranteed-bandwidth) connections, plus some room for control data.
What's left over is handed out with no particular arbitration to
people wanting bulk transport.  Sending MIDI this way seems risky if
there's other activity on the bus.  I'm curious whether people
actually see the interference I expect.

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Thu Oct 14 00:48:23 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA26119
	for <slinkp@ulster.net>; Wed, 13 Oct 1999 21:54:42 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA11898 for linux-audio-dev-list; Wed, 13 Oct 1999 21:28:57 -0400
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id VAA11895 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 13 Oct 1999 21:28:55 -0400
Message-Id: <199910140128.VAA11895@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Linux-friendly MIDI interface boxes?
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Wed, 13 Oct 1999 21:23:53 -0400 (EDT)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
In-Reply-To: <Pine.GSU.4.10.9910131543410.29101-100000@schauder.mit.edu> from "Christopher Jeris" at Oct 13, 99 04:02:04 pm
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 04b18473f3b1ad7bee9b8ee99175329a

Christopher Jeris wrote:
> Basically I want to take an Objective Caml interpreter
> (http://caml.inria.fr/) and extend it with the ALSA sequencer API, then
> build a set of higher-order functional operations for manipulating synth
> patches and midi sequences.

Nifty.  I approve.

Have you looked at Haskore?  http://www.haskell.org/haskore/
Some maybe-useful ideas about how to handle music vs. MIDI.  It's all
in Haskell, naturally, which is not as practical a system as O'Caml.

> I am hoping the MIDI protocol is slow enough
> in relation to current processors that I might not even have to
> micromanage the garbage collector too much when it comes time to handle
> sequences.

Like Gc.full_major() every millisecond? :-)

What the world needs is for somebody to figure out how to package
modern GC technology in a modular way, so that language implementations 
1) use it, and 2) don't get inextricably entangled with the GC they use.
Surprisingly hard, apparently.

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Fri Oct 15 03:05:25 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id IAA09139
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 08:03:36 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id HAA16672 for linux-audio-dev-list; Thu, 14 Oct 1999 07:32:12 -0400
Received: from ife.ee.ethz.ch (ife-ife3.ee.ethz.ch [129.132.25.193]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA16669 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 07:32:09 -0400
Received: from ife.ee.ethz.ch (eldrich.ee.ethz.ch [129.132.24.203])
	by ife.ee.ethz.ch (8.8.5/8.8.5) with ESMTP id NAA01275;
	Thu, 14 Oct 1999 13:27:11 +0200 (MET DST)
Message-ID: <3805BE0F.924A912E@ife.ee.ethz.ch>
Date: Thu, 14 Oct 1999 13:27:11 +0200
From: Thomas Sailer <sailer@ife.ee.ethz.ch>
Organization: IfE
X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4u)
X-Accept-Language: de,fr,ru
MIME-Version: 1.0
To: Paul Barton-Davis <pbd@Op.Net>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] atomic xchg
References: <199910131741.NAA03650@op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 6de034274d98fe9c2aaf52d6fbbb6593

Paul Barton-Davis wrote:
> 
> can someone point me to a gcc asm macro to do atomic pointer swaps ?

This is unportable, but on x86 it would probably look like: (for 32bit
quantities)

asm("xchg %1,%0" : "=r" (a), "=m" (b) : "0" (a), "1" (b));

b is the memory operand. You cannot swap atomically two memory operands.

Tom

From - Fri Oct 15 03:05:34 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA27507
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 10:17:52 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA16855 for linux-audio-dev-list; Thu, 14 Oct 1999 09:37:41 -0400
Received: from www.tomy.net (www.tomy.net [209.186.149.104]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA16852 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 09:37:39 -0400
From: thudson@cygnus.com
Received: from cygnus.com (IDENT:thudson@jimi.tomy.net [192.168.1.2])
	by www.tomy.net (8.9.3/8.9.3) with ESMTP id JAA07851
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 09:32:51 -0400
Message-ID: <3805DBE6.62317B0@cygnus.com>
Date: Thu, 14 Oct 1999 09:34:30 -0400
Organization: Cygnus Solutions
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Linux-friendly MIDI interface boxes?
References: <199910131907.PAA19471@renoir.op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 43605d3835befc2a1a220e887828c2f4

Paul Barton-Davis wrote:
>
> you can also get lucky with older standalone (2nd hand) MIDI patch
> bays - i paid $100 for an ensoniq KMX-16 which has 16 ins and 15
> outs. 

I use an Anatek SMP-16. 7 midi in, 8 midi out, and a 16x16 audio
matrix, all controllable by sysex. It also supports a 6-slider
control surface, merging/filtering of two inputs. I've also
had good success in creating an ALSA client that creates 8 client
ports and multiplexes these to the eight 8 midi outs using 
a single input port.

These are no longer made but you might find a used one cheap.
I believe they also made an SMP-8 that had the same number of midi
ports but no audio matrix.


Thomas

From - Fri Oct 15 03:05:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA04222
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 11:13:34 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA16907 for linux-audio-dev-list; Thu, 14 Oct 1999 10:14:45 -0400
Received: from sculpcave (ppp-4.wakkanet.fi [194.157.35.212]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA16904 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 10:14:35 -0400
Received: from localhost (localhost [127.0.0.1])
	by sculpcave (Postfix) with ESMTP
	id 5897E34D43; Thu, 14 Oct 1999 17:04:37 +0300 (EEST)
Date: Thu, 14 Oct 1999 17:04:37 +0300 (EEST)
From: Kai Vehmanen <root@wakkanet.fi>
X-Sender: root@sculpcave.localdomain
To: Paul Barton-Davis <pbd@Op.Net>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway 
In-Reply-To: <199910121522.LAA04637@renoir.op.net>
Message-ID: <Pine.LNX.4.20.9910141623110.755-100000@sculpcave.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f0623f06e9e706f8989b850b84092690

On Tue, 12 Oct 1999, Paul Barton-Davis wrote:

>> Currently most studio gear is designed to handle stereo-data 
> yes. and this is going to look very old fashioned in a very short
> time as computer-based (read: unlimited by conventional h/w
> constraints) solutions become more prevalent. nuendo is a clear
> demonstration of that.

Stereo-systems may look old fashioned, but they won't go away. I'd
love to be able to mix my music using >2 channels, but how would
I distribute it? Consumer audio, CDs, MDs, cassettes, LPs, radio, 
TV, etc. etc. are all stereo-based. Of course this will change at 
some point, but I can't see this coming any time soon. The technology
is already here, it's not the problem.

Hmm, can you briefly describe what Nuendo does...? I haven't used 
Windows/mac audio apps since SoundForge4.0...

>>connecting chains to each other.. This way I could easily simulate 
>>strip-bus combination or go even further... 
> on lesson i've learned in 13 years of programming is not to push for
> too much abstraction at the expense of usability. juhana has certainly
> talked and written and coded some interesting stuff about arbitrary
> processing nets, and David's proposed engine does some of the same

I've tried to come up with a design, which would allow me to flexibly 
combine mono, stereo and multichannel audio chains, but it always gets
too complex (computationally). If I just use mono chains to represent
multichannel audio, this again will complicate the effect configuration 
as I'd have to connect stereo/m-channel effects to multiple chains.

Any suggestions?

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav

From - Fri Oct 15 03:05:40 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA05295
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 11:19:30 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA16947 for linux-audio-dev-list; Thu, 14 Oct 1999 10:42:02 -0400
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA16944 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 10:42:00 -0400
Received: from bright.net (find-cas1-cs-11.dial.bright.net [209.143.26.114])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id KAA00829;
	Thu, 14 Oct 1999 10:37:04 -0400 (EDT)
Message-ID: <3805F204.225DA055@bright.net>
Date: Thu, 14 Oct 1999 11:08:52 -0400
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Linux Soundapps page updated
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 23506acf9b71f7f8a38fb3ee26248c20

Greetings:

  Just so everyone knows: I've updated the Linux Sound & MIDI Software
pages again. I've also updated the 1-page format, my apologies to those
who missed an update for that page last month.

  The mirror at the University of Vienna has disappeared. My contact
there is unreachable, so if anyone would like to mirror the site in
Europe please let me know.

  Lots of new listings. Check 'em out, have fun !

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
       http://www.bright.net/~dlphilp/linuxsound/

From - Fri Oct 15 03:05:42 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA10620
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 11:53:10 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA17001 for linux-audio-dev-list; Thu, 14 Oct 1999 11:27:18 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA16998 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 11:27:16 -0400
Received: from someip.ppp.op.net (d-bm3-08.ppp.op.net [209.152.194.72]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id LAA16936 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 11:22:19 -0400 (EDT)
Message-Id: <199910141522.LAA16936@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] atomic xchg 
In-reply-to: Your message of "Tue, 04 Jan 2000 02:25:08 +1100."
             <3870BF54.E9C7E4C9@response.cx> 
Date: Thu, 14 Oct 1999 12:17:53 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 778fe66d7231550c835168efb27945c6

In message <3870BF54.E9C7E4C9@response.cx>you write:
>Why do u wish to do this -- is it a concurrency issue ??

yep. when an engine thread is writing to a set of output buffers, and
another thread is reading from a different set of output buffers, i'd
like to able to atomically swap the pointers to the buffer sets
without a lock whenever the reader thread is all done. something like
that.

that way, the engine thread can keep doing its stuff (as long its uses
the pointer all the time and does not cache it, and declares it
volatile) without having to constantly lock and unlock every time it
wants to stuff data into the output buffer.

david has also pointed a potential (though not likely to be used) use
for it with timestamping.


From - Fri Oct 15 03:05:44 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA13047
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 12:09:03 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA17014 for linux-audio-dev-list; Thu, 14 Oct 1999 11:37:09 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA17011 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 11:37:04 -0400
Received: from someip.ppp.op.net (d-bm3-08.ppp.op.net [209.152.194.72]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id LAA18174 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 11:32:01 -0400 (EDT)
Message-Id: <199910141532.LAA18174@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] a new application underway 
In-reply-to: Your message of "Thu, 14 Oct 1999 17:04:37 +0300."
             <Pine.LNX.4.20.9910141623110.755-100000@sculpcave.localdomain> 
Date: Thu, 14 Oct 1999 12:27:36 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 42035d78c12f06f9304267d239142f49

>TV, etc. etc. are all stereo-based. Of course this will change at 
>some point, but I can't see this coming any time soon. The technology
>is already here, it's not the problem.

i think that the audio&entertainment industry will be making a big
push on this within the next few years. they see it as their next "CD"
- a new format that will persuade people to buy new equipment, new
formats of old material etc.

already, quite a large number of people in the US are buying "home
theater" setups that use 5.1 surround sound, for example.

>Hmm, can you briefly describe what Nuendo does...? I haven't used 
>Windows/mac audio apps since SoundForge4.0...

Nuendo is an integrated audio + video editor/sequencer. Its much like
all the rest, only better and also connects audio + video together in
a much more intuitive way than has been done previously (as far as i
know, and i know very, very little about video. BTW, the Avid video
stuff is being/has been merged into the next (current?) release of
protools - they (Digidesign - a division of Avid) will have a single
product now).

As far as surround sound goes: as far as i can determine, they store a
set of pan coefficients with the track. You can change the size of the
set of pan coefficents at any time. If its just 2, you get a stereo
slider pan UI, but for more than that, they provide a 2-view 3D
panner, one presenting position (X-Y axis) and one azimuth
(elevation).  It shows each speaker. You can add/remove/move speakers.
i think that adding or removing just alters the set of pan coefficents
(and who knows, it might just be "float pan_coefficients[SPEAKER_MAX]").

as you move the "cursor" around, they recompute the set of pan
coefficients to match. then i think they use them during playback
and/or splitting the track to N tracks for actual surround sound
media.

this is based on their literature and a demo at AES, plus my intuition
from trying to do the same thing.

>I've tried to come up with a design, which would allow me to flexibly 
>combine mono, stereo and multichannel audio chains, but it always gets
>too complex (computationally). If I just use mono chains to represent
>multichannel audio, this again will complicate the effect configuration 
>as I'd have to connect stereo/m-channel effects to multiple chains.

just ban stereo FX :) i'm only half-kidding! if you can group/sync the
controls on FX, you can do multi-channel FX with mono FX processors. 

--p

From - Fri Oct 15 03:05:52 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA27151
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 17:09:57 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA17428 for linux-audio-dev-list; Thu, 14 Oct 1999 16:22:38 -0400
Received: from chekov.Belgium.EU.net (chekov.belgium.eu.net [193.74.208.161]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA17401 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 16:19:01 -0400
Received: from (adial186.liege.eunet.be [195.207.174.186])
	by chekov.Belgium.EU.net  with SMTP id WAA04096 
	for <linux-audio-dev@ginette.musique.umontreal.ca>;
	Thu, 14 Oct 1999 22:13:56 +0200 (MET DST)
Subject: [linux-audio-dev] cpu/disk tradeoff
From: Benjamin GOLINVAUX <golinvaux@benjamin.net>
Reply-To: Benjamin GOLINVAUX <golinvaux@benjamin.net>
In-Reply-To: <37F53112.5E122044@virginia.edu>
Message-ID: <000356dcea8b6283_mailit@relay.eunet.be>
References: <37F53112.5E122044@virginia.edu>
Date: Thu, 14 Oct 1999 22:09:17 +0200
X-Mailer: BeatWare Mail-It 2.0.3
X-BeOS-Platform: Intel or clone
X-Priority: 3 (Normal)
To: linux-audio-dev@ginette.musique.umontreal.ca
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 2c7c6d9572fac4c94f8b227467fdc174

Hi !

I'm trying to devise a good sample edition and streaming method, 
and I've already been kindly advised by users on this list to use a
different file per processed part of my audio files, regarding non-
destructive editing.

However, there are two additional decisions that I don't wanna take
before having explained them to a broader audience than just me
and my dog (shame on my dog who still prefers fixed-point dsp).

** 1 ** Regarding edit lists issues, I saw two solutions : keep a list of
undo stack events, where each event would be desribing a past state 
or the present state of audio file. This event would be a list of file 
entries,
 along with offsets in this file and duration. This list would then be used 
to playback the sample. I wonder if it wouldn' be faster to always compute
 a whole file, and save the modified bit to a temporary file. This way, the 
undo stack would give a way to reconstruct the file incrementally. The 
point here is to minimize disk seek times by always having the disk read 
thread read a single file... Imagine I have 70 tracks playing together, 
would I want the playback to constantly switch between 700 files ? I don't
think so... When the user clicks the undo button, another temp file is 
created, filled by the undo thread (which is separated from the playback 
thread) and a semaphore is released when the playback thread is allowed to 
switch to this new file (perhaps shorter or longer than the original)... As 
I'm 
explaining it, it *seems* better... But David obviously choose to describe a 
method like the first one.

** 2 **  Another issue... Let's assume my output buffer is floating point, 
should I convert EVERY working file to floating point BEFORE ever 
processing it (and save it to a temp file) in order to later mix the file 
data
within the output buffer without run-time conversion, or should I perform
run-time conversion... I can't clearly decide if doubling (16bit -> 32bit) 
the 
disk load and thus reducing the number of available tracks is better or worse 
than diminishing DSP performance by having each read buffer converted to 
float, sample by sample. RELATED : I thought of a way to store 16bit 
"numbers" in a special format where the data could bne OR'ed with an 
exponent mask to directly produce floating point values without calling the
float->int asm opcodes (assuming x86) ? Is it too weird ?


If it were up to me, I'd choose to read a single file per clip, and store non
-
destructive edit lists in separate files read only during undo operation... 
Playback must be fast...  Undo, we don't care... So why do mjor packages
 seem to use the many-files method ? Have I been misinformed ?

Regarding float/int, I'd go float, because I know I'll try to push the dsp 
tests to the max, while I don't think I'll reach the maximum number of
tracks anytime soon.

Any comments ?

Benjamin GOLINVAUX


From - Fri Oct 15 03:05:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA32676
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 17:43:45 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA17679 for linux-audio-dev-list; Thu, 14 Oct 1999 17:18:08 -0400
Received: from durham2-011.dsl.gtei.net (durham2-011.dsl.gtei.net [4.3.2.11]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA17676 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 17:18:05 -0400
Received: by durham2-011.dsl.gtei.net (Postfix, from userid 1000)
	id 313C3CB80E; Thu, 14 Oct 1999 16:16:10 -0400 (EDT)
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Linux-friendly MIDI interface boxes?
References: <Pine.GSU.4.10.9910131353470.29101-100000@schauder.mit.edu>
From: Michael Alan Dorman <mdorman@debian.org>
Date: 14 Oct 1999 16:16:10 -0400
In-Reply-To: Christopher Jeris's message of "Wed, 13 Oct 1999 14:00:45 -0400 (EDT)"
Message-ID: <871zax3dh1.fsf@juliet.private.net>
Lines: 13
User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 990080e21a647be7a6378e056f0ac505

Christopher Jeris <cjeris@math.mit.edu> writes:
> Has anyone out there had experience using any of the common MIDI interface
> boxes (Midiman, Mark of the Unicorn, Emagic, etc) with Linux?  Are any of
> them even sufficiently documented to write free software that supports
> them?

There is a BSD driver in some sort of shape for MOTU's PC Express.
There's a link to it on the Linux MIDI + Audio page.

It might be possible to port it.

Mike.

From - Fri Oct 15 03:06:01 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA11725
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 19:03:06 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA17875 for linux-audio-dev-list; Thu, 14 Oct 1999 18:42:07 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA17871 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 18:42:03 -0400
Received: from gardena.net ([194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id AAA06998;
	Fri, 15 Oct 1999 00:36:50 +0200
Received: from localhost (localhost [[UNIX: localhost]])
	by gardena.net (8.9.3/8.9.3) id XAA00568;
	Thu, 14 Oct 1999 23:22:47 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] atomic xchg
Date: Thu, 14 Oct 1999 23:20:13 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199910141522.LAA16936@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101423224600.00534@goblin.flashnet.it>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 8099a1901a329f5b4f43ae6bb86359f5

On Thu, 14 Oct 1999, Paul Barton-Davis wrote:
> In message <3870BF54.E9C7E4C9@response.cx>you write:
> >Why do u wish to do this -- is it a concurrency issue ??
> 
> yep. when an engine thread is writing to a set of output buffers, and
> another thread is reading from a different set of output buffers, i'd
> like to able to atomically swap the pointers to the buffer sets
> without a lock whenever the reader thread is all done. something like
> that.
> 
> that way, the engine thread can keep doing its stuff (as long its uses
> the pointer all the time and does not cache it, and declares it
> volatile) without having to constantly lock and unlock every time it
> wants to stuff data into the output buffer.
> 
> david has also pointed a potential (though not likely to be used) use
> for it with timestamping.

Paul make sure that we have a fallback solution (compile time) for CPU
architectures which do not provide these specialized asm instructions,
since it would be nice to run our audio engine on any powerful Linux
architecture ( Alpha, G4 PPC etc).

Benno.

From - Fri Oct 15 03:06:02 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA12223
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 19:06:43 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA17872 for linux-audio-dev-list; Thu, 14 Oct 1999 18:42:04 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA17867 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 18:42:00 -0400
Received: from gardena.net ([194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id AAA06995
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 00:36:47 +0200
Received: from localhost (localhost [[UNIX: localhost]])
	by gardena.net (8.9.3/8.9.3) id XAA00605
	for linux-audio-dev@ginette.musique.umontreal.ca; Thu, 14 Oct 1999 23:53:36 +0200
From: Benno Senoner <sbenno@gardena.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] more audio client/server considerations (client acts as engine)
Date: Thu, 14 Oct 1999 23:22:49 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <99101423533601.00534@goblin.flashnet.it>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: a314c1caffc1494184ca0d56e324f401

Hi,
some time ago Paul said it would be nice to run one client audio app
as engine for an other client app:

let's say: app1 provides a LP filter
and app2 wants to use this filter.
But this filter is running in app1's thread.
As long there is only a point to point comunication, it's ok for me,
but do you plan to allow arbitrary long chains ?
like app1 generates audio , then sends the data to app2 which applies
an LP filter and then app2 sends the result to app3 which applies
an EQ.

The problem could be latency  , since if one app fails to meet a deadline,
or maybe too many apps could cause  excessive scheduling overhead (but I'm
confident that with 10 running audio threads there are no major scheduling
problems).
The idiotic case could be a plugin chain made up of 10 plugins,
5 of them running on app1 (the ones in the even positions) , and the other 5
running on app2 (these in the odd positions),
That would cause 10 context switches for this chain.
run a few of these idiotic chains and the scheduling overhead will ruin
the whole CPU performance.
 
I think the ideal solution is still to have point to point comunication between 
clients (audio applications) and the audio server.

there could be two classes of clients:
1) the client process the audio/event data and hosts plugins in his own
thread, and sends only the final result (audio data / MIDI events) to the audio
server which mixes toghether/routes the data from/to the clients.

2) the client delegates most of functions to the engine,
the plugins are hosted in the engine thread, that means
audio data from the client is sent to the server and then processed by the 
plugin net of the engine, and then mixed/routed as with the clients in the 1)
case.


Now an additional question:
David said "sensor threads" should run at highest priority (to allow to preempt
the engine), to get accurate timestamping.

IMHO it would be better to run all timestamp sensitive sensor tasks (MIDI input
etc) in one single thread to reduce scheduling overhead.

Or are there good reasons for not going this way ?


So what would be a typical figure of the running threads in an enviroment
with MIDI in/out , PCM in/out , server engine, and one client app ?

threads sorted by priority , highest priority first

MIDI i/o thread :select()s on MIDI fds and reads/writes data to the event
system
server engine : read()/write() of PCM data, syncs with clients, processes
plugins and mix results toghether
client app: reads/writes PCM data/event data from/to the engine
(and of course does some processing on the data).

Note that with this priority scheme, a flawed MIDI out as the one on the
SB AWE64, could cause audio dropouts on the audio engine, since the
MIDI out driver does busywaiting.
But we assume that we run our engine on non-flawed hardware.

regards,
Benno.

From - Fri Oct 15 03:06:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA10323
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 18:52:49 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA17859 for linux-audio-dev-list; Thu, 14 Oct 1999 18:31:14 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA17856 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 18:31:11 -0400
Received: from localhost.localdomain (d212-151-105-184.swipnet.se [212.151.105.184]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA11477; 
          Fri, 15 Oct 1999 00:26:11 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] atomic xchg
Date: Fri, 15 Oct 1999 00:26:31 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910141522.LAA16936@renoir.op.net>
In-Reply-To: <199910141522.LAA16936@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101500331200.00435@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id AAA11477
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA10323
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ec85c812f93e8c6c7c5e1890e4cf76ee

On Thu, 14 Oct 1999, Paul Barton-Davis wrote:
> david has also pointed a potential (though not likely to be used) use
> for it with timestamping.

We still have a problem with 64 bit shared variables, so I wouldn't
say "the atomic tricks" are ruled out for the timestamping. Even if
we use unsigned int and some unit that's close to the sample rate,
that's just 25 hours of 48 kHz resolution...

And BTW, even if a single CPU instruction is used (add for example),
that's worth nothing on an SMP system. AFAIK, the bus works with
access granularity, and doesn't care about CPU instructions...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Oct 15 03:06:06 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA22022
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 20:09:14 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA18089 for linux-audio-dev-list; Thu, 14 Oct 1999 19:49:57 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA18086 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 19:49:54 -0400
Received: from localhost.localdomain (d212-151-105-184.swipnet.se [212.151.105.184]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA10984; 
          Fri, 15 Oct 1999 01:44:49 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Benjamin GOLINVAUX <golinvaux@benjamin.net>,
        Benjamin GOLINVAUX <golinvaux@benjamin.net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] cpu/disk tradeoff
Date: Fri, 15 Oct 1999 00:51:51 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <37F53112.5E122044@virginia.edu> <000356dcea8b6283_mailit@relay.eunet.be>
In-Reply-To: <000356dcea8b6283_mailit@relay.eunet.be>
MIME-Version: 1.0
Message-Id: <99101501515102.00435@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id BAA10984
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA22022
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 49d94e38a1a4786e6cc9bbe4ee11e1f2

On Thu, 14 Oct 1999, Benjamin GOLINVAUX wrote:
> and my dog (shame on my dog who still prefers fixed-point dsp).

Your dog is an asm die-hard, then...? :-)

> The 
> point here is to minimize disk seek times by always having the disk read 
> thread read a single file... Imagine I have 70 tracks playing together, 
> would I want the playback to constantly switch between 700 files ?

How would you get it that bad? 70 tracks == 70 files (unless you have
lots of very small clips that are spread all over the disk...), and
that's around 20-30 seeks/s with 3 s of buffering, for example.

Big advantage: You don't move data at all, and hence, edit operations
don't stress the disk while playing back.

One solution to the "many small clips" problem would be to have a
background optimizer daemon that creates new iles with the audio
data of these clips in sequential order. However, I doubt it'll be
much point, as small clips that are moved around are usually either

1) rythm tracks where the user (or some automatic tool)
   manipulated the timing slightly, or

2) rythm loops, where the clips are actually used as if
   the HDR was a sampler. Most of those clips will be
   reused many times in the song.

And, 1) won't make much of a difference, as the clips are just slided
a little, as opposed to heavily shuffeled around, which means that
the read buffering will smooth it to a sequential stream, just like a
single, long clip. 2) means that the total size of the clips doesn't
justify them being streamed from disk - a reasonably smart cache in
the streamer daemon should take care of this.

> I can't clearly decide if doubling (16bit -> 32bit)  the 
> disk load and thus reducing the number of available tracks is better or worse 
> than diminishing DSP performance by having each read buffer converted to 
> float, sample by sample.

The average hard disks is still pretty slow compared to the CPU, so
if you don't need the full float resolution, there's not much point
in doubling the HD load. However, 16 bits for recording isn't all
that much, so 16 bit files only is not the way to go. I've seen
applications that use 24 bits/sample in files...

> RELATED : I thought of a way to store 16bit 
> "numbers" in a special format where the data could bne OR'ed with an 
> exponent mask to directly produce floating point values without calling the
> float->int asm opcodes (assuming x86) ? Is it too weird ?

Nothing that works is too weird for a rather simple but important
task as this, but check out the FP instruction set of the CPU first.
A decent CPU *should* be able to do this efficiently without "dirty"
tricks. The real world frequently turns out to be just as bad as you
expected, though...

> If it were up to me, I'd choose to read a single file per clip, and store non
> -
> destructive edit lists in separate files read only during undo operation... 
> Playback must be fast...  Undo, we don't care... So why do mjor packages
>  seem to use the many-files method ? Have I been misinformed ?

Editing while playing back, no waiting for "commit", no waiting for
undo...

> Regarding float/int, I'd go float, because I know I'll try to push the dsp 
> tests to the max, while I don't think I'll reach the maximum number of
> tracks anytime soon.

That certainly makes more sense than going short int only, especially
considering the performance of HDs these days, 20 and 24 bit sound
cards, and Benno's multitrack streaming results.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Oct 15 03:06:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA15601
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 19:28:29 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA17958 for linux-audio-dev-list; Thu, 14 Oct 1999 19:05:59 -0400
Received: from flophouse.localnet (grib.customer.jump.net [216.30.103.2]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA17955 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 19:05:56 -0400
Received: by flophouse.localnet (Postfix, from userid 1000)
	id 49A728DE9; Thu, 14 Oct 1999 18:00:58 -0500 (CDT)
To: Benno Senoner <sbenno@gardena.net>
Cc: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] atomic xchg
References: <199910141522.LAA16936@renoir.op.net> <99101423224600.00534@goblin.flashnet.it>
From: Bill Gribble <grib@cs.utexas.edu>
Date: 14 Oct 1999 18:00:57 -0500
In-Reply-To: Benno Senoner's message of "Thu, 14 Oct 1999 23:20:13 +0200"
Message-ID: <87emexsg2e.fsf@flophouse.localnet>
Lines: 26
User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 346f7200a64027b0d64acfe69b90388c

Benno Senoner <sbenno@gardena.net> writes:
> On Thu, 14 Oct 1999, Paul Barton-Davis wrote:
> > yep. when an engine thread is writing to a set of output buffers, and
> > another thread is reading from a different set of output buffers, i'd
> > like to able to atomically swap the pointers to the buffer sets
> > without a lock whenever the reader thread is all done. something like
> > that.

Why is it so important to do it without a lock?  Mutexes just aren't
that expensive, and you WILL end up shooting yourself in the foot if
you try to get by without them.  You're talking about swapping
pointers in a double-buffered workspace... the amount of time to do
the "work" is going to far overwhelm the time to do a piddly
pthread_mutex_lock() / swap pointers / pthread_mutex_unlock().

> Paul make sure that we have a fallback solution (compile time) for CPU
> architectures which do not provide these specialized asm instructions,
> since it would be nice to run our audio engine on any powerful Linux
> architecture ( Alpha, G4 PPC etc).

...which is the best reason to use a standard API (POSIX threads) and
don't depend on hardware-specific tricks.  

Bill Gribble


From - Fri Oct 15 03:06:05 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA18029
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 19:44:17 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA18041 for linux-audio-dev-list; Thu, 14 Oct 1999 19:20:51 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id TAA18038 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 19:20:48 -0400
From: est@hyperreal.org
Received: (qmail 29215 invoked by uid 162); 14 Oct 1999 23:15:42 -0000
Message-ID: <19991014231542.29214.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] atomic xchg
In-Reply-To: <99101500331200.00435@localhost.localdomain> from David Olofson
 at "Oct 15, 1999 00:26:31 am"
To: David Olofson <audiality@swipnet.se>
Date: Thu, 14 Oct 1999 16:15:42 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: a11fe90c65733901576d9cd8fbac062f

David Olofson discourseth:
> 
> And BTW, even if a single CPU instruction is used (add for example),
> that's worth nothing on an SMP system. AFAIK, the bus works with
> access granularity, and doesn't care about CPU instructions...

Hmm..I think it does care if you use the lock prefix on the pentium,
or the similar mechanism on the ppc.  Still, I prefer to think of
anything other than pthread calls or read/writes of pointer/ints as
architecture-specific optimizations.

Eric

From - Fri Oct 15 03:06:18 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA29029
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 20:55:07 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA18169 for linux-audio-dev-list; Thu, 14 Oct 1999 20:32:50 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA18166 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 20:32:47 -0400
Received: from localhost.localdomain (d212-151-105-184.swipnet.se [212.151.105.184]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA12235; 
          Fri, 15 Oct 1999 02:27:46 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Benno Senoner <sbenno@gardena.net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] more audio client/server considerations (client acts as engine)
Date: Fri, 15 Oct 1999 01:57:54 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <99101423533601.00534@goblin.flashnet.it>
In-Reply-To: <99101423533601.00534@goblin.flashnet.it>
MIME-Version: 1.0
Message-Id: <99101502344803.00435@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id CAA12235
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA29029
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e6931e16169632084cc9d0b3797e182b

On Thu, 14 Oct 1999, Benno Senoner wrote:
> I think the ideal solution is still to have point to point communication between 
> clients (audio applications) and the audio server.

Too restrictive to be the only supported method, but yes, it should
definitely be the recommended way of writing applications that could
be useful in low latency cooperation with other applications.

It means the engine will have to be fast and flexible, but hey, if
it's not good enough, hack it and submit the patch! :-) But of course,
people will still limit the low latency performance of the whole
system by writing local engines. We just have to live with that,
until MCS is so tuned and computers so fast that it makes no sense
not to use it... Another order of magnitude heavier DSP, and the way
you move the data around is virtually irrelevant WRT performance, so a
few % worse than hard core custom shm IPC won't matter, if it brings
some advantages.

Oh, well; Marxism never worked too well either...

> there could be two classes of clients:
> 1) the client process the audio/event data and hosts plugins in his own
> thread, and sends only the final result (audio data / MIDI events) to the audio
> server which mixes together/routes the data from/to the clients.
> 
> 2) the client delegates most of functions to the engine,
> the plugins are hosted in the engine thread, that means
> audio data from the client is sent to the server and then processed by the 
> plugin net of the engine, and then mixed/routed as with the clients in the 1)
> case.

Two nice ways of doing it, 2) being the superior one WRT cooperative
system performance. 3) would be streaming data back and forth as you
pointed out will result in latency problems. However, 3) might be
very useful if you really want to use that cool application with
run-time compiled processing nets running in the application's engine,
or whatever, for processing some tracks in your HDR program. A few ms
of extra latency is far better than having to export/process/import,
or some other medieval high-tech solution... :-)

> Now an additional question:
> David said "sensor threads" should run at highest priority (to allow to preempt
> the engine), to get accurate timestamping.
> 
> IMHO it would be better to run all timestamp sensitive sensor tasks (MIDI input
> etc) in one single thread to reduce scheduling overhead.

AFAIK, it doesn't make a difference, except when multiple input
events occur at the same time. Sleeping threads are not checked by
the scheduler anyway... And packing multiple (unrelated) device
interfaces in one thread isn't exactly nice coding style.

> So what would be a typical figure of the running threads in an enviroment
> with MIDI in/out , PCM in/out , server engine, and one client app ?
> 
> threads sorted by priority , highest priority first
> 
> MIDI i/o thread :select()s on MIDI fds and reads/writes data to the event
> system
> server engine : read()/write() of PCM data, syncs with clients, processes
> plugins and mix results toghether
> client app: reads/writes PCM data/event data from/to the engine
> (and of course does some processing on the data).
> 
> Note that with this priority scheme, a flawed MIDI out as the one on the
> SB AWE64, could cause audio dropouts on the audio engine, since the
> MIDI out driver does busywaiting.

Uuurgh!! Amazing they still build that kind of crap. RTLinux can "fix"
it, but that's certainly *NOT* what it's meant for!

> But we assume that we run our engine on non-flawed hardware.

Yep. Rock solid, low latency audio with high accuracy MIDI input is
probably rather uninteresting to people that don't even want to pay a
few $ for a card with a decent MIDI interface. (Ok, throw in a low
prio, high jitter MIDI sensor thread for crappy sound cards if you
like... Better than the engine freaking out first thing for every
other Linux newbie.)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Oct 15 03:06:22 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA29903
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 21:00:27 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA18175 for linux-audio-dev-list; Thu, 14 Oct 1999 20:40:00 -0400
Received: from flophouse.localnet (grib.customer.jump.net [216.30.103.2]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA18172 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 20:39:58 -0400
Received: by flophouse.localnet (Postfix, from userid 1000)
	id DC3388DE9; Thu, 14 Oct 1999 19:35:00 -0500 (CDT)
To: Paul Barton-Davis <pbd@Op.Net>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] atomic xchg
References: <199910142356.TAA10951@renoir.op.net>
From: Bill Gribble <grib@cs.utexas.edu>
Date: 14 Oct 1999 19:35:00 -0500
In-Reply-To: Paul Barton-Davis's message of "Thu, 14 Oct 1999 20:51:51 -0400"
Message-ID: <874sftlavf.fsf@flophouse.localnet>
Lines: 16
User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 403dd58d113fdb7bfe8c96d043366d72

Paul Barton-Davis <pbd@Op.Net> writes:
> yes, but pthread_mutex_lock() doesn't spin at all. if the lock is
> held, your thread will go to sleep. on an MP system, this is a disaster.

I'm just not convinced that this is the case.  We're talking about
data rates in the several-MB-per-sec range here, and I just don't
believe that the latency of a thread sleep/wakeup is going to kill
you, particularly not if your system is designed to use a sensible
amount of buffering and POSIX RT scheduling priorities. 

Unless you have a smaller number of threads doing significant work
than you have CPUs on the system, you'll have to take a break
somewhere down the road anyway.  If someone else holds a lock you
need, well, I guess it's a good time to let another thread run.

Bill Gribble

From - Fri Oct 15 03:06:24 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA31463
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 21:09:14 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA18188 for linux-audio-dev-list; Thu, 14 Oct 1999 20:46:04 -0400
Received: from flophouse.localnet (grib.customer.jump.net [216.30.103.2]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA18185 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 20:46:02 -0400
Received: by flophouse.localnet (Postfix, from userid 1000)
	id D38518DE9; Thu, 14 Oct 1999 19:41:04 -0500 (CDT)
To: Paul Barton-Davis <pbd@Op.Net>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] cpu/disk tradeoff
References: <199910150009.UAA11795@renoir.op.net>
From: Bill Gribble <grib@cs.utexas.edu>
Date: 14 Oct 1999 19:41:04 -0500
In-Reply-To: Paul Barton-Davis's message of "Thu, 14 Oct 1999 21:04:44 -0400"
Message-ID: <87zoxljw0v.fsf@flophouse.localnet>
Lines: 18
User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 24c71ba4182ed847faefe68fcb067a27

Paul Barton-Davis <pbd@Op.Net> writes:
> 16 bit is completely inadequate for professsional audio intermediate
> storage and manipulation. Its adequate for the final result, IMHO, but
> thats not the same thing at all, as many people have pointed out.

Why not use 32-bit int for your intermediate results?  a 4-byte float
wastes a lot of its representational ability on numbers way, way
beyond the bounds of what you need to be able to operate on for audio.

If you're interested in serving even the semi-pro audio world, you
want to be able to handle 24-bit input and output.  Commodity machines
(ADAT/DA-38, plus any external A/D/A worth the bubble wrap it's
packaged in) are at least 20-bit these days, and most folks want
24-bit ability even though they're mainly getting random bits down
there (not to mention that a commercial recording with more than 
4 bits of dynamic range is an anomaly).

Bill Gribble

From - Fri Oct 15 03:06:23 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA31450
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 21:09:09 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA18195 for linux-audio-dev-list; Thu, 14 Oct 1999 20:47:24 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA18192 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 20:47:22 -0400
Received: from localhost.localdomain (d212-151-105-184.swipnet.se [212.151.105.184]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA26459; 
          Fri, 15 Oct 1999 02:42:21 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Linux-friendly MIDI interface boxes?
Date: Fri, 15 Oct 1999 02:44:00 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910150003.UAA11438@renoir.op.net>
In-Reply-To: <199910150003.UAA11438@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101502492304.00435@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id CAA26459
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA31450
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7eef158305b0b43457d74442c3198856

On Fri, 15 Oct 1999, Paul Barton-Davis wrote:
> note: the author notes that the MOTU box interrupts "quite often
> (every 256 microseconds)" .... :(

What the!? 256 s! Either you can time the bytes to some 1/4 ms
accuracy, or that interface is *seriously* flawed. Must be that it
has a UART that transfers a single byte for one channel at a time or
something...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Oct 15 03:06:13 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA23967
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 20:22:28 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA18112 for linux-audio-dev-list; Thu, 14 Oct 1999 20:01:12 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA18109 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 20:01:10 -0400
Received: from someip.ppp.op.net (d-bm3-1b.ppp.op.net [209.152.194.91]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id TAA10951 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 19:56:11 -0400 (EDT)
Message-Id: <199910142356.TAA10951@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] atomic xchg 
In-reply-to: Your message of "14 Oct 1999 18:00:57 CDT."
             <87emexsg2e.fsf@flophouse.localnet> 
Date: Thu, 14 Oct 1999 20:51:51 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f816a8ce88749bf1857a6b1814af566f

>Why is it so important to do it without a lock?  Mutexes just aren't
>that expensive, and you WILL end up shooting yourself in the foot if
>you try to get by without them.  

on an MP machine, mutexes are incredibly expensive if you block to
wait for a short-held spinlock.

most of the time i have such locks, i use my own implementation of
pthreads_mutex_spinlock()

int
pthread_spin_lock (pthread_mutex_t *mp)

{
#if NCPUS > 1

	int err;
	int i;

	i = SPINLIMIT;

	while (--i && ((err = pthread_mutex_trylock (mp)) == EBUSY))
		;
	
	if (i == 0) {
	    err = pthread_mutex_lock (mp);
	}

	return err;

#else 
	return pthread_mutex_lock (mp);

#endif NCPUS
}

SPINLIMIT needs to be tuned to match roughly the loop-cnt-per-thread
context switch time (Karlin et al, 1991).

				  You're talking about swapping
>pointers in a double-buffered workspace... the amount of time to do
>the "work" is going to far overwhelm the time to do a piddly
>pthread_mutex_lock() / swap pointers / pthread_mutex_unlock().

yes, but pthread_mutex_lock() doesn't spin at all. if the lock is
held, your thread will go to sleep. on an MP system, this is a disaster.

>> Paul make sure that we have a fallback solution (compile time) for CPU
>> architectures which do not provide these specialized asm instructions,
>> since it would be nice to run our audio engine on any powerful Linux
>> architecture ( Alpha, G4 PPC etc).
>
>...which is the best reason to use a standard API (POSIX threads) and
>don't depend on hardware-specific tricks.  

i don't know of any hardware that doesn't have an atomic exchange
operation. if there is, i can guarantee you that it doesn't support
POSIX threads either. compare-and-swap (CAS) is something else
altogether, and as cute as Herlihy's wait-free synchronization can be,
i would never suggest we use it because CAS doesn't exist for all
architectures. but you can't implement (sorry, use) *any* thread
system without an atomic exchange op.

you don't need locks in many situations where people typically still
use them - primarily single reader ones. for example, by using the
following outline, you can avoid a 99% of the lock acquisitions in an
engine thread that wants to check for new requests:

   atomic_t requests_pending;   /* /usr/src/linux/asm/atomic.h */
   pthread_mutex_lock request_lock;
   some_queue_type_t request_queue;
 
READER (engine):

	if (atomic_read (&requests_pending)) {
	     pthread_mutex_spinlock (&request_lock);
	     top = request_queue.pop ();
	     pthread_mutex_unlock (&request_lock);
        }	   

WRITER (requestor):

	pthread_mutex_spinlock (&request_lock);
	request_queue.push (req);
	atomic_inc (&requests_pending);
	pthread_mutex_unlock (&request_lock);
		  
This can be an enormous win on an MP machine - the engine thread will
almost never acquire the lock, and when it does, it knows for sure
that its about the be released "real soon now", so spinning makes a
lot of sense. with this scheme, requestor threads can stuff things
onto the queue knowing that they will not cause the engine thread to
block while they manipulate the queue.

for UP machines, this all comes out in the wash: you *want* the
threads to block. however, as several people on this list are
realizing, the incredibly low cost of dual CPU boxes presents a
compelling practical argument for proper support of SMP systems, even
if a desire for elegance did not :)

--p

From - Fri Oct 15 03:06:25 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA01035
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 21:22:31 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA18215 for linux-audio-dev-list; Thu, 14 Oct 1999 21:03:24 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA18212 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 21:03:21 -0400
Received: from localhost.localdomain (d212-151-105-184.swipnet.se [212.151.105.184]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA04187; 
          Fri, 15 Oct 1999 02:58:18 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Bill Gribble <grib@cs.utexas.edu>, Paul Barton-Davis <pbd@Op.Net>
Subject: Re: [linux-audio-dev] atomic xchg
Date: Fri, 15 Oct 1999 02:55:41 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <199910142356.TAA10951@renoir.op.net> <874sftlavf.fsf@flophouse.localnet>
In-Reply-To: <874sftlavf.fsf@flophouse.localnet>
MIME-Version: 1.0
Message-Id: <99101503052005.00435@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id CAA04187
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA01035
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0cd3bf055d5821968a5d52adc057db80

On Fri, 15 Oct 1999, Bill Gribble wrote:
> I'm just not convinced that this is the case.  We're talking about
> data rates in the several-MB-per-sec range here, and I just don't
> believe that the latency of a thread sleep/wakeup is going to kill
> you, particularly not if your system is designed to use a sensible
> amount of buffering and POSIX RT scheduling priorities. 

On the contrary, this is exactly the problem we're dealing with. Low
latency real time processing by definition means low buffering. This
is why I originally intended to support user space SCHED_FIFO only for
debugging purposes and non-critical applications. The *real*
implementation would use RTLinux... There, I have _worst case_
scheduling jitter less than a single sample period, while SHED_FIFO -
despite Ingo's great work - is still just good enough for reliable
real time audio. Latency is certainly not low enough for multiplying
with some factor 2 or more.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Oct 15 03:06:15 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA24657
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 20:27:00 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA18136 for linux-audio-dev-list; Thu, 14 Oct 1999 20:08:39 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA18133 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 20:08:36 -0400
Received: from someip.ppp.op.net (d-bm3-1b.ppp.op.net [209.152.194.91]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id UAA11438 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 20:03:38 -0400 (EDT)
Message-Id: <199910150003.UAA11438@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Linux-friendly MIDI interface boxes? 
In-reply-to: Your message of "14 Oct 1999 16:16:10 EDT."
             <871zax3dh1.fsf@juliet.private.net> 
Date: Thu, 14 Oct 1999 20:59:17 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 00f48cfc716e731012c14c4a3f91486d

>There is a BSD driver in some sort of shape for MOTU's PC Express.
>There's a link to it on the Linux MIDI + Audio page.

Sorry for not mentioning that. I had thought for some reason it was
for a MOTU audio interface.

note: the author notes that the MOTU box interrupts "quite often
(every 256 microseconds)" .... :(

From - Fri Oct 15 03:06:16 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA26073
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 20:35:33 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA18142 for linux-audio-dev-list; Thu, 14 Oct 1999 20:14:05 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA18139 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 20:14:03 -0400
Received: from someip.ppp.op.net (d-bm3-1b.ppp.op.net [209.152.194.91]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id UAA11795 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 20:09:04 -0400 (EDT)
Message-Id: <199910150009.UAA11795@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] cpu/disk tradeoff 
In-reply-to: Your message of "Thu, 14 Oct 1999 22:09:17 +0200."
             <000356dcea8b6283_mailit@relay.eunet.be> 
Date: Thu, 14 Oct 1999 21:04:44 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: a55be9ef86465bc9f0bd6c373c90fcef

>Another issue... Let's assume my output buffer is floating point,
>should I convert EVERY working file to floating point BEFORE ever
>processing it (and save it to a temp file) in order to later mix the
>file data within the output buffer without run-time conversion, or
>should I perform run-time conversion... I can't clearly decide if
>doubling (16bit -> 32bit) the disk load and thus reducing the number
>of available tracks is better or worse than diminishing DSP
>performance by having each read buffer converted to float, sample by
>sample.

my new program hdr works entirely with sample_t's, which are currently
typedef'ed to be floats. it only deals with 16 bit data at its inputs
and outputs - every where else in the data path, and in its own disk
files that it writes as a sort of equivalent of a tape, we use floats.

16 bit is completely inadequate for professsional audio intermediate
storage and manipulation. Its adequate for the final result, IMHO, but
thats not the same thing at all, as many people have pointed out.

>RELATED : I thought of a way to store 16bit 
>"numbers" in a special format where the data could bne OR'ed with an 
>exponent mask to directly produce floating point values without calling the
>float->int asm opcodes (assuming x86) ? Is it too weird ?

why would you want to do this ? why not just use float all the way
until you ship the data to a 16-bit requiring destination (e.g. most
soundcards) ?

From - Fri Oct 15 03:06:27 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA02351
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 21:31:58 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA18238 for linux-audio-dev-list; Thu, 14 Oct 1999 21:13:21 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA18235 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 21:13:19 -0400
Received: from localhost.localdomain (d212-151-105-184.swipnet.se [212.151.105.184]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id DAA22051; 
          Fri, 15 Oct 1999 03:08:16 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Bill Gribble <grib@cs.utexas.edu>, Paul Barton-Davis <pbd@Op.Net>
Subject: Re: [linux-audio-dev] cpu/disk tradeoff
Date: Fri, 15 Oct 1999 03:05:59 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <199910150009.UAA11795@renoir.op.net> <87zoxljw0v.fsf@flophouse.localnet>
In-Reply-To: <87zoxljw0v.fsf@flophouse.localnet>
MIME-Version: 1.0
Message-Id: <99101503151706.00435@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id DAA22051
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA02351
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: db554a374c60a78fffcd1396528fe20b

On Fri, 15 Oct 1999, Bill Gribble wrote:
> Why not use 32-bit int for your intermediate results?  a 4-byte float
> wastes a lot of its representational ability on numbers way, way
> beyond the bounds of what you need to be able to operate on for audio.

1) Normalizing is expensive and needs a "level stamp"
   for every buffer. Great fun when adapting buffer
   sizes accross sub nets and clients... *not*

2) Why convert back and forth all the time?

> If you're interested in serving even the semi-pro audio world, you
> want to be able to handle 24-bit input and output.  Commodity machines
> (ADAT/DA-38, plus any external A/D/A worth the bubble wrap it's
> packaged in) are at least 20-bit these days, and most folks want
> 24-bit ability even though they're mainly getting random bits down
> there (not to mention that a commercial recording with more than 
> 4 bits of dynamic range is an anomaly).

Well, analog noise sounds better than digital quantization
distortion to most people... And, good audio cards *do* have better
than 96 dB SNR and dynamic range, and that's very helpful when
recording. You don't have to adjust the recording level all the time
to stay within -3 dB.

So, yes, >16 bits makes sense. And, it's also the new over-hyped
upcoming standard, so you just gotta' do it anyway...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Oct 15 03:06:20 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA29145
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 20:55:51 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA18163 for linux-audio-dev-list; Thu, 14 Oct 1999 20:31:25 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA18159 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 20:31:23 -0400
Received: from someip.ppp.op.net (d-bm3-1b.ppp.op.net [209.152.194.91]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id UAA12929 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 20:26:24 -0400 (EDT)
Message-Id: <199910150026.UAA12929@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] more audio client/server considerations (client acts as engine) 
In-reply-to: Your message of "Thu, 14 Oct 1999 23:22:49 +0200."
             <99101423533601.00534@goblin.flashnet.it> 
Date: Thu, 14 Oct 1999 21:22:04 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: aae8ab91c66b99e98ad704952fbc7908

>The idiotic case could be a plugin chain made up of 10 plugins, 5 of
>them running on app1 (the ones in the even positions) , and the other
>5 running on app2 (these in the odd positions), That would cause 10
>context switches for this chain.  run a few of these idiotic chains
>and the scheduling overhead will ruin the whole CPU performance.

I certainly agree that this is a silly case, but I also think that our
system should *allow* for this configuration. I would hope that most
people would not use it.

>there could be two classes of clients: 
>1)the client process the audio/event data and hosts plugins in his own
>thread, and sends only the final result (audio data / MIDI events)
>to the audio server which mixes toghether/routes the data from/to
>the clients.
>
>2) the client delegates most of functions to the engine,
>the plugins are hosted in the engine thread, that means
>audio data from the client is sent to the server and then processed by the 
>plugin net of the engine, and then mixed/routed as with the clients in the 1)
>case.

i think there is a lot of confusion here about what an engine thread
is. *ANY* application can run an engine thread, not just a
"server". an engine thread is essentially just a framework for event
distribution, providing time information, and building/executing
processing nets made up of plugins (function calls). 

anyway, this scheme should also work under our system, but again, i
would like to leave it up to the user to determine the configuration
that that adopt for any particular situation.

>IMHO it would be better to run all timestamp sensitive sensor tasks
>(MIDI input etc) in one single thread to reduce scheduling overhead.

>Or are there good reasons for not going this way ?

no, this is the way to go. the plural on "sensor threads" is my
fault. i meant it in a semantic sense, rather than an implementation
detail. 

i imagine that an implementation would use something similar to the
GTK/XForms/Qt I/O callback registration systems, whereby you register
a function to be run whenever a certain I/O condition is true for a
given file descriptor.
      
      void func (int fd, int condition, void *arg)
      {
		/* something happened to fd ... deal with it */
      }

      register_io_callback (some_fd, func, some_arg, IO_READABLE);
      register_io_callback (some_fd, some_other_func, some_arg, IO_WRITABLE);

etc. 

Need I add that Quasimodo does exactly this ? :)

--p

From - Fri Oct 15 03:06:28 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA05437
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 21:53:46 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA18259 for linux-audio-dev-list; Thu, 14 Oct 1999 21:35:19 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA18256 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 21:35:16 -0400
Received: from someip.ppp.op.net (d-bm3-1b.ppp.op.net [209.152.194.91]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id VAA17153 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 21:30:13 -0400 (EDT)
Message-Id: <199910150130.VAA17153@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] cpu/disk tradeoff 
In-reply-to: Your message of "14 Oct 1999 19:41:04 CDT."
             <87zoxljw0v.fsf@flophouse.localnet> 
Date: Thu, 14 Oct 1999 22:25:53 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: dc3e11380a010dd6a499237839c7c71d

In message <87zoxljw0v.fsf@flophouse.localnet>you write:
>Paul Barton-Davis <pbd@Op.Net> writes:
>> 16 bit is completely inadequate for professsional audio intermediate
>> storage and manipulation. Its adequate for the final result, IMHO, but
>> thats not the same thing at all, as many people have pointed out.
>
>Why not use 32-bit int for your intermediate results?  a 4-byte float
>wastes a lot of its representational ability on numbers way, way
>beyond the bounds of what you need to be able to operate on for audio.

my main reason is the cost on the Pentium of converting back and
forth. but i have also read compelling arguments on why
float makes sense over on the Csound mailing list.

[ aside: are people here familiar with our benchmarking of short/float
  conversion on the Csound list earlier this year ? Ed Hall managed to
  speed up a simple "how many table-driven sine wave oscillators can
  we support on a CPU" benchmark. The primary speedup came from
  getting rid of short/float conversions. The speedup was
  incredible. The original version of the program could do about 40
  oscillators on my PII-450 (its single-threaded); Ed's final version
  could do more than 500! It was also interesting to notice how vastly
  superior the MIPS processor was: about 5 times as fast as its clock
  speed equivalent Pentium-II. 
]

>If you're interested in serving even the semi-pro audio world, you
>want to be able to handle 24-bit input and output.  

that happens at a different level. handling ADAT data that is
streaming in from a tape is done by (1) a device driver and then (2)
one of hdr's "source" objects. The source provides float data to
anyone who reads data from it. the same thing would apply if we were
streaming to tape (not an imagined use for the program "hdr", but not
impossible), it would be handled by (1) a destination object and then
(2) a device driver. The destination accepts float data, and
eventually sends out whatever the device needs.

--p


From - Fri Oct 15 03:06:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA07143
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 22:05:09 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA18273 for linux-audio-dev-list; Thu, 14 Oct 1999 21:46:11 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA18270 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 21:46:09 -0400
Received: from someip.ppp.op.net (d-bm3-1b.ppp.op.net [209.152.194.91]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id VAA17961 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 21:41:10 -0400 (EDT)
Message-Id: <199910150141.VAA17961@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] atomic xchg 
In-reply-to: Your message of "14 Oct 1999 19:35:00 CDT."
             <874sftlavf.fsf@flophouse.localnet> 
Date: Thu, 14 Oct 1999 22:36:51 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5af07ad916606a1cab0836ec83d132cf

>I'm just not convinced that this is the case.  We're talking about
>data rates in the several-MB-per-sec range here, and I just don't
>believe that the latency of a thread sleep/wakeup is going to kill
>you, particularly not if your system is designed to use a sensible
>amount of buffering and POSIX RT scheduling priorities. 

"sensible amount of buffering" ? I'm buffering 64 samples to provide
about 1ms of buffer time at a 48KHz sample rate, mono (half that if
the card is stereo, which it probably is). Going to sleep, waiting for
some other thread to get SIG<whatever-it-is-that-pthreads-is-using-this-week>
and wake up again to acquire the lock doesn't take anything like 1ms,
but it does take a substantial fraction of time i would otherwise have
spent doing computation on the 64 samples. 

look, "spin-then-block" has been known for at least a decade to be the
right implementation of mutexes on MP systems. you can go back and dig
up Karlin's papers if you want to read more. it just so happens that
for some reason, pthreads doesn't provide pthread_mutex_spinlock(),
but insteads provides all the pieces you need to build it.

>Unless you have a smaller number of threads doing significant work
>than you have CPUs on the system, you'll have to take a break
>somewhere down the road anyway.  If someone else holds a lock you
>need, well, I guess it's a good time to let another thread run.

yes, but *NOT* just because i want to check an event queue! certainly,
a SCHED_FIFO thread had better sleep at some point, but on an MP
system, its not right for this to happen just because it wants a
resource that has a lock around it. if the lock is only held for a
short time by another thread on another processor, then i want the
lock-acquiring thread to keep running until it gets the lock, and then
keep going after that.

From - Fri Oct 15 14:42:14 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA25636
	for <slinkp@ulster.net>; Fri, 15 Oct 1999 12:33:42 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA23402 for linux-audio-dev-list; Fri, 15 Oct 1999 11:50:11 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id LAA23399 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 11:50:08 -0400
From: est@hyperreal.org
Received: (qmail 2593 invoked by uid 162); 15 Oct 1999 15:44:34 -0000
Message-ID: <19991015154434.2592.qmail@hyperreal.org>
Subject: [linux-audio-dev] floats vs. ints
In-Reply-To: <199910150130.VAA17153@renoir.op.net> from Paul Barton-Davis at
 "Oct 14, 1999 10:25:53 pm"
To: Paul Barton-Davis <pbd@Op.Net>
Date: Fri, 15 Oct 1999 08:44:34 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 560443adbd56ecd8da033b47f625cc44

Paul Barton-Davis discourseth:
> In message <87zoxljw0v.fsf@flophouse.localnet>you write:
> 
> my main reason is the cost on the Pentium of converting back and
> forth. but i have also read compelling arguments on why
> float makes sense over on the Csound mailing list.

Can you summarize?  I can certainly think of some arguments. :) I was
just checking out some code I wrote exactly a year ago.  I must have
just got my soundcard working under linux as I was benchmarking
int/float/double operations.  As soon as I saw float was quite viable,
I was happy to bid ints goodbye.  That was a pleasant change in some
ancient (80s!) assumptions of mine.

> [ aside: are people here familiar with our benchmarking of short/float
>   conversion on the Csound list earlier this year ?

You may remeber my posting to LAD a while ago reporting something like
a 10-fold speedup of float<->int16 conversion by doing it via 3dnow.
That was using float<->int32 operations + some regular x86 asm.  The k7
has added float<->int16 operations which would speed it up even more.
Apparently the k6-2 has these as well, though they're `undocumented'.

Eric

From - Fri Oct 15 14:42:16 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA25638
	for <slinkp@ulster.net>; Fri, 15 Oct 1999 12:33:43 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA23412 for linux-audio-dev-list; Fri, 15 Oct 1999 11:53:53 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA23409 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 11:53:50 -0400
Received: from op.net (d-bm3-0f.ppp.op.net [209.152.194.79]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id LAA26710 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 11:48:47 -0400 (EDT)
Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id MAA29560; Fri, 15 Oct 1999 12:44:36 -0400
Date: Fri, 15 Oct 1999 12:44:36 -0400
Message-Id: <199910151644.MAA29560@op.net>
From: Paul Barton-Davis <pbd@Op.Net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] multiple files/single files for HDR: my verdict
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: a26b4c93f3de8c2f32ae2fbcb5554418

i just noticed a nice trick that arises from use multiple files for
multitrack HDR. 

suppose you're currently only have a single input channel. ideally, to
minimize load on the disk subsystem and scheduling jitter, you'd like
to to only write a single output channel. if you interleave the
channel data, you can't do this, but if you use one fd per track you
can.

but the trick is even cooler (or it feels that way right now). as you
may know, lseek (fd, some-value-beyond-size-of-file, SEEK_SET) will
result in a zero-filled block if the file is subsequently written to
after the seek.

so ... when you add a new input channel/punch in a track, if you keep
track of where the one that is already running is writing to, you can
just seek there, and start writing. instant sync. this makes
punch-in/punch-out very efficient (though you may have to extend the
track files on closing if you punched-out and never punched-in again,
just to make sure they are all the same length. lseek() is your friend
here too.

this means that you can fire up "hdr", for example, with the potential
to record as many tracks as your system can handle, but only actually
use the bandwidth necessary for the number of tracks currently being
sent to disk.

perhaps this is all totally obvious to you, but it wasn't to me, and
it took me a little while to get it to work with multiple threads. but
now it does, and it seems very nice.

--p
  
ps. simple demo:
  
    tapedevice = new TapeDevice (48); /* track maximum */
    tapedevice->load_tape ("my-session");
    tapedevice->run ();

    /* at this point a writer thread is sleeping, waiting for work to
       do. Later, the main thread does:
     */

    tapedevice->write (mybuffer, nframes, track_number, Sound::float32);
    
    /* in a tightly-synced program like HDR, where all the input/output 
       channels are processed in a loop, we call ...
     */

    tapedevice->flush ()

     /* ... for each iteration around the main loop. This will wake up
        the writer thread if 1 or more tracks have more than
        frame_write_threshold frames pending.

        Then we do output to our soundcard(s), which will put us to
	sleep for a little bit, and let the tape writer thread run (on
	a UP system, anyway).

	Alternatively, the device can be set to flush automatically 
        every time the amount of pending frames exceeds a certain
        threshold. This would be more appropriate for single threaded
	programs and/or those without a tight "DSP-like" central loop.
      */

Coming soon to a tarfile near you.



From - Fri Oct 15 14:42:20 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA10162
	for <slinkp@ulster.net>; Fri, 15 Oct 1999 14:24:10 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA23710 for linux-audio-dev-list; Fri, 15 Oct 1999 13:55:10 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA23706 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 13:55:07 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46269AbPJORts>; Fri, 15 Oct 1999 20:49:48 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <199910151644.MAA29560@op.net> (message from Paul Barton-Davis on
	Fri, 15 Oct 1999 12:44:36 -0400)
Subject: Re: [linux-audio-dev] multiple files/single files for HDR: my verdict
Message-Id: <19991015174948Z46269-564+257@nic.funet.fi>
Date:   Fri, 15 Oct 1999 20:49:48 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 9c0e222c6ee8c9dcaa000f9c46fd8b06

>From:   Paul Barton-Davis <pbd@Op.Net>
>
>may know, lseek (fd, some-value-beyond-size-of-file, SEEK_SET) will
>result in a zero-filled block if the file is subsequently written to
>after the seek.

You are going to record silence as well? 50 tracks will then take
quite a much space even practically most of the tracks will be mostly
silent. The editlist would be better.

And is floating point 0 the same as 0x00000000? 

PS. did anyone read the abbott paper I made available?

Yours,

Juhana

From - Fri Oct 15 14:42:18 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA06147
	for <slinkp@ulster.net>; Fri, 15 Oct 1999 13:57:38 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA23669 for linux-audio-dev-list; Fri, 15 Oct 1999 13:24:47 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA23666 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 13:24:44 -0400
Received: from someip.ppp.op.net (d-bm3-0e.ppp.op.net [209.152.194.78]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id NAA05137 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 13:19:42 -0400 (EDT)
Message-Id: <199910151719.NAA05137@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: floats vs. ints 
In-reply-to: Your message of "Fri, 15 Oct 1999 08:44:34 PDT."
             <19991015154434.2592.qmail@hyperreal.org> 
Date: Fri, 15 Oct 1999 14:15:32 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: d3cc7a5b06e1ea2b966ef2bf6cab7c67

>> In message <87zoxljw0v.fsf@flophouse.localnet>you write:
>> 
>> my main reason is the cost on the Pentium of converting back and
>> forth. but i have also read compelling arguments on why
>> float makes sense over on the Csound mailing list.
>
>Can you summarize?

the most compelling ones seem to me to be:

1) 
    short sample_buffer_1[1024];
    short sample_buffer_2[1024];
    short output_buffer[1024];

    ... fill sample_buffer_1 with extremely loud noise ...
    ... fill sample_buffer_2 with extremely loud noise ...
    
    ... mix sample_buffer_{1,2} into output_buffer ...

    In this scenario, you will either have to accept clipping or do
    soft-limit (logarithmic) truncation like Apogee or use an
    intermediate representation (float?)  for every sample of every
    buffer pair at every place where two of them are mixed
    together. If you use float as the buffer type, you can basically
    forget about it: you have close to infinite headroom for all
    practical purposes.

2) on contemporary CPU's, float arithmetic is normally faster than integer.

3) a variant on (1): consider a plugin/function that does various
   multiplicative transforms on its data before compressing it all
   back down to a reasonable dynamic range. this can only be done
   safely with float, so why introduce yet another int16<->float
   requirement ?

4) audio generation/processing often makes heavy use of trig functions
   and other math library stuff, all of which require floating point
   arguments. if you want to know sin(x), why make the compiler do
   yet another int16->float->int16 conversion, when you could just
   make x a float ? a similar situation applies to any sample
   processing involving division, which can unnaturally truncate the
   result if done with integers.

--p

From - Sat Oct 16 02:47:58 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA17029
	for <slinkp@ulster.net>; Fri, 15 Oct 1999 15:10:21 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA23805 for linux-audio-dev-list; Fri, 15 Oct 1999 14:41:35 -0400
Received: from heroine.tampa.fl.us (alpha-iota97.resnet.usf.edu [131.247.220.97]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id OAA23802 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 14:41:32 -0400
Received: (qmail 23209 invoked from network); 15 Oct 1999 18:22:38 -0000
Received: from localhost (HELO earthling.net) (root@127.0.0.1)
  by localhost with SMTP; 15 Oct 1999 18:22:38 -0000
Message-ID: <380770EE.7F36AB43@earthling.net>
Date: Fri, 15 Oct 1999 14:22:38 -0400
From: Adam Williams <broadcast@earthling.net>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] floats vs. ints
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 548862b636271df0ad03a73f9bf29cca

On a 550Mhz computer, almost the lowest you can get nowadays, a 74
reflection reverb for 44100 2 channel audio in doubles uses about 25% of
the CPU time.  Conversion of 44100 2 channel audio from ints to floats,
2 additions, limiting, and conversion back to ints uses about 5%.  The
only reason to use ints is if you want to learn integer techniques,
which can be interesting in itself, but if you want your software used
as an audio tool you'll reduce your workload and drastically improve
quality using floats.
-- 
                               Heroine Virtual
                        freeyellow.com/members4/heroine
                      Render the impossible into reality

From - Sat Oct 16 02:48:03 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA26772
	for <slinkp@ulster.net>; Fri, 15 Oct 1999 16:11:24 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA23914 for linux-audio-dev-list; Fri, 15 Oct 1999 15:41:22 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA23911 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 15:41:20 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46602AbPJOTgG>; Fri, 15 Oct 1999 22:36:06 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <3807AF73.E6CCD276@alphalink.com.au> (message from Andrew Clausen
	on Fri, 15 Oct 1999 18:49:23 -0400)
Subject: Re: [linux-audio-dev] multiple files/single files for HDR: my verdict
Message-Id: <19991015193613Z46602-564+260@nic.funet.fi>
Date:   Fri, 15 Oct 1999 22:36:06 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5c3be5fb279cad1c51fe4b37e793ff45

>From:   Andrew Clausen <clausen@alphalink.com.au>
>
>Juhana Sadeharju wrote:
>> You are going to record silence as well?
>
>Why not exploit holes?

I don't understand, please explane what do you mean.

Yours,

Juhana

From - Sat Oct 16 02:48:06 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA28043
	for <slinkp@ulster.net>; Fri, 15 Oct 1999 16:20:04 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA23971 for linux-audio-dev-list; Fri, 15 Oct 1999 15:58:28 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA23968 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 15:58:25 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46357AbPJOTxC>; Fri, 15 Oct 1999 22:53:02 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <199910151910.PAA16439@renoir.op.net> (message from Paul
	Barton-Davis on Fri, 15 Oct 1999 16:06:20 -0400)
Subject: Re: [linux-audio-dev] multiple files/single files for HDR: my verdict
Message-Id: <19991015195305Z46357-563+253@nic.funet.fi>
Date:   Fri, 15 Oct 1999 22:53:02 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d9339b3d8b00acd7da24fbd82befa002

>From:   Paul Barton-Davis <pbd@Op.Net>
>
>remember: this is meant to be the equivalent of an ADAT and a mixing
>console. its not meant to be anything like any of the myriad of

Ok. But I think using lseek() is a kludge because the file systems
"editlist" just is not equivalent to audio editlist.

Yours,

Juhana

From - Sat Oct 16 02:48:01 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA22989
	for <slinkp@ulster.net>; Fri, 15 Oct 1999 15:45:05 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA23868 for linux-audio-dev-list; Fri, 15 Oct 1999 15:15:34 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA23865 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 15:15:32 -0400
Received: from someip.ppp.op.net (d-bm3-0e.ppp.op.net [209.152.194.78]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id PAA16439 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 15:10:30 -0400 (EDT)
Message-Id: <199910151910.PAA16439@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] multiple files/single files for HDR: my verdict 
In-reply-to: Your message of "Fri, 15 Oct 1999 20:49:48 +0300."
             <19991015174948Z46269-564+257@nic.funet.fi> 
Date: Fri, 15 Oct 1999 16:06:20 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e81cb3fa42dbacabf806569717d1419d

Juhana writes:

>>may know, lseek (fd, some-value-beyond-size-of-file, SEEK_SET) will
>>result in a zero-filled block if the file is subsequently written to
>>after the seek.
>
>You are going to record silence as well? 50 tracks will then take
>quite a much space even practically most of the tracks will be mostly
>silent. The editlist would be better.

three points: they won't be mostly silent. the whole point is that no
track gets recorded unless some stuff is written to it. ah, you say,
but that means that if i write 10 secs of sound to track 4 in the
middle of a 1 hour session, i get a 1 hour track instead of a 10 sec
one.  You might think that this was obviously true, but read on ...

second and rather more importantly, this is where a subtlety of the
ext2fs comes into play. I didn't mention this because its not part of
the POSIX lseek spec, but when you do a seek like this on ext2fs, it
doesn't allocate any disk blocks. its called a hole. You can therefore
create a file with oodles of empty space and have it take (roughly)
only the disk blocks needed for the recorded data. this works even if
you punch in and out *a lot*. Note: you can't see this with ls(1).

finally, by using an editlist, you require a particular program or
library to play back the data. the files i am creating can be
converted by sox into regular .wav or .aiff files, or read by any
program than can open a file and read binary IEEE 32 bit floats from
it. since my program is an HDR, not a soundfile editor, i don't want
to force an editlist API on anything that I might want to use to
manipulate the recorded data. besides, as described above, ext2fs has
its own built-in equivalent of a rudimentary editlist, and its
intimately coupled with the whole disk subsystem - i'd rather use
that.

remember: this is meant to be the equivalent of an ADAT and a mixing
console. its not meant to be anything like any of the myriad of
soundfile editors out there. the functions are sufficiently different
that i prefer using a different program for each task.

>And is floating point 0 the same as 0x00000000? 

yes. -0 is not the same, but its a distinction that doesn't bother me :)

See: http://pscinfo.psc.edu/general/software/packages/ieee/ieee.html 

--p

From - Sat Oct 16 02:48:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA32013
	for <slinkp@ulster.net>; Fri, 15 Oct 1999 16:45:31 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA24063 for linux-audio-dev-list; Fri, 15 Oct 1999 16:17:58 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA24060 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 16:17:32 -0400
Received: from localhost.localdomain (d212-151-36-248.swipnet.se [212.151.36.248]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id WAA02701; 
          Fri, 15 Oct 1999 22:12:18 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] cpu/disk tradeoff
Date: Fri, 15 Oct 1999 22:07:20 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910150130.VAA17153@renoir.op.net>
In-Reply-To: <199910150130.VAA17153@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101522192200.00510@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id WAA02701
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id QAA32013
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 6924a46e844fe62f75d1b3d0fa19397d

>   "It was also interesting to notice how vastly
>   superior the MIPS processor was: about 5 times as fast as its clock
>   speed equivalent Pentium-II."

*hehe*

*drewl*

Well, it looks like x86 CPUs aren't very cost effective these days,
at least not when you put some *serious* load on them. They're
pretty OK for waiting for harddrive DMA and shuffling buffers around,
though.

(OK, I'm probably still going to buy a dual Celeron 500 or something
as an X workstation + test system for now, but I'll consider other
CPUs - rather than building an "RT-Beowulf" - if/when I need that much
power.)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Oct 16 02:48:12 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA01997
	for <slinkp@ulster.net>; Fri, 15 Oct 1999 16:59:55 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA24295 for linux-audio-dev-list; Fri, 15 Oct 1999 16:31:36 -0400
Received: from alsa.alsa-project.org (alsa.jcu.cz [160.217.1.49]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA24292 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 16:31:30 -0400
Received: from localhost (andy@localhost)
	by alsa.alsa-project.org (8.8.8/8.8.8) with ESMTP id WAA12474;
	Fri, 15 Oct 1999 22:26:08 +0200
Date: Fri, 15 Oct 1999 22:26:08 +0200 (MEST)
From: Andy Lo A Foe <andy@alsa-project.org>
To: Paul Barton-Davis <pbd@Op.Net>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] audio interference or ... ?
In-Reply-To: <199910152044.QAA31199@op.net>
Message-ID: <Pine.LNX.4.05.9910152221050.12322-100000@alsa.alsa-project.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1f9d3136597b745a15c071956dd38061

On Fri, 15 Oct 1999, Paul Barton-Davis wrote:

> do you think it reasonable to conclude that this is caused by video
> noise ? or is there still some chance that scheduling nonsense caused
> by the X server needing to run may be to blame ? any suggestions on
> how to figure it out ? for what its worth, increasing the frames
> processed per cycle from 64 to 1024 makes no apparent difference in
> the noise.

Well, if I put my amp on a high enough level I can hear keyboard events,
mouse events, graphics operation and hard disk access through my
speakers :)  I'm not sure I had this problem with my AWE64 Gold, have
to check it. My card is Trident 4DWave NX, analog output used.

Andy
--
AlsaPlayer, http://www.alsa-project.org/~andy/

From - Sat Oct 16 02:48:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id CAA32409
	for <slinkp@ulster.net>; Sat, 16 Oct 1999 02:12:37 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id BAA28908 for linux-audio-dev-list; Sat, 16 Oct 1999 01:38:16 -0400
Received: from mail.cid.net (cephyr.cid.net [195.35.45.193]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA28905 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 16 Oct 1999 01:38:13 -0400
Received: from uucp by mail.cid.net (Exim 2.11) with local-bsmtp
	id 11cMSv-0001HQ-01; Sat, 16 Oct 1999 07:33:13 +0200
Received: from deneb.cygnus.argh.org ([192.168.1.2])
	by cygnus.argh.org with esmtp (Exim 3.02 #1)
	id 11cEC6-0001ne-00; Fri, 15 Oct 1999 22:43:18 +0200
Received: from fw by deneb.cygnus.argh.org with local (Exim 3.02 #1)
	id 11cEC5-0002lK-00; Fri, 15 Oct 1999 22:43:17 +0200
To: David Olofson <audiality@swipnet.se>
Cc: Benjamin GOLINVAUX <golinvaux@benjamin.net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] non-destructive editing
References: <0003566e187af433_mailit@relay.eunet.be> <99100920565801.00456@localhost.localdomain>
From: Florian Weimer <fw@deneb.cygnus.argh.org>
Date: 15 Oct 1999 22:43:17 +0200
In-Reply-To: David Olofson's message of "Sat, 9 Oct 1999 20:17:18 +0200"
Message-ID: <87iu48icd6.fsf@deneb.cygnus.argh.org>
Lines: 8
User-Agent: Gnus/5.07009701 (Pterodactyl Gnus v0.97.1) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 6edb79cdc1f4dff72533b74a88af1d76

David Olofson <audiality@swipnet.se> writes:

> BTW, does anyone know of a fs that allows removing blocks in the middle of
> files? (It's possible to do, but I'm not sure I would want to see the
> resulting mess... :-)

reiserfs does this, AFAIK.  According to the last things I've heard
about it, it's quite stable already.

From - Sat Oct 16 02:48:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA27434
	for <slinkp@ulster.net>; Fri, 15 Oct 1999 16:15:59 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA23928 for linux-audio-dev-list; Fri, 15 Oct 1999 15:53:55 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA23925 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 15:53:53 -0400
Received: from op.net (d-bm3-0e.ppp.op.net [209.152.194.78]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id PAA20137 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 15:48:50 -0400 (EDT)
Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id QAA31199; Fri, 15 Oct 1999 16:44:41 -0400
Date: Fri, 15 Oct 1999 16:44:41 -0400
Message-Id: <199910152044.QAA31199@op.net>
From: Paul Barton-Davis <pbd@Op.Net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] audio interference or ... ?
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 970230180e382c052857ad39f20f551e

i have a noise problem. my regular matrox PCI video card is currently
defunct, and i am using an old ISA Diamond Speedstar. its also sitting
right next to my Hoontech card.

when i run this new hdr program, and I move the controls, I get a a
lot of static-like noise. a little more tracking down suggests that
the noise comes from anything involving X activity - mouse motion,
pixmap redraws, etc. if i bind a couple of MIDI faders to the volume
faders, then switch to an empty workspace (ie. no X output), the noise
goes away, *even when I move the MIDI faders*. that is, the program is
still running, but there is no X activity, and I am still actively
modulating the volume controls via MIDI, with no static noise.

do you think it reasonable to conclude that this is caused by video
noise ? or is there still some chance that scheduling nonsense caused
by the X server needing to run may be to blame ? any suggestions on
how to figure it out ? for what its worth, increasing the frames
processed per cycle from 64 to 1024 makes no apparent difference in
the noise.

i don't recall this being a problem with quasimodo, but the overlap
between the time i've been working on hdr and time the matrox card
has been dead is almost 100%, so its hard to say.

--p



From - Sat Oct 16 02:48:16 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA07091
	for <slinkp@ulster.net>; Fri, 15 Oct 1999 17:33:03 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA24374 for linux-audio-dev-list; Fri, 15 Oct 1999 17:11:04 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA24371 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 17:10:58 -0400
Received: from localhost.localdomain (d212-151-36-248.swipnet.se [212.151.36.248]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id XAA20765; 
          Fri, 15 Oct 1999 23:05:54 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] audio interference or ... ?
Date: Fri, 15 Oct 1999 22:52:04 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910152044.QAA31199@op.net>
In-Reply-To: <199910152044.QAA31199@op.net>
MIME-Version: 1.0
Message-Id: <99101523125701.00510@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id XAA20765
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id RAA07091
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e45462848cdcf140ba4e05e22fd854f4

On Fri, 15 Oct 1999, Paul Barton-Davis wrote:
> do you think it reasonable to conclude that this is caused by video
> noise ?

If I could hear it, I'd recognize it if it's video noise. Very
characteristic to analog + digital systems, and brings inspiring C64
memories back... :-) (BTW, note that I generally *hate* noise!)

> or is there still some chance that scheduling nonsense caused
> by the X server needing to run may be to blame ?

Most probably not, if it's soft noise. That would in most cases
result in very loud distortion due to the DMA hitting old data, or
the CODEC being stopped. (Significantly louder and sharper than hard
clipping!)

- Identified as sharp spikes in the output data.

It *could*, however, result in the DAC stalling at the current level
until new data arrives. IIRC, the AudioPCI can be programmed to
behave that way.

- Identified as flat sections in the signal.
  Use a sine wave of 1-5 kHz or so as a test signal.

> for what its worth, increasing the frames
> processed per cycle from 64 to 1024 makes no apparent difference in
> the noise.

That sounds like video noise to me...


Oh, BTW, you *are* ramping to new levels with sample accuracy when
the controllers are moved, right? If you don't, you'll get clicks
and/or a soft, buzzing sound when moving the faders... If you have a
Roland JV-1080 around, slide the pan controller some while playing a
note. (Don't know if that flaw is in all versions [XP, 2080...],
though.) IIRC, the EMU8000 (AWE) chip has the same bug on some or all
of the controllers as well.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Oct 16 02:48:17 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA09818
	for <slinkp@ulster.net>; Fri, 15 Oct 1999 17:44:48 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA24404 for linux-audio-dev-list; Fri, 15 Oct 1999 17:24:22 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA24401 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 17:24:16 -0400
Received: from localhost.localdomain (d212-151-36-248.swipnet.se [212.151.36.248]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id XAA04999; 
          Fri, 15 Oct 1999 23:19:08 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] cpu/disk tradeoff
Date: Fri, 15 Oct 1999 23:13:47 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910152030.QAA24681@renoir.op.net>
In-Reply-To: <199910152030.QAA24681@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101523261102.00510@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id XAA04999
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id RAA09818
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: cb6518157343d61b323d0cdb6c44506b

On Fri, 15 Oct 1999, Paul Barton-Davis wrote:
> >Well, it looks like x86 CPUs aren't very cost effective these days,
> 
> just to clarify: the MIPS was about 5 times the speed *for this
> benchmark*, which tested a specific thing: table-driven sine wave
> generation. there is no particular reason to expect the difference to
> apply to everything else. it would be interesting to see the
> comparison for float computed sine waves.

Yes, I'm aware of that... RISCs are usually not very much faster than
CISCs in the *average* case, but DSP is far from the "average" code
run on workstations. RISCs usually do things they were not originally
designed for a lot better than CISCs, as CISC instructions turn into
legacy crap in such cases. (I could dig out some practical 68k
examples from my old Amiga code... And that's a *good* instruction
set, as opposed to the x86 mess.)

Besides, I'm still more interested in the Alpha than the MIPS (perhaps
I'm just missinformed?), but we'll see if/when the Athlon gets rid
of the 3DNow! waitstates flaw. (Hmmm... BTW, I saw some company
selling Athlon 500 nearly as cheap as Celeron 500. But what about
dual Athlon?)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Oct 16 02:48:11 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA01563
	for <slinkp@ulster.net>; Fri, 15 Oct 1999 16:57:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA24306 for linux-audio-dev-list; Fri, 15 Oct 1999 16:35:33 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA24303 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 16:35:31 -0400
Received: from someip.ppp.op.net (d-bm3-0e.ppp.op.net [209.152.194.78]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id QAA24681 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 16:30:28 -0400 (EDT)
Message-Id: <199910152030.QAA24681@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] cpu/disk tradeoff 
In-reply-to: Your message of "Fri, 15 Oct 1999 22:07:20 +0200."
             <99101522192200.00510@localhost.localdomain> 
Date: Fri, 15 Oct 1999 17:26:20 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: a8137ca76d81a7efc85cc7e086f1fcaf

In message <99101522192200.00510@localhost.localdomain>you write:
>>   "It was also interesting to notice how vastly
>>   superior the MIPS processor was: about 5 times as fast as its clock
>>   speed equivalent Pentium-II."
>

>Well, it looks like x86 CPUs aren't very cost effective these days,

just to clarify: the MIPS was about 5 times the speed *for this
benchmark*, which tested a specific thing: table-driven sine wave
generation. there is no particular reason to expect the difference to
apply to everything else. it would be interesting to see the
comparison for float computed sine waves. 

From - Sat Oct 16 02:48:15 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA05617
	for <slinkp@ulster.net>; Fri, 15 Oct 1999 17:22:25 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA24330 for linux-audio-dev-list; Fri, 15 Oct 1999 16:59:01 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA24327 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 16:58:58 -0400
Received: from someip.ppp.op.net (d-bm3-0e.ppp.op.net [209.152.194.78]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id QAA27121 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 16:53:55 -0400 (EDT)
Message-Id: <199910152053.QAA27121@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] multiple files/single files for HDR: my verdict 
In-reply-to: Your message of "Fri, 15 Oct 1999 22:53:02 +0300."
             <19991015195305Z46357-563+253@nic.funet.fi> 
Date: Fri, 15 Oct 1999 17:49:47 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 999a3ba05ba09de4d1598c1f949b759f

Juhana writes:

>>remember: this is meant to be the equivalent of an ADAT and a mixing
>>console. its not meant to be anything like any of the myriad of
>
>Ok. But I think using lseek() is a kludge because the file systems
>"editlist" just is not equivalent to audio editlist.

i know that. but why is it a kludge ? i wouldn't dream of using holes
for a soundfile editor. but this isn't the same thing at all. what
strikes you as ugly about it ? would you rather end up with files that
can only read by a particular program because they come with an
editlist instead of being a linear stream of data when accessed via
read(2) ? in an editor that seems OK, but in a program designed to
bring live sound into the computer efficiently, easily and
controllably, it seems to me that you particularly do *not* want to
use an editlist.



From - Sat Oct 16 02:48:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA16028
	for <slinkp@ulster.net>; Fri, 15 Oct 1999 18:30:05 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA24473 for linux-audio-dev-list; Fri, 15 Oct 1999 18:07:34 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id SAA24470 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 18:07:32 -0400
From: est@hyperreal.org
Received: (qmail 22918 invoked by uid 162); 15 Oct 1999 22:02:11 -0000
Message-ID: <19991015220211.22917.qmail@hyperreal.org>
Subject: [linux-audio-dev] cpus
In-Reply-To: <99101523261102.00510@localhost.localdomain> from David Olofson
 at "Oct 15, 1999 11:13:47 pm"
To: David Olofson <audiality@swipnet.se>
Date: Fri, 15 Oct 1999 15:02:11 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: aaa03364da7a340f657b4248ba3ef622

David Olofson discourseth:
> 
> Besides, I'm still more interested in the Alpha than the MIPS (perhaps
> I'm just missinformed?), but we'll see if/when the Athlon gets rid
> of the 3DNow! waitstates flaw. (Hmmm... BTW, I saw some company
> selling Athlon 500 nearly as cheap as Celeron 500. But what about
> dual Athlon?)

mmm..I still lust for the g4.  Having coded some 3dnow, I really
appreciate how having more (32 vs 8) SIMD registers could improve
pipelining.  Also, the registers are 128-bits and the instruction set
is neat.

Eric

From - Sat Oct 16 02:48:20 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA19819
	for <slinkp@ulster.net>; Fri, 15 Oct 1999 19:01:40 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA24535 for linux-audio-dev-list; Fri, 15 Oct 1999 18:39:56 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA24532 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 18:39:54 -0400
Received: from localhost.localdomain (d212-151-36-248.swipnet.se [212.151.36.248]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA08831; 
          Sat, 16 Oct 1999 00:34:49 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: est@hyperreal.org
Subject: [linux-audio-dev] Re: cpus
Date: Sat, 16 Oct 1999 00:40:40 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <19991015220211.22917.qmail@hyperreal.org>
In-Reply-To: <19991015220211.22917.qmail@hyperreal.org>
MIME-Version: 1.0
Message-Id: <99101600415204.00510@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id AAA08831
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA19819
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 9275607fd8073ded72c3e47ad3b40ab1

On Sat, 16 Oct 1999, est@hyperreal.org wrote:
> mmm..I still lust for the g4.  Having coded some 3dnow, I really
> appreciate how having more (32 vs 8) SIMD registers could improve
> pipelining.  Also, the registers are 128-bits and the instruction set
> is neat.

32 regs!?! DAMN, I gadda' have one! >:-D~


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Oct 16 02:48:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA19663
	for <slinkp@ulster.net>; Fri, 15 Oct 1999 15:28:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA23827 for linux-audio-dev-list; Fri, 15 Oct 1999 14:57:40 -0400
Received: from mail.alphalink.com.au (mail.alphalink.com.au [203.24.205.7]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA23824 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 14:57:36 -0400
Received: from alphalink.com.au (IDENT:andrew@d104-as1-mel.alphalink.com.au [202.161.100.104]) by mail.alphalink.com.au (8.9.3/8.6.9) with ESMTP id EAA03923; Sat, 16 Oct 1999 04:52:16 +1000
Message-ID: <3807AF73.E6CCD276@alphalink.com.au>
Date: Fri, 15 Oct 1999 18:49:23 -0400
From: Andrew Clausen <clausen@alphalink.com.au>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.10 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Juhana Sadeharju <kouhia@nic.funet.fi>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] multiple files/single files for HDR: my verdict
References: <19991015174948Z46269-564+257@nic.funet.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: fc982fd9ba4e6abd6398cdb7695745f9

Juhana Sadeharju wrote:
> You are going to record silence as well?

Why not exploit holes?

Andrew Clausen

From - Sat Oct 16 02:48:22 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA20482
	for <slinkp@ulster.net>; Fri, 15 Oct 1999 19:07:44 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA24523 for linux-audio-dev-list; Fri, 15 Oct 1999 18:36:11 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA24520 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 18:36:08 -0400
Received: from someip.ppp.op.net (d-bm3-0e.ppp.op.net [209.152.194.78]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id SAA05757 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 18:31:06 -0400 (EDT)
Message-Id: <199910152231.SAA05757@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] audio interference or ... ? 
In-reply-to: Your message of "Fri, 15 Oct 1999 22:52:04 +0200."
             <99101523125701.00510@localhost.localdomain> 
Date: Fri, 15 Oct 1999 19:26:59 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7a389ca20c717bd4d0d232a1e7e7eee2

>Oh, BTW, you *are* ramping to new levels with sample accuracy when
>the controllers are moved, right? If you don't, you'll get clicks
>and/or a soft, buzzing sound when moving the faders...

well, not i am not doing this yet. once we get the plugin API worked
out, i'll work on an engine that does this with sample accuracy. for
now, its block-size quantized. the noise is probably there, though I
don't hear it, but its not something i am worried about at this point.

actually, now that I'm mentioning the plugin API again, i've been
wondering about your response to my last long-ish message regarding
addressing, engine deMUX efficiency etc. i've assumed that you're busy
with other things, a not entirely unreasonable state to be in :)

--p


From - Sat Oct 16 02:48:25 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA11923
	for <slinkp@ulster.net>; Fri, 15 Oct 1999 22:13:35 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA24779 for linux-audio-dev-list; Fri, 15 Oct 1999 21:52:42 -0400
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA24776 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 21:52:39 -0400
Received: from localhost.localdomain (d212-151-36-248.swipnet.se [212.151.36.248]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id DAA00221; 
          Sat, 16 Oct 1999 03:47:29 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] audio interference or ... ?
Date: Sat, 16 Oct 1999 02:04:20 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910152231.SAA05757@renoir.op.net>
In-Reply-To: <199910152231.SAA05757@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101603543205.00510@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb07.swip.net id DAA00221
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id WAA11923
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b37af75db84550bc0a3ec8d6b3c9253a

On Sat, 16 Oct 1999, Paul Barton-Davis wrote:
> >Oh, BTW, you *are* ramping to new levels with sample accuracy when
> >the controllers are moved, right? If you don't, you'll get clicks
> >and/or a soft, buzzing sound when moving the faders...
> 
> well, not i am not doing this yet. once we get the plugin API worked
> out, i'll work on an engine that does this with sample accuracy. for
> now, its block-size quantized. the noise is probably there, though I
> don't hear it, but its not something i am worried about at this point.

You could get away with zero crossing triggering as well (used in
some digitally controlled amplifiers), but I'm afraid that's more
expensive than ramping on a CPU...

> actually, now that I'm mentioning the plugin API again, i've been
> wondering about your response to my last long-ish message regarding
> addressing, engine deMUX efficiency etc. i've assumed that you're busy
> with other things, a not entirely unreasonable state to be in :)

Well, I've kind of had a cerebral database overload here with all
this, work, and then trying to get the new ATI Rage 128 X-server to
work. (Would like to testdrive the iiyama 22"er with a card that can
do better than 1600x1200 @ 85 Hz - impressive monitor BTW;
recommended! :-)

What's the date/time of that post, in case I'm not thinking about
the right one?


Anyway, I have a few other interesting problems to solve: 

1) Huge block transfers
   * Jaroslav dreamt about sending an entire sampled
     instrument as an event. Why not throwing in a
     request/reply event that lets you do asynchronous
     I/O? Network transparent and all... Real time or
     off-line, AND, it means you can do asynchronous
     stuff from within plug-ins! (The latter is
     probably a bad habit in most cases...)
   * The event system's memory allocator is meant for
     small events, =< 256 bytes or so. Getting rid of
     that restriction would most likely mean a
     significant performance hit in the average case.
     Therefore, "huge blocks" should be added as a
     higher level, so that you only get the
     performance hit when there really is no way
     around it.
   * Note that the normal events are always in locked
     memory (real time...), while "huge blocks"
     needn't be.
Simply a more flexible, but also slightly more expensive way of
sending data.

2) Variable data (audio) buffer size
   * For compressed formats, variable sample rates, ...
   * Memory allocation? This can be big buffers, so
     it's getting tricky... So far, I've been thinking
     "specified maximum size", as that's about the
     only thing that works in a hard real time system.
Do we use "audio ports" (let's call them "stream ports" or
something...) for this at all, or should the "huge block" event
protocol be used here? That is, should the stream ports actually
support dynamic buffer size, or should an event system extension
carry that "special" feature? Unless "variable rate streams" really
*can* be supported with virtually no performance hit for constant
rate streams, I think this is the way to go. It would keep the extra
complexity out of plug-ins that don't use it anyway.

3) The name of the standard! :-)
   * Currently referred to as MCS -
     The Multimedia Communication System
   * MuCoS
   * MInT - Multimedia Integration Toolkit
   * MICS - Multimedia Integration & Communication Standard
   * ReTMIS - Real Time Multimedia Integration Standard
   * ...or whatever... We had a few other suggestions a
     while ago. Some cut'n'paste perhaps...
     *zzrr... rattle* Found sum'!
> LAPS     Linux Audio Plugin Standard
> LAPLAND  Linux Audio Plugin
> Language and Design LAPI     Linux Audio Plugin Interface
> YAPI     Yet Another Plugin Interface
> TAPDANCE The Audio Plugin Definition ANd Connection Extension
> LAPDOG   Linux Audio Plugin Definition 
> SOCKET   Sound Connection and Key Extension Tools
> GACK     GNU Audio Connector Kit
> TEDIUM   This Extension Definition Is Under new Management
> inVeST   is not VeST

I also wrote a post on a games programming site regarding "sounds &
ambience" in games. The system I describe there (although a bit heavy
for games, unless most of the advanced features proposed are left out)
illustrates one kind of processing that I'd like to be able to do
with MCS... (I'm Mr. Harmony on that board.)

	http://www.lionhead.co.uk/forums/Forum4/HTML/002387.html

And I posted a note on the design efforts as well, to see if we could
possibly get some audio hackers to reveal the weaknesses of the Dark
Side, so that we can avoid doing the same mistakes. :-)

	http://www.lionhead.co.uk/forums/Forum4/HTML/002386.html


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Oct 16 02:48:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA21819
	for <slinkp@ulster.net>; Fri, 15 Oct 1999 23:45:10 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA24929 for linux-audio-dev-list; Fri, 15 Oct 1999 23:25:31 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA24926 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 23:25:29 -0400
Received: from op.net (d-bm2-0c.ppp.op.net [209.152.194.44]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id XAA24137 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 15 Oct 1999 23:20:25 -0400 (EDT)
Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id AAA09782; Sat, 16 Oct 1999 00:16:21 -0400
Date: Sat, 16 Oct 1999 00:16:21 -0400
Message-Id: <199910160416.AAA09782@op.net>
From: Paul Barton-Davis <pbd@Op.Net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] video interference
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8003
X-Mozilla-Status2: 00000000
X-UIDL: 5df49016b00c3a092d11c68f228bffbb

as an inadvertent test, i just picked up the new version of alsaplayer
(a truly cool program!). despite having a dual PII-450, with my
current video card and X server, it suffers from *exactly* the same problems
as "hdr". huge amounts of noise whenever any X activity occurs; none
if we just change X state so that no windows are mapped, all noise
goes away.

it occured to me that this old card only has 1MB of RAM on it.  i
conclude, for now, that its a poor video card, inadequate video RAM or
something related. whenever i get the matrox back, i'll let you know.

From - Sat Oct 16 02:48:31 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA27472
	for <slinkp@ulster.net>; Sat, 16 Oct 1999 00:56:44 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA25011 for linux-audio-dev-list; Sat, 16 Oct 1999 00:30:13 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA25008 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 16 Oct 1999 00:30:05 -0400
Received: from localhost.localdomain (d212-151-36-248.swipnet.se [212.151.36.248]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id GAA19954; 
          Sat, 16 Oct 1999 06:24:53 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] video interference
Date: Sat, 16 Oct 1999 06:17:06 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910160416.AAA09782@op.net>
In-Reply-To: <199910160416.AAA09782@op.net>
MIME-Version: 1.0
Message-Id: <99101606315600.00875@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id GAA19954
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id AAA27472
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4548f5612f89a4fbe21b94cad388315e

On Sat, 16 Oct 1999, Paul Barton-Davis wrote:
> as an inadvertent test, i just picked up the new version of alsaplayer
> (a truly cool program!). despite having a dual PII-450, with my
> current video card and X server, it suffers from *exactly* the same problems
> as "hdr". huge amounts of noise whenever any X activity occurs; none
> if we just change X state so that no windows are mapped, all noise
> goes away.
> 
> it occured to me that this old card only has 1MB of RAM on it.  i
> conclude, for now, that its a poor video card, inadequate video RAM or
> something related. whenever i get the matrox back, i'll let you know.

As it most likely doesn't do busmaster DMA, it could be the X server
doing nasty things. What X server? Not too long ago, there were
still hard STIs/CLIs in there... (Some RTLinux people had problems
with that, as it ruins the RT timing, and can't be prevented at run
time.) You could try the standard VGA (*urgh!*) server just to see
if it makes a differece.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Oct 16 03:37:54 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id DAA02966
	for <slinkp@ulster.net>; Sat, 16 Oct 1999 03:22:28 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id CAA28983 for linux-audio-dev-list; Sat, 16 Oct 1999 02:56:15 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA28980 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 16 Oct 1999 02:56:13 -0400
Received: from ulster.net (port180.ts2.ulster.net [208.242.164.180])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id CAA01730;
	Sat, 16 Oct 1999 02:53:43 -0400
Message-ID: <38082260.A46CCE79@ulster.net>
Date: Sat, 16 Oct 1999 02:59:45 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Barton-Davis <pbd@Op.Net>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] video interference
References: <199910160416.AAA09782@op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: eceb9a4acca197ed18cfa73c1f20b159

Paul Barton-Davis wrote:
> 
> as an inadvertent test, i just picked up the new version of alsaplayer
> (a truly cool program!). despite having a dual PII-450, with my
> current video card and X server, it suffers from *exactly* the same problems
> as "hdr". huge amounts of noise whenever any X activity occurs; none
> if we just change X state so that no windows are mapped, all noise
> goes away.

You know, this sounds suspiciously like the noise that caused me so
much agony that I started the Audio-Quality HOWTO. 

What fixed it for me was to add:
	append=no-hlt
...to my etc/lilo.conf.

-- PW

----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.
email=========================slinkp AT ulster DOT net
ARMS online=======================http://reacharms.com    
personal page===========http://www.ulster.net/~abigoo/

From - Mon Oct 18 02:47:43 1999
Received: from alsa.alsa-project.org (andy@alsa.jcu.cz [160.217.1.49])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id FAA09007
	for <slinkp@ulster.net>; Sat, 16 Oct 1999 05:54:22 -0400
Received: from localhost (andy@localhost)
	by alsa.alsa-project.org (8.8.8/8.8.8) with ESMTP id LAA18850;
	Sat, 16 Oct 1999 11:51:29 +0200
Date: Sat, 16 Oct 1999 11:51:29 +0200 (MEST)
From: Andy Lo A Foe <andy@alsa-project.org>
To: Paul Winkler <slinkp@ulster.net>
cc: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] video interference
In-Reply-To: <38082260.A46CCE79@ulster.net>
Message-ID: <Pine.LNX.4.05.9910161144520.18755-100000@alsa.alsa-project.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3110b398cf46bd7bb111a1a63417b52c

On Sat, 16 Oct 1999, Paul Winkler wrote:

> You know, this sounds suspiciously like the noise that caused me so
> much agony that I started the Audio-Quality HOWTO. 
> 
> What fixed it for me was to add:
> 	append=no-hlt
> ...to my etc/lilo.conf.

Woah, this helped very much. The interference is still there but, how
should I explain this, at a much lower level. I also noticed that the
interference is there before the audio driver is loaded. Also my hdparm
setttings seem to have a negative effect too (hdparm is almost an ON
switch for the noise :-)

/usr/sbin/hdparm -c1 -u1 -m16 /dev/hda

I'll disable this and test it some more..

Andy
--
AlsaPlayer, http://www.alsa-project.org/~andy/

From - Mon Oct 18 02:47:46 1999
Received: from alsa.alsa-project.org (andy@alsa.jcu.cz [160.217.1.49])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id GAA09430
	for <slinkp@ulster.net>; Sat, 16 Oct 1999 06:03:19 -0400
Received: from localhost (andy@localhost)
	by alsa.alsa-project.org (8.8.8/8.8.8) with ESMTP id MAA18936;
	Sat, 16 Oct 1999 12:00:36 +0200
Date: Sat, 16 Oct 1999 12:00:36 +0200 (MEST)
From: Andy Lo A Foe <andy@alsa-project.org>
To: Paul Winkler <slinkp@ulster.net>
cc: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] video interference
In-Reply-To: <38082260.A46CCE79@ulster.net>
Message-ID: <Pine.LNX.4.05.9910161158280.18899-100000@alsa.alsa-project.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 9cf7207db443269762ff25c8c7ec5962

On Sat, 16 Oct 1999, Paul Winkler wrote:

> 	append=no-hlt
> ...to my etc/lilo.conf.

Ok, I was wrong about the hdparm bit. It turns out the be the sound driver
that was the ON switch for this after all. Nonetheless, the no-hlt option
helps a great deal. It'd be interesting to check if the noise is still
there when using the digital out of the card...

Andy
--
AlsaPlayer, http://www.alsa-project.org/~andy/

From - Mon Oct 18 02:47:51 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA26952
	for <slinkp@ulster.net>; Sat, 16 Oct 1999 10:06:46 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA29625 for linux-audio-dev-list; Sat, 16 Oct 1999 09:42:00 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA29622 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 16 Oct 1999 09:41:56 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m11cRri-000e0kC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Sat, 16 Oct 1999 13:19:10 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Sat, 16 Oct 1999 13:19:10 +0200 (CEST)
To: Benno Senoner <sbenno@gardena.net>
Cc: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] atomic xchg
In-Reply-To: <99101423224600.00534@goblin.flashnet.it>
References: <199910141522.LAA16936@renoir.op.net>
	<99101423224600.00534@goblin.flashnet.it>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14344.23946.341780.599722@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id KAA26952
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f0350462f5c93c8ce2f87185760311fc

Benno Senoner writes:
 > Paul make sure that we have a fallback solution (compile time) for CPU
 > architectures which do not provide these specialized asm instructions,
 > since it would be nice to run our audio engine on any powerful Linux
 > architecture ( Alpha, G4 PPC etc).
 > 
 > Benno.
 > 

Yes, Im volunteering for the Alpha part, so I will shout out loud
if something is not running there. 

Guenter

From - Mon Oct 18 02:48:02 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA22845
	for <slinkp@ulster.net>; Sat, 16 Oct 1999 14:40:27 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA29986 for linux-audio-dev-list; Sat, 16 Oct 1999 14:14:54 -0400
Received: from mail.cid.net (cephyr.cid.net [195.35.45.193]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA29983 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 16 Oct 1999 14:14:51 -0400
Received: from uucp by mail.cid.net (Exim 2.11) with local-bsmtp
	id 11cYHK-0006kU-00; Sat, 16 Oct 1999 20:10:02 +0200
Received: from deneb.cygnus.argh.org ([192.168.1.2])
	by cygnus.argh.org with esmtp (Exim 3.02 #1)
	id 11cYI4-0000iV-00; Sat, 16 Oct 1999 20:10:48 +0200
Received: from fw by deneb.cygnus.argh.org with local (Exim 3.02 #1)
	id 11cYI4-0001As-00; Sat, 16 Oct 1999 20:10:48 +0200
To: Paul Barton-Davis <pbd@Op.Net>
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] MCS: 64 bit timestamps?
References: <199910110404.AAA17257@renoir.op.net>
From: Florian Weimer <fw@deneb.cygnus.argh.org>
Date: 16 Oct 1999 20:10:47 +0200
In-Reply-To: Paul Barton-Davis's message of "Mon, 11 Oct 1999 01:00:02 -0400"
Message-ID: <87905318ig.fsf@deneb.cygnus.argh.org>
Lines: 8
User-Agent: Gnus/5.07009701 (Pterodactyl Gnus v0.97.1) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5bb95d5aa6b048eee0b5dad802708b67

Paul Barton-Davis <pbd@Op.Net> writes:

>         current_cycle_counter = read_tsc ();
> 	cycle_diff = current_cycle_counter -
> 	             cycle_counter_at_start_of_control_loop;

Forgive me the dumb question, but how is this supposed to work on an
SMP box?

From - Mon Oct 18 02:48:08 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA01664
	for <slinkp@ulster.net>; Sat, 16 Oct 1999 22:34:46 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA00672 for linux-audio-dev-list; Sat, 16 Oct 1999 22:06:22 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA00669 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 16 Oct 1999 22:06:19 -0400
Received: from someip.ppp.op.net (d-bm2-04.ppp.op.net [209.152.194.36]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id WAA21094 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 16 Oct 1999 22:01:12 -0400 (EDT)
Message-Id: <199910170201.WAA21094@renoir.op.net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] MCS: 64 bit timestamps? 
In-reply-to: Your message of "16 Oct 1999 20:10:47 +0200."
             <87905318ig.fsf@deneb.cygnus.argh.org> 
Date: Sat, 16 Oct 1999 22:57:22 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f84def8ba1cc79ad7d3e6886d6ca4397

Florian writes:

>>         current_cycle_counter = read_tsc ();
>> 	cycle_diff = current_cycle_counter -
>> 	             cycle_counter_at_start_of_control_loop;
>
>Forgive me the dumb question, but how is this supposed to work on an
>SMP box?

which part bothers you, "read_tsc" or the subtraction of non-atomic 64
bit quantities ?

if the cycle counters are not (1) synchronized at bootup and (2) not
running at the same rate, then as David pointed out, its hardly
*symmetric* multiprocessing is it ? 

the non-atomic 64 bit stuff is more of a problem. i don't have an easy
answer yet (or rather, i don't have an answer that doesn't involve
taking a mutex).

--p

From - Mon Oct 18 02:48:11 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA12031
	for <slinkp@ulster.net>; Sun, 17 Oct 1999 00:34:28 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA00804 for linux-audio-dev-list; Sun, 17 Oct 1999 00:15:17 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA00801 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 17 Oct 1999 00:15:15 -0400
Received: from someip.ppp.op.net (d-bm2-18.ppp.op.net [209.152.194.56]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id AAA27276 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 17 Oct 1999 00:10:06 -0400 (EDT)
Message-Id: <199910170410.AAA27276@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] back to the API
In-reply-to: Your message of "Sat, 16 Oct 1999 02:04:20 +0200."
             <99101603543205.00510@localhost.localdomain> 
Date: Sun, 17 Oct 1999 01:06:17 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 95e55c88dd8bee7cf02cf50ae2f9abf9

[ ... missing reply ... ]

>What's the date/time of that post, in case I'm not thinking about
>the right one?

note sure precisely, since i don't keep records/copies generally, but
it was my reply to your reply to my post of Tues Oct 12 1999, 12:18:13
EDT (subject "big picture, for a moment").

>1) Huge block transfers
    
      [ ... ]


>2) Variable data (audio) buffer size
   
      [ ... ]

Gregory Bateson once defined information as "any difference that makes
a difference". as i started writing an implementation of the system
we've been talking about so far (yep, rapid prototyping works better
for me than text sometimes), it seemed very clear to me at least that
events can be beautifully defined this way if you are willing to
exclude any data streams, including audio and "huge block sizes".

that is, an "event" is a notice that something has changed. the notice
can either be a delta from the old state, a new state, or a notice to
increment or decrement (which can have type-specific semantics).

   [ in this system, a GUI would lookup the target ID of a plugin's
     parameter, associate with a widget or whatever, and then whenever
     something changed because of user interaction with the GUI, the
     GUI would send an event saying "target ID has changed, the
     {delta,absolute value} is XXX". (Note: working in delta's
     is probably a good idea, when i think about some of the
     horrible aspects of some automated mixing visual+physical UI's)

     the plugin, when it noticed the event, would map the target ID to
     its own parameters (*probably* represented by some variable in
     memory), and perform the adjustment(s) as it saw fit.  
   ]

what would it mean to say that the "audio" has changed ? thats hardly
a difference that makes a difference! audio is really a data stream,
not a series of events. you've already demarcated them linguistically,
and suggested that a plugin would get audio via at least one audio
port "which is not the same as its event port" (my wording, your
intent, i hope). this strongly suggests to me that its a mistake to
consider these to be the same thing. look at two of the most salient
differences:

     1) data size: audio (N samples per call to process (); likely
                          to be N >= 32 ... 128 bytes for RT; non-RT
			  processing might go way higher ... 4KB ?)
	           event (with my Bateson inspired idea, about 24-32 bytes)

     2) data rate: audio (MB-GB/sec, continuous)
                   event (often zero, typically bytes/sec, very intermittent,
			  typically bursty)

i am therefore not convinced that these two very different entities
should be considered the same thing at all.

what about jaroslav's example of an instrument request ? well, the
wording is interesting. "request" ... this is not a notice that
anything *has* changed, its a notice that someone would like something
*to* change. if you had to cast it into an event, it would look more
like "XX has placed a request with YY". that is: the state of some
"request" parameter has just been changed. there should be, as you get
close to concluding, some other way to move whatever data is
associated with the "request" parameter from the one place to another.

this hints at one problem with my Bateson inspiration: strings and
other things where "state" is not a scalar. i am trying to think about
this. i really don't want a silly limit on string/array size on the one
hand, and on the other, a ridiculous consumption of unnecessary memory
if an implementation uses pool-based memory allocation (which mine
will/does). 

one possibility is that things needing to work with non-scalar data
request a piece of global memory (regular memory for threads, shmem
for processes), and then work with that memory as the storage for the
non-scalar. the event would just contain a void * then, pointing to
the global memory. this has its problems, not least of which is
atomicity of the contents of the memory. if the plugin has been told
that, say, a string value has changed, but then the string changes
again before/while its looking at it, this is, uhm, not good :)

--p

From - Mon Oct 18 02:48:20 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA01485
	for <slinkp@ulster.net>; Sun, 17 Oct 1999 13:09:33 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA07047 for linux-audio-dev-list; Sun, 17 Oct 1999 12:38:57 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA07044 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 17 Oct 1999 12:38:54 -0400
Received: from localhost.localdomain (d212-151-87-150.swipnet.se [212.151.87.150]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id SAA29979; 
          Sun, 17 Oct 1999 18:33:41 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] MCS: 64 bit timestamps?
Date: Sun, 17 Oct 1999 18:12:23 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910170201.WAA21094@renoir.op.net>
In-Reply-To: <199910170201.WAA21094@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101718404900.00724@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id SAA29979
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id NAA01485
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: a5e16552c638fa2a1e8facf0d751c8ed

On Sun, 17 Oct 1999, Paul Barton-Davis wrote:
> the non-atomic 64 bit stuff is more of a problem. i don't have an easy
> answer yet (or rather, i don't have an answer that doesn't involve
> taking a mutex).

You don't need a mutex for a pointer to a struct... But you *do* need
a bunch of structs in a circular buffer to ensure that the pointer a
thread grabs is valid long enough. It's not sexy, and not even fool
proof (some non-RT task can grab the pointer and go to sleep for a
while...), but it's sync free and simple.


----8<---( mcstime.h )-----------------
struct sync_point_t {
	.
	.
	.
};

extern sync_point_t *mcs_sync_point;
--------------------------------->8----

----8<---( engine.c )------------------
#define SYNCSTRUCTS	<sensible value>
static int current_struct = 0;
static sync_point_t struct_tab[SYNCSTRUCTS];

sync_point_t *mcs_sync_point;

void update_sync(void)
{
	/* Fill in the new struct... */
	.
	.
	.
	struct_tab[current_struct].blah = ...;

	/* / / Critical: Atomic pointer write. / / */
	mcs_sync_point = &struct_tab[current_struct];
	/* / / / / / / / / / / / / / / / / / / / / */

	if(++current_struct >= SYNCSTRUCTS)
		current_struct = 0;
}
--------------------------------->8----

SYNCSTRUCTS needs to be sync_valid_time / resync_rate for this to be
safe, while soft RT systems and coding style make it impossible to
safely quarantee that the sync_valid_time limit is obeyed...

OTOH, long before that happens, timestamping is already pretty useless
anyway... And, what happens if an structure access collision occurs?
As long as you get a screwed up timestamp, and not a segfault or div
by zero, I'd say it's not a real problem.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Mon Oct 18 02:48:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA21227
	for <slinkp@ulster.net>; Sun, 17 Oct 1999 16:40:25 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA07314 for linux-audio-dev-list; Sun, 17 Oct 1999 16:19:27 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA07311 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 17 Oct 1999 16:19:25 -0400
Received: from localhost.localdomain (d212-151-102-165.swipnet.se [212.151.102.165]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id WAA03559; 
          Sun, 17 Oct 1999 22:14:10 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] back to the API
Date: Sun, 17 Oct 1999 19:23:34 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910170410.AAA27276@renoir.op.net>
In-Reply-To: <199910170410.AAA27276@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101722201901.00724@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id WAA03559
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id QAA21227
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 434df98db7f4b0c751cb573cf3e123d5

On Sun, 17 Oct 1999, Paul Barton-Davis wrote:
> [ ... missing reply ... ]
> 
> >What's the date/time of that post, in case I'm not thinking about
> >the right one?
> 
> note sure precisely, since i don't keep records/copies generally, but
> it was my reply to your reply to my post of Tues Oct 12 1999, 12:18:13
> EDT (subject "big picture, for a moment").

Weird... I found the 12:18:13 post, my reply, but no further posts
in that thread. Lost or accidentally deleted, I guess... Could
someone forward those posts to me?

[...]
> what would it mean to say that the "audio" has changed ? thats hardly
> a difference that makes a difference! audio is really a data stream,
> not a series of events.

That depends a bit on whether you want to view audio as abstract
streams, or as what they actually are; buffers of samples. True, it
doesn't really make sense to say "Hey! A new buffer. :-)" every
freaking cycle, as it's *required* that there is anyway.

However, it changes a bit when dealing with some compressed data
formats and other situations when variable data rates are needed.
Also, allowing plug-ins to handle muted inputs by themselves (as
opposed to leaving it to the engine to entirely disable the plug-in
when there is no input, and the specified tail has died out) require
that the engine can say which buffers are empty/muted.

The information that a plug-in gets:
	(implicit information inside [],
	all seen from the plug-in's perspective,
	I: = input,
	O: = output)

-----------------------------------------------------
I:[cycle starts now!]		//process() call
I:[local time starts at 0]	//Event timing rel. buffer start
I:N samples to process		//In the closure...
				//(Set at init time - could
				//be changed with an event.)
I:[the data is in the
   current buffers]
	.
	.			//...Normal events...
	.
O:[N samples ready]		//Must be done before return
O:[cycle ends now!]		//process() return
-----------------------------------------------------

IMO, a logical distinction between two kinds of events can be made.
The kind of events that clearly belongs in the event system are those
that are directly related to the processing. The other kind is events
that actually occur in real life, directly and unconditionally
affecting the plug-in, ie process() being called, or the audio
streams being prepared so that the plug-in can access the data.
Obviously, there's no need to send an event telling the plug-in that
it has been called! :-) But after that, the clear distinction starts
to fade... Do we tell the plug-in that the buffer size has changed?
Or even that there really *is* a new buffer (that is, the audio port
isn't muted)...?

> you've already demarcated them linguistically,
> and suggested that a plugin would get audio via at least one audio
> port "which is not the same as its event port" (my wording, your
> intent, i hope). this strongly suggests to me that its a mistake to
> consider these to be the same thing. look at two of the most salient
> differences:
> 
>      1) data size: audio (N samples per call to process (); likely
>                           to be N >= 32 ... 128 bytes for RT; non-RT

How does a sampleplayer interface with a streaming/caching "daemon"?
(A special case that shouldn't be supported?)

> 			  processing might go way higher ... 4KB ?)

(IIRC, VST had a 32 kB default buffer size before they realized you
don't want to wait for ages to hear the effect of an automation
edit...)

> 	           event (with my Bateson inspired idea, about 24-32 bytes)
> 
>      2) data rate: audio (MB-GB/sec, continuous)
>                    event (often zero, typically bytes/sec, very intermittent,
> 			  typically bursty)
> 
> i am therefore not convinced that these two very different entities
> should be considered the same thing at all.

What I consider most important here is good one kind of port is at
doing the other one's job. Clearly, streams of fixed size raw data
buffers is rather useless for events, and the event system can't
carry high bandwidth data in-band.

But how different is sending an event from passing an extra argument
to process()?

The "huge block events" would not change the current event system
design - only define events that can reference "out-of-band" data,
pretty much like what you describe below. The most important part of
that extension is defining the semantics, so that it can be handled
correctly by the engine.

The audio streams could be handled using an extension based on, or
similar to the "huge block events". If it's logical, efficient,
flexible enough and overall a good idea, remains to see. There might
be better ways, and/or ways that do the same thing with a better
balance between efficiency in the average case and special settings.
I'd like to have high efficiency in all situations, of course! :-)

> what about jaroslav's example of an instrument request ? well, the
> wording is interesting. "request" ... this is not a notice that
> anything *has* changed, its a notice that someone would like something
> *to* change. if you had to cast it into an event, it would look more
> like "XX has placed a request with YY". that is: the state of some
> "request" parameter has just been changed. there should be, as you get
> close to concluding, some other way to move whatever data is
> associated with the "request" parameter from the one place to another.

>From Jaroslav's post:
> A little dream:
> 
> Event - picture 768x576 from grabbed from the BTTV driver 8-bits per
>         color
> Event - Piano instrument 96kHz, 24-bit resolution

The request/reply thing was my solution for actions that cannot be
ekpected to be carried out in real time, like sending a full 96 kHz
piano over to a synth. This data needs to be streamed out-of-band, at
the highest possible speed. Anyway, that kind of operations don't fit
well with the plug-in concept anyway - only clients should do it,
probably. (But a sampler *plug-in*...? Hmmm...)

The picture, OTOH, fits into the streaming system. For this to make
sense in a real time system, there would be a stream of pictures. One
picture corresponds to one audio sample; both could be called a
frame. (Why? A picture is an array of pixels, covering one frame
period. A sample is a DC level, held for one sample period.)

As for events and out-of-band, non real time transfer;
1) Set up you data buffer.
2) Send the event "Yo! There's a buffer for ya' at &buffer".
3) Stay off the buffer...
4) ...until you get the event "Ok, got it. (&buffer)"

Even though the event system is buffered and timestamped, I don't see
it as very different from function calls, RPC or other ways of
getting things done. Real time vs. non real time is probably what
makes the most obvious difference here. The timestamping + buffering
has the side effect of true real time events ("now!" as opposed to
"exactly at t = 0 + x"), and thus out-of-band, "ASAP events" not
fitting in very well.

> this hints at one problem with my Bateson inspiration: strings and
> other things where "state" is not a scalar. i am trying to think about
> this. i really don't want a silly limit on string/array size on the one
> hand, and on the other, a ridiculous consumption of unnecessary memory
> if an implementation uses pool-based memory allocation (which mine
> will/does). 

This is a problem that probably doesn't have any perfect solution -
perhaps not even a nice one. (I'm not giving up in a while yet,
though!)

The reason why I decided on the qm allocator with heaps for the
events is that it allows quick allocation of lots of small blocks
without fragmentation. It also replaces deallocation with garbage
collection in a very low cost way. (When a qm_heap_t is replaces a
buffer, the reference to the old one goes where the data will be
used, and is flushed from there.)

As soon as the global heap of buffers is turned into a freelist, we
get search and splitt overhead, risk of complicated memory leak bugs,
deallocation overhead, and most importantly; _memory fragmentation_.
This is a *very* serious problem, and was the reason why you had to
reboot old Amigas and Macs on a regular basis when using applications
that were nasty to the memory manager. Unless we can take even more
overhead and remap memory pages (which requires a quite non-trivial
kernel hack, as we still need shared meory...), there's no way around
it.

There is an intermediate half-solution. (One implementation can be
found in the Kernel.) Set up a number of global buffer heaps, where
the buffers have different sizes. Power-of-2 sizes (like 32, 64,
128,...) seems to be a good distribution for the average case. During
initialization, the heaps are filled with sufficient numbers of
buffers. When allocating, a buffer is grabbed from the first
non-empty heap that has buffers of sufficient size. To make the
system more adaptive; increase the number of big buffers, and add
migration/transformation between the heaps.

Costs a lot more than the qm way, but can be implemented more
efficiently than a classic "search & split" memory manager. It
eliminates fragmentation, but it restricts allocation size to the
largest block size, and relies on real life not being too different
from the statistics used to balance the heaps...

> one possibility is that things needing to work with non-scalar data
> request a piece of global memory (regular memory for threads, shmem
> for processes), and then work with that memory as the storage for the
> non-scalar. the event would just contain a void * then, pointing to
> the global memory.

That's about what the underlying implementation of "huge blocks"
would be.

> this has its problems, not least of which is
> atomicity of the contents of the memory. if the plugin has been told
> that, say, a string value has changed, but then the string changes
> again before/while its looking at it, this is, uhm, not good :)

If you tell someone that you put a ladder in the right place, you
don't move it away just when he's about to step on it, do you? :-)

A standard problem in multitasking/multithreaded environments, and
can't be solved transparently with other magic than copying... (How
do you copy a ladder...!?)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Mon Oct 18 02:48:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA19112
	for <slinkp@ulster.net>; Sun, 17 Oct 1999 16:20:21 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA07271 for linux-audio-dev-list; Sun, 17 Oct 1999 15:45:22 -0400
Received: from gauss.deltav.hu (gauss.deltav.hu [194.9.64.225]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA07268 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 17 Oct 1999 15:45:18 -0400
Received: from boksi (77.dial02.deltav.hu [194.9.64.77]) by gauss.deltav.hu
          (Netscape Messaging Server 3.6)  with ESMTP id AAA18BB
          for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Sun, 17 Oct 1999 21:43:42 +0200
Received: from reactor by boksi with local (Exim 1.92 #1 (Debian))
	id 11cwGc-00004F-00; Sun, 17 Oct 1999 21:46:54 +0200
Message-ID: <19991017214654.A257@boksi>
Date: Sun, 17 Oct 1999 21:46:54 +0200
From: reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] new Brahms
Reply-To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91.2
Organization: CTP media laboratories
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 6f6d9e1bef6e044d2eb512bff78739ac

yo!

there's a new version of Brahms, out there:
http://lienhard.desy.de:80/mackag/homepages/jan/Brahms/Brahms-0.97.2.tar.gz

(i found it on freshmeat, just to be fair.)

byez!


reactor/CTPmedia

From - Mon Oct 18 02:48:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA21637
	for <slinkp@ulster.net>; Sun, 17 Oct 1999 16:44:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA07331 for linux-audio-dev-list; Sun, 17 Oct 1999 16:25:29 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA07328 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 17 Oct 1999 16:25:26 -0400
Received: from localhost.localdomain (d212-151-102-165.swipnet.se [212.151.102.165]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id WAA17941; 
          Sun, 17 Oct 1999 22:20:12 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] MCS: 64 bit timestamps?
Date: Sun, 17 Oct 1999 22:24:47 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910170201.WAA21094@renoir.op.net> <99101718404900.00724@localhost.localdomain>
In-Reply-To: <99101718404900.00724@localhost.localdomain>
MIME-Version: 1.0
Message-Id: <99101722272000.19701@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id WAA17941
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id QAA21637
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c35be21e29f16585508c71a4b9dcd3b6

Uhm, for clarity:

 ----8<---( engine.c )------------------
 #define SYNCSTRUCTS      <sensible value>
-static int current_struct = 0;
+static int next_struct = 0;
 static sync_point_t struct_tab[SYNCSTRUCTS];


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Mon Oct 18 02:48:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA30279
	for <slinkp@ulster.net>; Sun, 17 Oct 1999 22:35:05 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA07758 for linux-audio-dev-list; Sun, 17 Oct 1999 22:02:21 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA07755 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 17 Oct 1999 22:02:19 -0400
Received: from someip.ppp.op.net (d-bm3-18.ppp.op.net [209.152.194.88]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id VAA23224 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 17 Oct 1999 21:57:05 -0400 (EDT)
Message-Id: <199910180157.VAA23224@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] back to the API 
In-reply-to: Your message of "Sun, 17 Oct 1999 19:23:34 +0200."
             <99101722201901.00724@localhost.localdomain> 
Date: Sun, 17 Oct 1999 22:53:30 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 8a90d4ca332be968149e8f14ab667dfd

>>      1) data size: audio (N samples per call to process (); likely
>>                           to be N >= 32 ... 128 bytes for RT; non-RT
>
>How does a sampleplayer interface with a streaming/caching "daemon"?
>(A special case that shouldn't be supported?)

can you elaborate on the problem ? it did occur to me, BTW, that in
your scenario of the engine outsourcing to a client the job of sending
output to an actual audio output source, there is *no* way to reliably
determine the fixed latency that is needed to compute sample-accurate
timestamps. you have no idea what the client is doing with the data. i
suppose that our API could require the client to give us a number and
post events if it ever changes.

>> 			  processing might go way higher ... 4KB ?)
>
>(IIRC, VST had a 32 kB default buffer size before they realized you
>don't want to wait for ages to hear the effect of an automation
>edit...)

thats reasonable, but if you want to use a really great reverb (say,
convolution based) fed through a fancy plugin and you know it will
take hours to generate, large buffers *might* be a good idea.

>But how different is sending an event from passing an extra argument
>to process()?

in one of your descriptions, you talked about a plugin having "one
input audio port and one output audio port". i think that having just
one of each is a bad idea. but anyway, i don't think that any of this
stuff should be passed as an argument to process() anyway. instead, we
want something like this:

	  struct plugin {
	         int process (struct plugin *);
		 .
		 .
		 .
		 audio_port_t *audio_input;
		 audio_port_t *audio_output;
		 event_list_t event_list;
         };

the engine can then manipulate

    plugin->audio_input[0]

etc. before calling process(), passing it a pointer to "itself". think
"closures" ...

>As for events and out-of-band, non real time transfer;
>1) Set up you data buffer.
>2) Send the event "Yo! There's a buffer for ya' at &buffer".
>3) Stay off the buffer...
>4) ...until you get the event "Ok, got it. (&buffer)"

sounds like what i had in mind, with the addition of the explicit "OK,
got it (&buffer)". i think this is the way to handle things like this.

>The reason why I decided on the qm allocator with heaps for the
>events is that it allows quick allocation of lots of small blocks
>without fragmentation. It also replaces deallocation with garbage
>collection in a very low cost way. (When a qm_heap_t is replaces a
>buffer, the reference to the old one goes where the data will be
>used, and is flushed from there.)

at the moment, i am preferring an implementation that uses fixed event
sizes, since events are just "differences that make a difference". you
don't need a heap or a real allocator at all - you use a pool system
identical to the incredibly efficient one used in the kernel. it took
me a while to figure out how it worked, and it probably dates back to
the 60's, but its really cool, and really fast. it looks like a
freelist, but it isn't, really.

assumption: every object to be allocated has a pointer to another
object of the same kind that is usable when the object is
"deallocated".

Pool setup:

        struct object_pool {
	       object_t *objs;
	       object_t *next_free;
	};

	1) allocate a pool of the objects:

	   object_pool.objs = (object_t) malloc (sizeof(object_t) * POOL_SIZE);

	2) connect each "next" pointer to make a free list

	   for (i = 0; i < POOL_SIZE - 1; i++) {
	       object_pool.objs[i]->next = &object_pool.objs[i+1];
	   }
	   
	3) mark the top of the freelist

	   object_pool.next_free = object_pool.objs[i];

object allocation:

	object_t *
	alloc_object ()
	{
		object_t *obj;

		obj = object_pool.next_free;
		object_pool.next_free = obj->next;
		/* for safety, do: obj->next = 0; */
		return obj;
	}

object deallocation:

	void
	dealloc_object ()
	{
		obj->next = object_pool.next_free;
		object_pool.next_free = obj;
	}
	
this is not all correct, and it does handle OOM conditions. however,
you'll find this basic structure all over the kernel. its beautiful,
really beautiful. 

>As soon as the global heap of buffers is turned into a freelist, we
>get search and splitt overhead, risk of complicated memory leak bugs,
>deallocation overhead, and most importantly; _memory fragmentation_.

nope. not if the objects are all the same size. 

i am now waiting for your obvious explanation of why events cannot all
be the same size, and then why all buffers cannot be the same size,
since we have already talked about a scheme in which the engine
decides the optimum buffer size based on plugin requirements. 

furthermore, since changing buffer size is a pretty drastic thing to
do to the system (many small details to handle if this ever happens),
it seems not unreasonable to just set up a new buffer pool, and maybe
discard the old one, though this seems harder.

so i see us having 2 pools of (differently) fixed sized objects,
events and buffers, using this kernel-style allocation mechanism.

and of course, note that since only the engine allocates and
deallocates from both pools, no locks are necessary.


>> this has its problems, not least of which is
>> atomicity of the contents of the memory. if the plugin has been told
>> that, say, a string value has changed, but then the string changes
>> again before/while its looking at it, this is, uhm, not good :)
>
>If you tell someone that you put a ladder in the right place, you
>don't move it away just when he's about to step on it, do you? :-)

sure. the solution is actually pretty obvious:

      void *get_string_pointer (const char *str) 
      {
		... lookup existing strings, perhaps via hash ...
		if found, return pointer to string
		if not found, alloc "global" memory, store string there, 
		   and return pointer.
      }

then, when you want to say "input file just changed to XXX", you
actually say "input file just changed (value at <address>)", and now
we now that the address will always hold that value. if necessary, we
can do reference counting too, to ensure that we can periodically
sweep away stale values.

--p

From - Wed Oct 20 01:23:37 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA15698
	for <slinkp@ulster.net>; Mon, 18 Oct 1999 13:21:47 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA12914 for linux-audio-dev-list; Mon, 18 Oct 1999 12:38:10 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA12911 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 18 Oct 1999 12:38:07 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46234AbPJRQcU>; Mon, 18 Oct 1999 19:32:20 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <199910152053.QAA27121@renoir.op.net> (message from Paul
	Barton-Davis on Fri, 15 Oct 1999 17:49:47 -0400)
Subject: Re: [linux-audio-dev] multiple files/single files for HDR: my verdict
Message-Id: <19991018163233Z46234-563+321@nic.funet.fi>
Date:   Mon, 18 Oct 1999 19:32:20 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 6556a8693abbda6e183b7399b438cb90

>From:   Paul Barton-Davis <pbd@Op.Net>
>
>controllably, it seems to me that you particularly do *not* want to
>use an editlist.

Exactly opposite: *I do want* use an editlist. [Maybe my mails on it didn't
arrive at you.]

*You do want* use some kludge mixtura of files and possible editlist
(which about -- as used with your kludge -- I have not seen anything here).

When a third party program reads your files, it doesn't see your kludge
file system usage -- you need to pass an editlist separately in anyway.
So, why to complicate the system with some kludge?

But when I see details I'm able to make true comparison between the both
systems!

Yours,

Juhana

From - Wed Oct 20 01:23:40 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA27650
	for <slinkp@ulster.net>; Mon, 18 Oct 1999 14:40:19 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA13129 for linux-audio-dev-list; Mon, 18 Oct 1999 14:11:21 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA13125 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 18 Oct 1999 14:11:15 -0400
Received: from someip.ppp.op.net (d-bm3-01.ppp.op.net [209.152.194.65]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id OAA27588 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 18 Oct 1999 14:05:49 -0400 (EDT)
Message-Id: <199910181805.OAA27588@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] using ext2fs "holes" in files
In-reply-to: Your message of "Mon, 18 Oct 1999 19:32:20 +0300."
             <19991018163233Z46234-563+321@nic.funet.fi> 
Date: Mon, 18 Oct 1999 15:02:23 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b70b36a749376e9537197fb32f951c01

>*You do want* use some kludge mixtura of files and possible editlist
>(which about -- as used with your kludge -- I have not seen anything here).

Juhana, i don't know about you, but as a programmer, i take the phrase
"your kludge" rather personally. i don't know if its how you meant it,
but it comes across to me as a very negative and rather personal
statement.

first of all, i would have to be stupid to be against editlists for
programs that *edit* files and want to do so in an efficient,
non-destructive fashion. However, neither of those characteristics
describe my program. my not using an editlist has *nothing* do do with
the fact that a filesystem supports "holes" in files - it is because
my program doesn't do anything that makes sense for editlist use. if i
gave you the impression that i planned to use an editlist as well,
then i gave you the wrong impression, somehow.

furthermore, i don't rely in any way on whether or not "holes" are
supported. all i do is to lseek to the right offset in a file and
write there: i don't care whether the fs zero fills real disk blocks,
uses holes or whatever. All I care about is that POSIX says that
whenever i read back the file, I will read zeros in from any offsets
that I skipped without having previously written them.

it just so happens that ext2fs (and some of its predecessor file
systems) were designed to allow files with "holes" as an efficient use
of disk space, but thats just an implementation detail that adds an
additional, but not central argument in favor of doing this.

>When a third party program reads your files, it doesn't see your kludge
>file system usage -- you need to pass an editlist separately in anyway.
>So, why to complicate the system with some kludge?

No! Please read the man page for lseek(2). When *any* program reads a
file with holes, it reads zeroes for as many bytes as the hole is
large. Why do you keep calling this a kludge ? there is no way for an
application to have any idea that it is reading a hole instead of
zeroes from the disk except for speed of access (the holes will be
faster) or by carefully checking the results of various system calls
like stat(2).

let me say that again: *ANY* program can read a file created with
holes, without any special tricks or knowledge about the structure of
the file. but they are not a substitute for an editlist where an
editlist makes sense. not least because once you write any data to a
byte within the hole, that byte can never return to being part of a
hole (and, given implementation realities, neither can the disk block
it was part of).

--p

From - Wed Oct 20 01:23:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA06970
	for <slinkp@ulster.net>; Mon, 18 Oct 1999 18:56:36 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA13534 for linux-audio-dev-list; Mon, 18 Oct 1999 18:29:23 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA13531 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 18 Oct 1999 18:29:20 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46567AbPJRWXe>; Tue, 19 Oct 1999 01:23:34 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <199910181805.OAA27588@renoir.op.net> (message from Paul
	Barton-Davis on Mon, 18 Oct 1999 15:02:23 -0400)
Subject: Re: [linux-audio-dev] using ext2fs "holes" in files
Message-Id: <19991018222347Z46567-563+334@nic.funet.fi>
Date:   Tue, 19 Oct 1999 01:23:34 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c9b9930e155db14a6376821521d3e0f0

>From:   Paul Barton-Davis <pbd@Op.Net>
>
>>*You do want* use some kludge mixtura of files and possible editlist
>>(which about -- as used with your kludge -- I have not seen anything here).
>
>Juhana, i don't know about you, but as a programmer, i take the phrase
>"your kludge" rather personally. i don't know if its how you meant it,
>but it comes across to me as a very negative and rather personal
>statement.

I'm terribly sorry! I just meant "your suggestion" rather than anything
negative.

I admit that claiming me not interested in using editlist, got me tensed
but that is another story.

>my program doesn't do anything that makes sense for editlist use. if i
>gave you the impression that i planned to use an editlist as well,
>then i gave you the wrong impression, somehow.

Ok, somehow. :-)
All right, your application seems to spend very much disk space:
all loops and other repetitions take new disk space every time when they
appear in the mix, and if you run an effect on a track, it fills the holes.
All editing and processing is destructive unless we bounce the result to
another track.

Perhaps that is the purpose of your program but it wastes too much disk
space.

>No! Please read the man page for lseek(2). When *any* program reads a
>file with holes, it reads zeroes for as many bytes as the hole is

I didn't mean that. Only the cases such as backupping to cdrom (it fills
the holes) or an application converting the file to some other format.

 -*-

Well, I think editlist-only is the way to go. Recording etc. happens
always to a new file. Or if we want destructive operations, new files
are created only at head and tail of an old file which is overwritten.
And so on...

We would have a full control over what is on the disk, on backup cdroms,
what other applications should read, etc.

I don't want argue on this and thus at least I move to think how such HDR
application would function.

Yours,

Juhana

From - Wed Oct 20 01:23:43 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA21950
	for <slinkp@ulster.net>; Mon, 18 Oct 1999 20:27:32 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA13677 for linux-audio-dev-list; Mon, 18 Oct 1999 20:03:39 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA13674 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 18 Oct 1999 20:03:36 -0400
Received: from localhost.localdomain (d212-151-46-73.swipnet.se [212.151.46.73]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA07482; 
          Tue, 19 Oct 1999 01:58:12 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] back to the API
Date: Tue, 19 Oct 1999 00:42:59 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910180157.VAA23224@renoir.op.net>
In-Reply-To: <199910180157.VAA23224@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101902051700.00441@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id BAA07482
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA21950
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7eea3d4cf8e78a927ef47268c9f8ea83

On Mon, 18 Oct 1999, Paul Barton-Davis wrote:
> >>      1) data size: audio (N samples per call to process (); likely
> >>                           to be N >= 32 ... 128 bytes for RT; non-RT
> >
> >How does a sampleplayer interface with a streaming/caching "daemon"?
> >(A special case that shouldn't be supported?)
> 
> can you elaborate on the problem ?

Variable rate streaming. The streaming/caching "daemon" will only
provide guaranteed bandwidth streaming, caching, prebufferng of
real time starting points and that kind of things, while resampling
should be done in other plug-ins. Considering the cost of high
quality resampling, and the fact that some people might want to use
pitch changing (with preserved duration) instead, suggests that
hardcoding it into a big "universal" sampleplayer is a bad idea.
Streaming/caching/prebuffering is a rather complex subsystem in
itself, and it's also very problematic to run more than one per hard
drive, so it should be made as a reusable module. Probably a client,
so that you can use the one that works best for you with your
favourite applications. A standard API for plug-ins should be
defined, so that you can hook up a stream from the streaming/caching
daemon to any plug-in that supports variable rate inputs.

Variable rate outputs? What about data compressors, or simply a max
input frequency -> sample rate "shaper" plug-in? This *will* be
required by some users (hey, some even suggest using mp3 for HDR
*NOW*!), so why not plan it in, rather than breaking the API later on?

> it did occur to me, BTW, that in
> your scenario of the engine outsourcing to a client the job of sending
> output to an actual audio output source, there is *no* way to reliably
> determine the fixed latency that is needed to compute sample-accurate
> timestamps. you have no idea what the client is doing with the data.

A ploblem that is simply ignored by VST and (AFAIK) DirectX. While I
thought about it years ago, of course. ;-)

It seeed obvious to me that ignoring the fact that just about *any*
DSP algorithm will have unavoidable delays, couldn't be a good idea.
True, it doesn't matter much to most users, and it's not compensated
for in analog systems (analog filters *do* have latency!), but I've
always been too much of a perfectionist when it comes to this kind of
things...

> i
> suppose that our API could require the client to give us a number and
> post events if it ever changes.

I already described the foundation for that in one of my first posts:

------8<-----------------------------------------------------------
	float inherent_delay;	/* Inherent means inherent to the
				 * processing algorithm, and is
				 * used for processing latency
				 * compensation.
				 * Value is in frames, and should
				 * reflect sub-sample resolution.
				 */
	int look_ahead;		/* Number of extra frames needed
				 * after the end of input buffers.
				 * Can be negative.
				 */
	int skip_behind;	/* Number of frames skipped
				 * at the start of input buffers.
				 * (That is, inputs[n]+=look_behind
				 * before process_XXX() is called.)
				 * Can be negative.
				 */
----------------------------------------------------------->8------

The same functionality should be in the event based API, and should
also be used for clients.

> >> 			  processing might go way higher ... 4KB ?)
> >
> >(IIRC, VST had a 32 kB default buffer size before they realized you
> >don't want to wait for ages to hear the effect of an automation
> >edit...)
> 
> thats reasonable, but if you want to use a really great reverb (say,
> convolution based) fed through a fancy plugin and you know it will
> take hours to generate, large buffers *might* be a good idea.

Yes indeed. Off-line processing... Is 2 GB/buffer on 32 bit systems an
accpetable limit? :-)

> >But how different is sending an event from passing an extra argument
> >to process()?
> 
> in one of your descriptions, you talked about a plugin having "one
> input audio port and one output audio port".

Uhm, did I say that? Well, either I was thinking about some kind of
multichannel ports (bad idea, if I was), or actually meant event
ports. (My old design had just one event output - it looks different
in the new one. More on that later.)

> i think that having just
> one of each is a bad idea. but anyway, i don't think that any of this
> stuff should be passed as an argument to process() anyway. instead, we
> want something like this:
> 
> 	  struct plugin {
> 	         int process (struct plugin *);
> 		 .
> 		 .
> 		 .
> 		 audio_port_t *audio_input;
> 		 audio_port_t *audio_output;
> 		 event_list_t event_list;
>          };
> 
> the engine can then manipulate
> 
>     plugin->audio_input[0]
> 
> etc. before calling process(), passing it a pointer to "itself". think
> "closures" ...

Yes, I wasn't thinking about the argument passing method, but about
the event vs. [argument,variable,...] distinction.

Anyway, I think the closure should be kept as far away from the API
as possible. As I see it, it's a *private* struct, possibly with a
very simple public header struct.

>     plugin->audio_input[0]

Won't work unless we set a fiked size on the arrays. Instead, the
plug-in should give the engine the size and address of the tables
during init. Perhaps even the addres of each audio port (or "stream
port", as I'd prefer to call it). Or, the info can be filled into
that public header struct, but that would mean eliminating the
pointer-per-port style.

What's the point with the "pointer-per-port style", BTW? Making the
plug-in process() code simpler by keeping all data for one channel in
one struct. That struct could be a bigger one, extending the public
port struct as needed - which cannot be done with tables. Don't know
if it matters much, or even is a good idea, but it seems nice to me
right now...

> >As for events and out-of-band, non real time transfer;
> >1) Set up you data buffer.
> >2) Send the event "Yo! There's a buffer for ya' at &buffer".
> >3) Stay off the buffer...
> >4) ...until you get the event "Ok, got it. (&buffer)"
> 
> sounds like what i had in mind, with the addition of the explicit "OK,
> got it (&buffer)". i think this is the way to handle things like this.

That's how you do IPC with shared memory in the normal case, only
there you send the "events" as true real time messages. We can't do
that (except with clients - where it's possible to get the extreme
context switching rates back if you really want to), so we buffer up
as many events, notifications and requests as possible, and send the
whole "transaction" off when our cycle ends. Makes sense to me for
the kind of systems we're dealing with, as it makes it possible to
control the worst case latency for the real time stuff, while
worsening the average latency a bit.

> >The reason why I decided on the qm allocator with heaps for the
> >events is that it allows quick allocation of lots of small blocks
> >without fragmentation. It also replaces deallocation with garbage
> >collection in a very low cost way. (When a qm_heap_t is replaces a
> >buffer, the reference to the old one goes where the data will be
> >used, and is flushed from there.)
> 
> at the moment, i am preferring an implementation that uses fixed event
> sizes, since events are just "differences that make a difference".

How big?

> you
> don't need a heap or a real allocator at all - you use a pool system
> identical to the incredibly efficient one used in the kernel. it took
> me a while to figure out how it worked, and it probably dates back to
> the 60's, but its really cool, and really fast. it looks like a
> freelist, but it isn't, really.
> 
> assumption: every object to be allocated has a pointer to another
> object of the same kind that is usable when the object is
> "deallocated".
> 
> Pool setup:
> 
>         struct object_pool {
> 	       object_t *objs;
> 	       object_t *next_free;
> 	};
> 
> 	1) allocate a pool of the objects:
> 
> 	   object_pool.objs = (object_t) malloc (sizeof(object_t) * POOL_SIZE);
> 
> 	2) connect each "next" pointer to make a free list
> 
> 	   for (i = 0; i < POOL_SIZE - 1; i++) {
> 	       object_pool.objs[i]->next = &object_pool.objs[i+1];
> 	   }
> 	   
> 	3) mark the top of the freelist
> 
> 	   object_pool.next_free = object_pool.objs[i];
> 
> object allocation:
> 
> 	object_t *
> 	alloc_object ()
> 	{
> 		object_t *obj;
> 
> 		obj = object_pool.next_free;
> 		object_pool.next_free = obj->next;
> 		/* for safety, do: obj->next = 0; */
> 		return obj;
> 	}
> 
> object deallocation:
> 
> 	void
> 	dealloc_object ()
> 	{
> 		obj->next = object_pool.next_free;
> 		object_pool.next_free = obj;
> 	}
> 	
> this is not all correct, and it does handle OOM conditions. however,
> you'll find this basic structure all over the kernel. its beautiful,
> really beautiful. 

Yep. :-) That's exactly what I had in mind for audio buffers. Cache
optimization, speed and simplicity at the same time. BTW, MidiShare
uses a system of that kind, IIRC.

> >As soon as the global heap of buffers is turned into a freelist, we
> >get search and splitt overhead, risk of complicated memory leak bugs,
> >deallocation overhead, and most importantly; _memory fragmentation_.
> 
> nope. not if the objects are all the same size. 

Well, I was thinking about allocation of data buffers, not the
events themselves. Eventmemory management is not a problem, not even
with dynamic size with a sane size limit.

> i am now waiting for your obvious explanation of why events cannot all
> be the same size, and then why all buffers cannot be the same size,

Does an event have one or two arguments? Or three? Should there be
room for doubles? Is it safe to split too big events into multiple
events, with respect to ordering of events with the same timestamp?
(I think they should come in the order they're sent, but what if
someone else is sending the same kind of events to the same place?)

I was thinking fixed size from the very beginning, but it's more of a
"simple solution for now" than anything else IMO. I don't like being
forced into cludges to work around legacy design limitations...

> since we have already talked about a scheme in which the engine
> decides the optimum buffer size based on plugin requirements. 

That's an optimization for the normal case; constant rate streaming.
Not a generic solution for all kinds of real time streaming.

> furthermore, since changing buffer size is a pretty drastic thing to
> do to the system (many small details to handle if this ever happens),
> it seems not unreasonable to just set up a new buffer pool, and maybe
> discard the old one, though this seems harder.

In real time...? You could discard the old pool *before* setting up
the new one, but that brings other problems with it... And it
certainly doesn't work for dynamic rate streaming.

> so i see us having 2 pools of (differently) fixed sized objects,
> events and buffers, using this kernel-style allocation mechanism.

That would be nice and simple, and I used to like it once upon a
time. I still like it where it does tho job nicely, and no extra
flexibility is needed, but I've changed my mind about more generic
systems.

> and of course, note that since only the engine allocates and
> deallocates from both pools, no locks are necessary.

How do you send events to the engine from other threads in that case?

> >> this has its problems, not least of which is
> >> atomicity of the contents of the memory. if the plugin has been told
> >> that, say, a string value has changed, but then the string changes
> >> again before/while its looking at it, this is, uhm, not good :)
> >
> >If you tell someone that you put a ladder in the right place, you
> >don't move it away just when he's about to step on it, do you? :-)
> 
> sure. the solution is actually pretty obvious:
> 
>       void *get_string_pointer (const char *str) 
>       {
> 		... lookup existing strings, perhaps via hash ...
> 		if found, return pointer to string
> 		if not found, alloc "global" memory, store string there, 
> 		   and return pointer.
>       }
> 
> then, when you want to say "input file just changed to XXX", you
> actually say "input file just changed (value at <address>)", and now
> we now that the address will always hold that value. if necessary, we
> can do reference counting too, to ensure that we can periodically
> sweep away stale values.

Sounds way too expensive, and more importantly undeterministic, for a
real time system. And unless the lookup really finds a string most of
the time, you might as well copy the data right away. I think a
sensible, well defined protocol can eliminate the "ladder removal"
problem and optimize away most of the reference counting overhead.
But the fragmentation problem is still not solved...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Oct 20 01:23:47 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA06556
	for <slinkp@ulster.net>; Mon, 18 Oct 1999 22:11:14 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA13906 for linux-audio-dev-list; Mon, 18 Oct 1999 21:49:15 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA13903 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 18 Oct 1999 21:49:13 -0400
Received: from someip.ppp.op.net (d-bm3-15.ppp.op.net [209.152.194.85]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id VAA13510 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 18 Oct 1999 21:43:56 -0400 (EDT)
Message-Id: <199910190143.VAA13510@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] using ext2fs "holes" in files 
In-reply-to: Your message of "Tue, 19 Oct 1999 01:23:34 +0300."
             <19991018222347Z46567-563+334@nic.funet.fi> 
Date: Mon, 18 Oct 1999 22:40:34 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 732950571e91439b4479503d450b8fc5

>All right, your application seems to spend very much disk space:
>all loops and other repetitions take new disk space every time when they
>appear in the mix, and if you run an effect on a track, it fills the holes.
>All editing and processing is destructive unless we bounce the result to
>another track.

there is no editing, and no processing. its a *live* multitrack
HDR. although it can handle other soundfiles and its own "tape" format
as input sources, its not intended to be used for soundfile editing.

>I didn't mean that. Only the cases such as backupping to cdrom (it fills
>the holes) or an application converting the file to some other format.

ah, OK, understood. yes, under those circumstances, you will end up
with the full block allocation that the file "size" would suggest. for
the way i work, this doesn't bother me. i also see it as the
responsibility of a "soundfile-aware" application that can support its
own editlist-based format to look for extended periods of silence in a
channel, and convert them into editlist equivalents. but you don't
*start* from such a format, since it requires every other program to
understand *your* editlist system.

>I don't want argue on this and thus at least I move to think how such HDR
>application would function.

i don't like thinking too much without coding. so i did, and its
pretty functional and pretty useful. i hope to release a copy over the
coming weekend.

the important thing for me is that my program is *not* aimed at the
kind of HDR that any program with an editlist would do. its intended
to be the equivalent of, say, a hand-held portable ADAT recorder, or
better yet, one of those small digital recording consoles that people
like Yamaha make. i *need* a program like this, and i consider it a
quite different kind of program. just as you wouldn't use an ADAT
machine with a mixing console to do non-destructive, non-linear
editing, you wouldn't use this program for that either. on the other
hand, if you've got 12 channels of input, 5 of them live and 7 of them
pre-recorded, and you want a recording of the overall "take", for
later editing with <insert-editlist-based-soundfile-editor-here>, then
my "hdr" program is possibly exactly what you want.

--p


From - Wed Oct 20 01:23:49 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA15981
	for <slinkp@ulster.net>; Mon, 18 Oct 1999 23:12:50 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA13984 for linux-audio-dev-list; Mon, 18 Oct 1999 22:50:29 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA13981 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 18 Oct 1999 22:50:27 -0400
Received: from localhost.localdomain (d212-151-46-73.swipnet.se [212.151.46.73]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id EAA23884; 
          Tue, 19 Oct 1999 04:45:07 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] using ext2fs "holes" in files
Date: Tue, 19 Oct 1999 04:48:40 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910190143.VAA13510@renoir.op.net>
In-Reply-To: <199910190143.VAA13510@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101904521703.00441@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id EAA23884
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id XAA15981
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d6dc0d513bc291d72a5208a04ae620ed

On Tue, 19 Oct 1999, Paul Barton-Davis wrote:
> the important thing for me is that my program is *not* aimed at the
> kind of HDR that any program with an editlist would do. its intended
> to be the equivalent of, say, a hand-held portable ADAT recorder, or
> better yet, one of those small digital recording consoles that people
> like Yamaha make. i *need* a program like this, and i consider it a
> quite different kind of program. just as you wouldn't use an ADAT
> machine with a mixing console to do non-destructive, non-linear
> editing, you wouldn't use this program for that either. on the other
> hand, if you've got 12 channels of input, 5 of them live and 7 of them
> pre-recorded, and you want a recording of the overall "take", for
> later editing with <insert-editlist-based-soundfile-editor-here>, then
> my "hdr" program is possibly exactly what you want.

Also, a simple design and an uncluttered UI makes a lot of sense in
live situations. It's easier to write a reliable application that
way, and there's less risk of user mistakes. I would never use CuBase
or Cakewalk for that, even if they were available for real OSes...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Oct 20 01:23:54 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA22455
	for <slinkp@ulster.net>; Tue, 19 Oct 1999 00:11:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA14122 for linux-audio-dev-list; Mon, 18 Oct 1999 23:50:47 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA14119 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 18 Oct 1999 23:50:44 -0400
Received: from localhost.localdomain (d212-151-91-97.swipnet.se [212.151.91.97]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id FAA12720 for <linux-audio-dev@ginette.musique.umontreal.ca>; 
          Tue, 19 Oct 1999 05:45:26 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] MuCoS: New "radical" changes!
Date: Tue, 19 Oct 1999 04:57:05 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <99101905523604.00441@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id FAA12720
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id AAA22455
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 286a9b986f3c96386b3c3e201542e231

Inspired by an idea of Roger Larsson's (private mail in swedish), and
my coming to the conclusion that there is only

1) everything fixed size,
2) virtual memory with hardware support, or
3) memory segmentation handled by the code,

I decided to give the third alternative a shot.

Motivation:
1) is to restrictive, and will become a cumbersome legacy problem
sooner or later, if not right from the start. There is a reason why
I'm still thinking rather than having yet another VST style engine
in running code. (Perhaps I'm expecting too much from the new API,
but hey, you go ahead and code something in the classic style while
I "waste" my time! If I come up with something useful, and use it if
you like... I like designing, so I don't mind. :-)

2) is too expensive on most architectures (modifying + flushing VMTs),
and also requires a kernel hack if we are to use it for real time.
(Unless there is a way to lock memory *before* you malloc() it...)

Solution (?):
Now, 3) is usually nothing but a major PITA. (Remember 16 bit
protected mode, or perhaps even real mode? Or the REU for the C64?)
However, as we're dealing with a) events and b) buffers anyway, it
doesn't have to make all that much difference.

(Beware, Paul; you won't like this! ;-)

We had this discussion on events, some ideas about using events for
audio buffer info and so on. Roger had this idea of a different
design, that's even more event oriented than my plans so far... And I
realized that there is a use for the "new audio buffer" event:
eliminating the memory allocation problem. Well, almost. It's no
magic, but it'll solve a very serious problem, and brings some bonus
in the form of simplifying dynamic streaming rate support.

1) Have a "new buffer for channel X starts now" event, and
   just handle it as usual in process(). (Possibly, the
   event can handle multiple channels - a performance hack
   for the average case.)

2) Make the engine insert those events when needed - in the
   normal case; first in the event input buffer.

3) Have fun!

There is now no restrictive connection between the stream buffer size
and the cycle rate. (Other than that using a buffer size that's a few
samples short of the cycle time is a bit inefficient. However, it
still means only some extra events - no function calls with the
complexity of getting it done right in the engine.)

BTW, this eliminates the need for public stream ports in a quite
natural way. A stream port becomes an invisible abstraction accessed
through events, and the implementation details can be tailored for
speed or convenience as the plugin hacker desires.

Oh, the GIMP uses tiled buffers when communicating with it's plugins
these days. But that's for a slightly different reason; huge images
don't fit in RAM, and this way is a lot more efficient than
swapping... It works (obviously!), but I'd guess it means a little
extra trouble for them, compared to our case - we have to deal with
lots of buffer boundaries all the time anyway.

"The Right Thing" would be way too inefficient, and I still don't
think that "Worse Is Better" to the extent of going back to the fixed
size everything model. I think this seems pretty close to "The Right
Thing", even if the "new buffer for channel X starts now" event
perhaps looks like a "Worse Is Better" style thing... If it can't be
logically perfect, let's at least make it simple and efficient. :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Oct 20 01:23:50 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA16003
	for <slinkp@ulster.net>; Mon, 18 Oct 1999 23:13:01 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA13978 for linux-audio-dev-list; Mon, 18 Oct 1999 22:48:44 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA13975 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 18 Oct 1999 22:48:42 -0400
Received: from someip.ppp.op.net (d-bm3-15.ppp.op.net [209.152.194.85]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id WAA17981 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 18 Oct 1999 22:43:23 -0400 (EDT)
Message-Id: <199910190243.WAA17981@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] back to the API 
In-reply-to: Your message of "Tue, 19 Oct 1999 00:42:59 +0200."
             <99101902051700.00441@localhost.localdomain> 
Date: Mon, 18 Oct 1999 23:40:02 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1e6984b05295c2cdb1fd0c4f2e3fd8bc

>Anyway, I think the closure should be kept as far away from the API
>as possible. As I see it, it's a *private* struct, possibly with a
>very simple public header struct.

i see it oppositely: the API has to define what gets passed to various
plugin function calls. By making it the plugin itself, the API becomes
completely amenable to source-code compatible alteration. If you
specify anything else, any time you want to change the argument type
or number, everything needs to be recoded, not just recompiled.

before I get going, some suggested terminology changes:

destination "ports" are not at all similar to source "ports".
destinations contain LISP-like linked lists of ptrs to events in
sources' "typical-C-like" linked lists. 

so ... i am using the term "event source" for a "source port" - a
place where events appear from the engine's POV - and "event
destination" for places where a pointer to the event gets posted
(i.e. where they appear from a plugin/client POV).

> at the moment, i am preferring an implementation that uses fixed event
>> sizes, since events are just "differences that make a difference".
>
>How big?

     sizeof (event_timestamp_field) +
     sizeof (event_type_field) + 
     sizeof (event_extra_size_field) + 
     sizeof (event_target_id_field) +
     sizeof (union { 
	   .... various data types ...
     }) 

either way, i figure there should be two OOB mechanisms for events
requiring more space than fits into the union: one would use a void *
member of the union, and would point to space managed entirely by the
plugin (via some allocation/deallocation API that we provide). The
other would be via an second such member, but would point to space
allocated by the engine, and released by the engine after the event is
processed.

My current prototype-in-progress implementation looks like this:

typedef struct event {
    msc_timestamp_t ev_timestamp; /* when it happened */

#define EV_EVENT_TYPE_MASK  0x000000ff
#define EV_VALUE_TYPE_MASK  0x000fff00

#define EV_EVENT_TYPE_DELTA     0x01
#define EV_EVENT_TYPE_ABSOLUTE  0x02
#define EV_EVENT_TYPE_INCREMENT 0x03
#define EV_EVENT_TYPE_DECREMENT 0x04

#define EV_VALUE_FLOAT          0x00100
#define EV_VALUE_DOUBLE         0x00200
#define EV_VALUE_UINT32         0x00400
#define EV_VALUE_INT32          0x00800
#define EV_VALUE_UINT16         0x01000
#define EV_VALUE_INT16          0x02000
#define EV_VALUE_CHAR           0x04000
#define EV_VALUE_STRING         0x08000
#define EV_VALUE_POINTER        0x10000    /* event source allocates space */
#define EV_VALUE_DATA           0x20000    /* engine allocates space */

    unsigned int ev_type;         /* type of event */
    unsigned int ev_size;         /* zero if val.{data,v} not used, otherwise
				     specifies the size of val.{data,v}
				   */
    unsigned int ev_target_id;    /* what changed */

    union { 
	float f;
	double d;
	unsigned int u;
	int i;
	unsigned short us;
	short s;
	char c;
	char *str;
	void *v;                 /* points to non-event memory */  
	unsigned char *data;     /* points to non-event memory,
				    deleted each plugin process()
				    cycle.
				 */
				    
    } val;                       /* change value; see EVENT_TYPE_MASK 
				    to interpret.
				 */

    /* PRIVATE */

    struct event *next;

} event_t;

if we believe that a common case is to pass around, say, new absolute
values of structures rather than basic C types, then we can have a
field in the union along the lines:

      unsigned char structure[EV_MAX_DATA_SIZE];

and use it with casts. But I'd expect EV_MAX_DATA_SIZE to be small
(say 16-32 bytes).

note that events take essentially 3 arguments:

     - what changed (ev_target_id) - this may refer (from a plugin's
               point of view) to some C parameter in memory, or it
	       may not - the engine doesn't care
     - how it changed (delta from old value, absolute new value,
	       increment or decrement from old value)
     - value (interpreted based on the kind of change)

increments and decrements do not take a value argument. they are a
special case that could arguably be done away with if they turn out to
be infrequently used. it just struck me that the frequent use of C's
++ and -- operators might make it worth representing such events in a
way that avoided having to do an extra assignment when setting up the
event. 

>> >As soon as the global heap of buffers is turned into a freelist, we
>> >get search and splitt overhead, risk of complicated memory leak bugs,
>> >deallocation overhead, and most importantly; _memory fragmentation_.
>> 
>> nope. not if the objects are all the same size. 
>
>Well, I was thinking about allocation of data buffers, not the
>events themselves. Eventmemory management is not a problem, not even
>with dynamic size with a sane size limit.

i don't see why data buffers are such a problem. they don't get
allocated and deallocated very often - its not even clear to me why
malloc(3) is unacceptable. a plugin would establish its buffers at
init time, might occasionally allocate some afterwards, and would
destroy them when removed.
		   
>		   Is it safe to split too big events into multiple
>events, with respect to ordering of events with the same timestamp?
>(I think they should come in the order they're sent, but what if
>someone else is sending the same kind of events to the same place?)

can't happen. events appear at an event source. only one "object" has
access to the event source. the event can go to many event
destinations but thats different: these are just LISP-like lists of
pointers to events. the object that owns the event source posts events
to it in the order received, so that when the engine inspects all
active event sources, it finds them already sorted in time order on
any given event source. its job is to build the event cell lists for
each destination, which requires mux-ing each relevant source and
sorting by timeorder while so doing. thats all. 

i should have the prototype code working tomorrow.

>> and of course, note that since only the engine allocates and
>> deallocates from both pools, no locks are necessary.
>
>How do you send events to the engine from other threads in that case?

the engine is subscribed to all event sources. before building the
event lists for each subscriber to all active event sources, it has to
make a pass through the current events to see if there is anything
earmarked for it. it does this by inspecting the ev_target_id field,
to see if any of the message concern any of its "parameters".

but either way, the quote from me above is misleading. each
event_source has its own event pool. its only the event_cell pool
(used to build event lists for destinations) that is owned by the
engine. 

>real time system. And unless the lookup really finds a string most of
>the time, you might as well copy the data right away.

fair point. probably quite a reasonable pragmatic approach. there are
certainly some pathological cases where its the wrong thing to do, but
they would reflect a combination of bad plugin GUI programming and a
bad user interface. 

BTW: can we *please, Please, PLEASE* avoid the pseudo-OOP code ala GTK
with "simple public header structs" etc. ? C simply cannot provide
"private" and "public" compile-time safety, so trying to provide
it only makes the code harder to read, and the macros more numerous. I
am sick of writing stuff in GTK like:
   
          gc = GTK_WIDGET(t)->style->fg_gc[GTK_WIDGET_STATE(GTK_WIDGET(t))];

all of which reflects this use of "header structs" that became so
prevalent as many people wanted the benefits of OOP without the cost. 

Lets just make the structs open and clear, and mark areas that are
off-limits to plugins etc. with clear comments. It will make our life
much easier down the road, I think.

The only exception I have ever come across for this has been generic
lists, which allow manipulation of any object in a list as long as its
initial structure shares the same declarations as the "generic list
element". I haven't yet found a place in this system where that might
be useful.

--p

From - Wed Oct 20 01:23:57 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA27890
	for <slinkp@ulster.net>; Tue, 19 Oct 1999 01:20:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA14241 for linux-audio-dev-list; Tue, 19 Oct 1999 00:57:57 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA14238 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 19 Oct 1999 00:57:54 -0400
Received: from localhost.localdomain (d212-151-91-97.swipnet.se [212.151.91.97]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id GAA25811; 
          Tue, 19 Oct 1999 06:52:33 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] back to the API
Date: Tue, 19 Oct 1999 05:53:33 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910190243.WAA17981@renoir.op.net>
In-Reply-To: <199910190243.WAA17981@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101906594205.00441@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id GAA25811
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id BAA27890
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 472d56b2869f7f4c1adc6be63746c56e

On Tue, 19 Oct 1999, Paul Barton-Davis wrote:
> i see it oppositely: the API has to define what gets passed to various
> plugin function calls. By making it the plugin itself, the API becomes
> completely amenable to source-code compatible alteration. If you
> specify anything else, any time you want to change the argument type
> or number, everything needs to be recoded, not just recompiled.

How does it make a difference WRT binary level compatibility whether
the API specifies what the events should look like, or what a struct
should look like?

BTW, we need both kinds of specifications anyway, and I'd like to
get as close to keeping all important stuff in one of them as
possible. As we're dealing with a sample accurate system, the event
system seem to be the logical "main API", IMO.

> before I get going, some suggested terminology changes:
> 
> destination "ports" are not at all similar to source "ports".

Agreed. That becomes obvious when studying the routing more closely.

> destinations contain LISP-like linked lists of ptrs to events in
> sources' "typical-C-like" linked lists. 
> 
> so ... i am using the term "event source" for a "source port" - a
> place where events appear from the engine's POV - and "event
> destination" for places where a pointer to the event gets posted
> (i.e. where they appear from a plugin/client POV).

Ok...
 
> > at the moment, i am preferring an implementation that uses fixed event
> >> sizes, since events are just "differences that make a difference".
> >
> >How big?
> 
>      sizeof (event_timestamp_field) +
>      sizeof (event_type_field) + 
>      sizeof (event_extra_size_field) + 
>      sizeof (event_target_id_field) +
>      sizeof (union { 
> 	   .... various data types ...
>      }) 
> 
> either way, i figure there should be two OOB mechanisms for events
> requiring more space than fits into the union: one would use a void *
> member of the union, and would point to space managed entirely by the
> plugin (via some allocation/deallocation API that we provide).

Major problem; this still has to be implemented. And it has to work
without shared memory...

> The
> other would be via an second such member, but would point to space
> allocated by the engine, and released by the engine after the event is
> processed.

Ok. Looks a lot like my qm_heap_t, except that you can allocate space
from there from outside the engine. Same problem with memory
fragmentation and/or allocation size restrictions.

[...good lookin' event struct...]
> if we believe that a common case is to pass around, say, new absolute
> values of structures rather than basic C types, then we can have a
> field in the union along the lines:
> 
>       unsigned char structure[EV_MAX_DATA_SIZE];
> 
> and use it with casts. But I'd expect EV_MAX_DATA_SIZE to be small
> (say 16-32 bytes).
> 
> note that events take essentially 3 arguments:
> 
>      - what changed (ev_target_id) - this may refer (from a plugin's
>                point of view) to some C parameter in memory, or it
> 	       may not - the engine doesn't care
>      - how it changed (delta from old value, absolute new value,
> 	       increment or decrement from old value)

Uhm, this seems to be asking for trouble with automation and editing
of automation data... Why deltas and inc/dec? What are plugins
allowed to send?

>      - value (interpreted based on the kind of change)

Whether this is enough depends on what the event system will be used
for - and IMO, the design we're working on has too much potential to
be restricted to audio for the simple reason that you can't send more
than 32 bytes (or whatever) as a single event without extra trouble
and overhead. I believe things like a 3D sound FX system for games or
movie sound track editing would benefit from larger events... Should
we extend the "standard" when such needs become important?

(Not that we should design for the unknown future - that's a waste of
time and may make things worse - but 32 bytes seems little to me
already.)

> increments and decrements do not take a value argument. they are a
> special case that could arguably be done away with if they turn out to
> be infrequently used. it just struck me that the frequent use of C's
> ++ and -- operators might make it worth representing such events in a
> way that avoided having to do an extra assignment when setting up the
> event.

Don't know if that matters enough performance wise to support it, as
it's hardly the common case... BTW, many CPUs don't have special
INC/DEC instructions nowodays, and those that have often execute them
slower than ADD/SUB. (Not that it matters much - it's the memory
variable in the event that causes the overhead.)

> >> >As soon as the global heap of buffers is turned into a freelist, we
> >> >get search and splitt overhead, risk of complicated memory leak bugs,
> >> >deallocation overhead, and most importantly; _memory fragmentation_.
> >> 
> >> nope. not if the objects are all the same size. 
> >
> >Well, I was thinking about allocation of data buffers, not the
> >events themselves. Eventmemory management is not a problem, not even
> >with dynamic size with a sane size limit.
> 
> i don't see why data buffers are such a problem. they don't get
> allocated and deallocated very often - its not even clear to me why
> malloc(3) is unacceptable. a plugin would establish its buffers at
> init time, might occasionally allocate some afterwards, and would
> destroy them when removed.

Yes, hopefully that will be enough... Have to think more about that.

> >		   Is it safe to split too big events into multiple
> >events, with respect to ordering of events with the same timestamp?
> >(I think they should come in the order they're sent, but what if
> >someone else is sending the same kind of events to the same place?)
> 
> can't happen. events appear at an event source. only one "object" has
> access to the event source. the event can go to many event
> destinations but thats different: these are just LISP-like lists of
> pointers to events. the object that owns the event source posts events
> to it in the order received, so that when the engine inspects all
> active event sources, it finds them already sorted in time order on
> any given event source. its job is to build the event cell lists for
> each destination, which requires mux-ing each relevant source and
> sorting by timeorder while so doing. thats all.

So, you have to force every event source to use a unique kind of
event? Ok, it's rather silly to connect two sources of the same kind
of events to the same input - it should probably just not be allowed.

> i should have the prototype code working tomorrow.
> 
> >> and of course, note that since only the engine allocates and
> >> deallocates from both pools, no locks are necessary.
> >
> >How do you send events to the engine from other threads in that case?
> 
> the engine is subscribed to all event sources. before building the
> event lists for each subscriber to all active event sources, it has to
> make a pass through the current events to see if there is anything
> earmarked for it. it does this by inspecting the ev_target_id field,
> to see if any of the message concern any of its "parameters".
> 
> but either way, the quote from me above is misleading. each
> event_source has its own event pool. its only the event_cell pool
> (used to build event lists for destinations) that is owned by the
> engine. 

Ok.

> >real time system. And unless the lookup really finds a string most of
> >the time, you might as well copy the data right away.
> 
> fair point. probably quite a reasonable pragmatic approach. there are
> certainly some pathological cases where its the wrong thing to do, but
> they would reflect a combination of bad plugin GUI programming and a
> bad user interface. 
> 
> BTW: can we *please, Please, PLEASE* avoid the pseudo-OOP code ala GTK
> with "simple public header structs" etc. ? C simply cannot provide
> "private" and "public" compile-time safety, so trying to provide
> it only makes the code harder to read, and the macros more numerous. I
> am sick of writing stuff in GTK like:
>    
>           gc = GTK_WIDGET(t)->style->fg_gc[GTK_WIDGET_STATE(GTK_WIDGET(t))];
> 
> all of which reflects this use of "header structs" that became so
> prevalent as many people wanted the benefits of OOP without the cost. 
> 
> Lets just make the structs open and clear, and mark areas that are
> off-limits to plugins etc. with clear comments. It will make our life
> much easier down the road, I think.

Good point, but that's not exactly what I meant. How could you
possibly give the engine anything but a void * to you closure, if
it's not 100% defined in the API, or 100% private to the plugin?
Further, how do you optimize engines without breaking plugin binary
compatibility, if you have "private" implementation stuff in the API?

It's going to be some uggly code somewhere, but I'd rather have that
in the engine, so there will be nothing of the above in plugin code.
*Possibly*, there will be special instantiation calls that allow the
engine to add internal stuff to the same memory blocks as some
structs, but that would have to be *strongly* motivated.

> The only exception I have ever come across for this has been generic
> lists, which allow manipulation of any object in a list as long as its
> initial structure shares the same declarations as the "generic list
> element". I haven't yet found a place in this system where that might
> be useful.

Neither have I. Most of the structures will be handled by inline code
in plugins anyway, for performance reasons. The things that are
implementation specific shouldn't show up in the API spec at all,
not even as macros containing things like 'char _private_stuff[64]' or
whatever. That might not be enough anyway, and results in *really*
messy engine source code still without really isolating the
implementation from the interface - the hardcoded struct size is
still there... It would probably be nicer to have the engine
allocate the memory, or in the case of the closure/instance struct, A
void * to something "engine private".


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Oct 20 01:24:01 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA29889
	for <slinkp@ulster.net>; Tue, 19 Oct 1999 01:51:29 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id BAA18182 for linux-audio-dev-list; Tue, 19 Oct 1999 01:29:53 -0400
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA18179 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 19 Oct 1999 01:29:51 -0400
Received: from localhost.localdomain (d212-151-91-97.swipnet.se [212.151.91.97]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id HAA23699; 
          Tue, 19 Oct 1999 07:24:31 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] MuCoS: New "radical" changes!
Date: Tue, 19 Oct 1999 07:04:03 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910190421.AAA24692@renoir.op.net>
In-Reply-To: <199910190421.AAA24692@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101907314106.00441@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb05.swip.net id HAA23699
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id BAA29889
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 31712d5cf321e3db2d3a16ffd163c35e

On Tue, 19 Oct 1999, Paul Barton-Davis wrote:
> >1) Have a "new buffer for channel X starts now" event, and
> >   just handle it as usual in process(). (Possibly, the
> >   event can handle multiple channels - a performance hack
> >   for the average case.)
> >
> >2) Make the engine insert those events when needed - in the
> >   normal case; first in the event input buffer.
> >
> >3) Have fun!
> 
> what makes you think I wouldn't like this ? i love it!

Just a joke related to the Gregory Bateson inspired post; events vs.
streams. :-)

> although i
> don't quite see how it can work. what does the event mean ? 

The event means that the timestamp is where to stop processing and
handle the event (as always), and that event carries the pointer to
the next buffer for a certain channel. That is, you handle the event
by grabbing the pointer, possibly resetting the index variable for
that channel (unless you increment the pointer), and then go back to
processing until there time of the next event.

The total number of samples to process during the call can be passed
through the first event in the buffer or a terminator event - the
latter probably being the least expensive for the plugin, while the
former avoids the engine having to traverse the event list to find
out where to insert that terminator...

> also, i still don't see any need for a particularly fancy scheme for
> handling buffer allocation. its so rare, and they are so long-lived
> and so intimately connected with the construction of the processing
> net that all of your usual RT-concerns don't seem to apply here.

A LIFO stack (ar call it a pool) of equally sized buffers that the
engine can grab when it needs them. Minimum memory use, maximum
simplicity, and good cache optimization. And with the "new buffer"
approach, it still works if you need dynamic rate streaming.

> my vision of this: a buffer gets one or more input buffers which it
> can't touch (const unsigned char * const :).

Why not just forget about reserved buffers altogether (except for
private buffers that plugins may need), and grab them from the pool as
needed? The cache will love it! :-)

> if it needs any internal
> buffers, they are allocated at init time,

Yes. Most plugins will probably be capable of estimating the maximum
buffer size they need. If not, perhaps they should have access to the
buffer pool? I don't really like the idea, but perhaps it can be kept
clean... (Think "variable delay" - the buffer size must cover the
maximum delay. That can be a lot of RAM.)

> and whenever the engine
> broadcasts a buffer size change event (both hugely expensive events
> any way you measure them).

That depends entirely on the engine with the new little idea. The
plug-ins just do as they're told, just as before, with the one
exception that you have to be smart about "new buffer" events if
you're about to ignore the timestamps. But you shouldn't really do
that anyway...

> it additively writes to its output
> buffer(s). the input buffer(s) and output buffer(s) are shared across
> all plugins and are "owned" by an (audio...) input thread/client and
> an (audio ...) output thread/client. we're done. where does all this
> need for careful buffer allocation come into play ?

Well, it doesn't, unless true variable buffer size is needed. :-)

Strings and that kind of things is still a problem, though...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Oct 20 01:23:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA25998
	for <slinkp@ulster.net>; Tue, 19 Oct 1999 00:52:32 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA14182 for linux-audio-dev-list; Tue, 19 Oct 1999 00:26:42 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA14179 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 19 Oct 1999 00:26:39 -0400
Received: from someip.ppp.op.net (d-bm2-1a.ppp.op.net [209.152.194.58]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id AAA24692 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 19 Oct 1999 00:21:22 -0400 (EDT)
Message-Id: <199910190421.AAA24692@renoir.op.net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] MuCoS: New "radical" changes! 
In-reply-to: Your message of "Tue, 19 Oct 1999 04:57:05 +0200."
             <99101905523604.00441@localhost.localdomain> 
Date: Tue, 19 Oct 1999 01:18:02 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d14c0a0fb224364e472d3c4f3aeda9f7

>1) Have a "new buffer for channel X starts now" event, and
>   just handle it as usual in process(). (Possibly, the
>   event can handle multiple channels - a performance hack
>   for the average case.)
>
>2) Make the engine insert those events when needed - in the
>   normal case; first in the event input buffer.
>
>3) Have fun!

what makes you think I wouldn't like this ? i love it! although i
don't quite see how it can work. what does the event mean ? 

also, i still don't see any need for a particularly fancy scheme for
handling buffer allocation. its so rare, and they are so long-lived
and so intimately connected with the construction of the processing
net that all of your usual RT-concerns don't seem to apply here.

my vision of this: a buffer gets one or more input buffers which it
can't touch (const unsigned char * const :). if it needs any internal
buffers, they are allocated at init time, and whenever the engine
broadcasts a buffer size change event (both hugely expensive events
any way you measure them). it additively writes to its output
buffer(s). the input buffer(s) and output buffer(s) are shared across
all plugins and are "owned" by an (audio...) input thread/client and
an (audio ...) output thread/client. we're done. where does all this
need for careful buffer allocation come into play ?

--p

From - Wed Oct 20 01:24:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA30060
	for <slinkp@ulster.net>; Tue, 19 Oct 1999 01:54:22 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id BAA18176 for linux-audio-dev-list; Tue, 19 Oct 1999 01:25:34 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA18173 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 19 Oct 1999 01:25:31 -0400
Received: from someip.ppp.op.net (d-bm2-1a.ppp.op.net [209.152.194.58]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id BAA28950 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 19 Oct 1999 01:20:13 -0400 (EDT)
Message-Id: <199910190520.BAA28950@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] back to the API 
In-reply-to: Your message of "Tue, 19 Oct 1999 05:53:33 +0200."
             <99101906594205.00441@localhost.localdomain> 
Date: Tue, 19 Oct 1999 02:16:54 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 01528f3ea06191212606a5eaa8bea53b

>> i see it oppositely: the API has to define what gets passed to various
>> plugin function calls. By making it the plugin itself, the API becomes
>> completely amenable to source-code compatible alteration. If you
>> specify anything else, any time you want to change the argument type
>> or number, everything needs to be recoded, not just recompiled.
>
>How does it make a difference WRT binary level compatibility whether
>the API specifies what the events should look like, or what a struct
>should look like?

no difference to *binary* compatibility - if you change the size of
anything, or the arguments to anything, you have to recompile
anyway. but if plugin functions only get a pointer to a plugin struct,
you can always extend that struct at any time, and not have to change
any plugin code when the recompile is done.

an API *has* to include some struct definitions. event and plugin seem
like the two most likely. a plugin has to be able to inspect events
(OK, so you can wrap a void * in macros, but this seems silly), and it
might want to modify itself. Or do you really want macros for all this ?

>> either way, i figure there should be two OOB mechanisms for events
>> requiring more space than fits into the union: one would use a void *
>> member of the union, and would point to space managed entirely by the
>> plugin (via some allocation/deallocation API that we provide).
>
>Major problem; this still has to be implemented. And it has to work
>without shared memory...

in what sense ? do you mean without thread-shared memory, without
shmem-like memory, or without shared memory period ? if its without
shared memory period, then i cannot see how the client or plugin API
can possibly function. if you're worried about an in-kernel
implementation, you just mmap some space from/to the kernel. its
easier to map it into the kernel, i think.

>> note that events take essentially 3 arguments:
>> 
>>      - what changed (ev_target_id) - this may refer (from a plugin's
>>                point of view) to some C parameter in memory, or it
>> 	       may not - the engine doesn't care
>>      - how it changed (delta from old value, absolute new value,
>> 	       increment or decrement from old value)
>
>Uhm, this seems to be asking for trouble with automation and editing
>of automation data... Why deltas and inc/dec? What are plugins
>allowed to send?

they send events that say:

     "XXX has changed by +4"
     "YYY has changed, new value is 13.4554"
     "ZZZ has been incremented"

in each case, XXX, YYY or ZZZ is the target_id of the change, which is
assigned by the engine when the plugin declares its "parameters", and
is looked up by the plugin during event processing to decide if it
really cares.

its really just an editlist, suprise, suprise!

>>      - value (interpreted based on the kind of change)

>Whether this is enough depends on what the event system will be used
>for - and IMO, the design we're working on has too much potential to
>be restricted to audio for the simple reason that you can't send more
>than 32 bytes (or whatever) as a single event without extra trouble
>and overhead. I believe things like a 3D sound FX system for games or
>movie sound track editing would benefit from larger events... Should
>we extend the "standard" when such needs become important?

can you give an example of an event from those worlds which needs more
space ?

>> can't happen. events appear at an event source. only one "object" has
>> access to the event source. the event can go to many event
>> destinations but thats different: these are just LISP-like lists of
>> pointers to events. the object that owns the event source posts events
>> to it in the order received, so that when the engine inspects all
>> active event sources, it finds them already sorted in time order on
>> any given event source. its job is to build the event cell lists for
>> each destination, which requires mux-ing each relevant source and
>> sorting by timeorder while so doing. thats all.
>
>So, you have to force every event source to use a unique kind of
>event? Ok, it's rather silly to connect two sources of the same kind
>of events to the same input - it should probably just not be allowed.

nope. two objects can generate the same kind of event. they would end
up in two distinct event sources, and be merged by the engine into a
single event list for presentation at a destination.

>Good point, but that's not exactly what I meant. How could you
>possibly give the engine anything but a void * to you closure, if
>it's not 100% defined in the API, or 100% private to the plugin?
>Further, how do you optimize engines without breaking plugin binary
>compatibility, if you have "private" implementation stuff in the API?

you define a plugin struct :

    struct plugin {
	   ... stuff the engine cares about ...
    };

then in the plugin code, in the
"run-me-when-instantiating-an-instance" function, you do this:

    struct my_kind_of_plugin {
	   struct plugin std;
	   ... stuff this plugin cares about ...
    };

then just allocate a "my_kind_of_plugin", set up the fields that the
engine needs to see, and send it up to the engine as a "struct
plugin".

yes, yes, this is entirely going back on my comments about header
structs, but this is one case where it seems right.

oops, my daughter is awake. see you tomorrow.

--p

From - Wed Oct 20 01:24:22 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA16033
	for <slinkp@ulster.net>; Tue, 19 Oct 1999 17:49:01 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA20019 for linux-audio-dev-list; Tue, 19 Oct 1999 17:16:26 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA20016 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 19 Oct 1999 17:16:22 -0400
Received: from localhost.localdomain (d212-151-106-44.swipnet.se [212.151.106.44]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id XAA22831; 
          Tue, 19 Oct 1999 23:10:56 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] back to the API
Date: Tue, 19 Oct 1999 21:57:17 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910190520.BAA28950@renoir.op.net>
In-Reply-To: <199910190520.BAA28950@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99101923180800.00468@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id XAA22831
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id RAA16033
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0585d8acb0dea843d01479fb0f144d2a

On Tue, 19 Oct 1999, Paul Barton-Davis wrote:
> an API *has* to include some struct definitions. event and plugin seem
> like the two most likely. a plugin has to be able to inspect events

Yes, and it will do so by explicit code, or macros. The structures
should be carefully designed so that you can safely drop the API
macros if you don't like them, and still sleep well at nights - the
part of the structures that you see in the API will be there in
future implementations. (So, we'd better make damn sure not to get
uggly cludges in here; we'll have to live with it for ages if this
project succeeds.)

> (OK, so you can wrap a void * in macros, but this seems silly), and it
> might want to modify itself. Or do you really want macros for all this ?

No, only where it makes things easier to read, and less bug prone.
*Binary* compatibility is a requirement, so wrapping things just for
the sake of abstraction is quite pointless.

As for "private" structs, this is one way to do it:

-----8<--------------------
struct public_stuff_t {
	.
	.
	.
};
-------------------->8-----
struct private_instance_t {
	struct public_stuff_t	public_stuff;
	.
	.
	.
};
-----8<--------------------

Instantiate in a function on the private side. Only one typecast is
needed, and that can be done with an inline function for compile time
type checking.

> >> either way, i figure there should be two OOB mechanisms for events
> >> requiring more space than fits into the union: one would use a void *
> >> member of the union, and would point to space managed entirely by the
> >> plugin (via some allocation/deallocation API that we provide).
> >
> >Major problem; this still has to be implemented. And it has to work
> >without shared memory...
> 
> in what sense ? do you mean without thread-shared memory, without
> shmem-like memory, or without shared memory period ?

"Accross networks" would explain it, I think. That is, situations
where *all* data has to be copied to get accross to the reciever.

> if its without
> shared memory period, then i cannot see how the client or plugin API
> can possibly function.

Why? As long as _every part of the protocol_ is defined in the API
spec, there's no real problem - a gateway/proxy would know how to find
the data to copy. My point is just, "Don't make that inherently
impossible or inefficient by design."

> if you're worried about an in-kernel
> implementation, you just mmap some space from/to the kernel. its
> easier to map it into the kernel, i think.

Yes, in there, many things get simpler and faster, although a lot
more dangerous... No bugs allowed. Anyway; not an implementation
problem.

> >> note that events take essentially 3 arguments:
> >> 
> >>      - what changed (ev_target_id) - this may refer (from a plugin's
> >>                point of view) to some C parameter in memory, or it
> >> 	       may not - the engine doesn't care
> >>      - how it changed (delta from old value, absolute new value,
> >> 	       increment or decrement from old value)
> >
> >Uhm, this seems to be asking for trouble with automation and editing
> >of automation data... Why deltas and inc/dec? What are plugins
> >allowed to send?
> 
> they send events that say:
> 
>      "XXX has changed by +4"
>      "YYY has changed, new value is 13.4554"
>      "ZZZ has been incremented"
> 
> in each case, XXX, YYY or ZZZ is the target_id of the change, which is
> assigned by the engine when the plugin declares its "parameters", and
> is looked up by the plugin during event processing to decide if it
> really cares.

Well, I believe plug-in code should be as simple as possible, so I
don't see why alternative ways of changing parameters makes sense...

> its really just an editlist, suprise, suprise!

An editlist belongs in the application, and shouldn't be decoded by
the plug-ins, IMO. That's unnecessary code duplication.

> >>      - value (interpreted based on the kind of change)
> 
> >Whether this is enough depends on what the event system will be used
> >for - and IMO, the design we're working on has too much potential to
> >be restricted to audio for the simple reason that you can't send more
> >than 32 bytes (or whatever) as a single event without extra trouble
> >and overhead. I believe things like a 3D sound FX system for games or
> >movie sound track editing would benefit from larger events... Should
> >we extend the "standard" when such needs become important?
> 
> can you give an example of an event from those worlds which needs more
> space ?

Well, to trigger a sound effect in a 3D sound system, you need at
least:

	int	soundfx_id;
	float	pitch;
	float	volume;
	float	xpos,ypos,zpos;
	float	xspeed,yspeed,zspeed;

However, since we have timestamps, this could be split into multiple
events (which has other advantages), but I think using a channel or
object system would be a *very* good idea in that case. It is needed
for a system of thi kind anyway.

However, we still have strings, and possibly arrays. One solution
would be to define a standard for array access, and then just fill in
the data using as many events as you need.

Bonuses:
	Random access.
	Structure.
	Fixed size events.

Problems:
	More complexity in plug-in code.
	Overhead.
	Sync.

The complexity could be hidden in some "nice" inline func or macro.
The sync problem can be solved by using a transaction terminator
event, or by using the first event as a header.

Sync is not a problem with true real time events within a single
thread - but is *is* for out-of-band events, as all events of a
transaction may not arrive in time... What should the plug-in do
about an unfinished transaction? If it's in the middle of throwing
data into it's internal variables, we're screwed; the plug-in can't
process!

Handle the sync problem in the interface between threads? If it can
be done nicely, and there are no more nasty surprises, fixed size
events may be the way to go, after all. It *is* indeed simple and
efficient in the average case, and that's a very strog argument _for_
going that way.

> >So, you have to force every event source to use a unique kind of
> >event? Ok, it's rather silly to connect two sources of the same kind
> >of events to the same input - it should probably just not be allowed.
> 
> nope. two objects can generate the same kind of event. they would end
> up in two distinct event sources, and be merged by the engine into a
> single event list for presentation at a destination.

Well, as long as it's defined in the spec that all events with the
same timestamp from one source are kept together, it's safe. (IIRC,
this one started out with "is it safe to split events?")

> >Good point, but that's not exactly what I meant. How could you
> >possibly give the engine anything but a void * to you closure, if
> >it's not 100% defined in the API, or 100% private to the plugin?
> >Further, how do you optimize engines without breaking plugin binary
> >compatibility, if you have "private" implementation stuff in the API?
> 
> you define a plugin struct :
> 
>     struct plugin {
> 	   ... stuff the engine cares about ...
>     };
> 
> then in the plugin code, in the
> "run-me-when-instantiating-an-instance" function, you do this:
> 
>     struct my_kind_of_plugin {
> 	   struct plugin std;
> 	   ... stuff this plugin cares about ...
>     };
> 
> then just allocate a "my_kind_of_plugin", set up the fields that the
> engine needs to see, and send it up to the engine as a "struct
> plugin".

*hehe* I guess I should have read the whole post first... :-)

> yes, yes, this is entirely going back on my comments about header
> structs, but this is one case where it seems right.

Agreed. And no unsexy macros needed; this is a low level, hardcare,
high performance API, so there's not much we want to hide anyway. If
the engine needs some private stuff as well, this can be taken one
more step (but that's pushing it...):

In the engine:
	struct private_plugin_ext {
		.
		.
		.
	};

	struct private_plugin {
		struct private_plugin_ext ext;
		struct plugin std;
	};

	struct plugin *eng_create_plugin(int size)
	{
		struct private_plugin *p;
		p = malloc( sizeof(struct plugin) +
				sizeof(struct private_plugin_ext)
			);
		return &(p->std);
	}

In the plug-in init code:
	my_plugin_instance = eng_create_plugin	(
				sizeof(struct my_kind_of_plugin)
						);

...or something... *urgh* I don't like it, but at least it's
possible, if it's really needed. (BTW, is it compiler alignment safe
the way I've done it above? One not very nice problem that may occur
with this kind of code..)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Oct 20 01:24:27 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA14655
	for <slinkp@ulster.net>; Tue, 19 Oct 1999 21:00:29 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA20344 for linux-audio-dev-list; Tue, 19 Oct 1999 20:40:17 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA20341 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 19 Oct 1999 20:40:13 -0400
Received: from localhost.localdomain (IDENT:root@[194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id CAA30914;
	Wed, 20 Oct 1999 02:34:33 +0200
Received: from localhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with SMTP id AAA00623;
	Wed, 20 Oct 1999 00:14:23 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] using ext2fs "holes" in files
Date: Tue, 19 Oct 1999 23:50:56 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910181805.OAA27588@renoir.op.net>
In-Reply-To: <199910181805.OAA27588@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99102000142200.00570@localhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 252701263fe1206d45e7f284ab030dfe

On Mon, 18 Oct 1999, Paul Barton-Davis wrote:

[ ... filesystem holes discussion ... ]

> furthermore, i don't rely in any way on whether or not "holes" are
> supported. all i do is to lseek to the right offset in a file and
> write there: i don't care whether the fs zero fills real disk blocks,
> uses holes or whatever. All I care about is that POSIX says that
> whenever i read back the file, I will read zeros in from any offsets
> that I skipped without having previously written them.
> 
> it just so happens that ext2fs (and some of its predecessor file
> systems) were designed to allow files with "holes" as an efficient use
> of disk space, but thats just an implementation detail that adds an
> additional, but not central argument in favor of doing this.
> 

Agreed,
the POSIX semantics say that we can seek beyond the EOF, therefore
why should we not use this nice feature ?

I remember several years ago, when I was at the college, and we played with
286 boxes running DOS and GWBasic,
our CS professor gave us a problem to solve (on paper only , basic code was
required) which involved such a "holes" problem. 

Of course, since I knew that DOS provides these seek semantics ,
I implemented the algorithm in a smart way, and I risked a bad mark for this
exam.
The teacher said my code is totally wrong and I have to write zeroes
to the file.
He didn't believe me until I showed him the truth, by running my code on a
real box. He was very perplexed about the fact
*HEHE*
:-)

Benno.

From - Wed Oct 20 01:24:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA14662
	for <slinkp@ulster.net>; Tue, 19 Oct 1999 21:00:32 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA20339 for linux-audio-dev-list; Tue, 19 Oct 1999 20:40:12 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA20336 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 19 Oct 1999 20:40:08 -0400
Received: from localhost.localdomain (IDENT:root@[194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id CAA30911
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 20 Oct 1999 02:34:29 +0200
Received: from localhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with SMTP id CAA00686
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 20 Oct 1999 02:31:23 +0200
From: Benno Senoner <sbenno@gardena.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] variable samplerate plugins, streaming etc. Was: back to the API
Date: Wed, 20 Oct 1999 01:34:05 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910180157.VAA23224@renoir.op.net> <99101902051700.00441@localhost.localdomain>
In-Reply-To: <99101902051700.00441@localhost.localdomain>
MIME-Version: 1.0
Message-Id: <99102002312301.00570@localhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 9713fee36a94e3d4f267b5bd9f5ab20f

I was a bit busy the last 3 weeks, but
I followed the API discussion.

One of the important things is the vaiable samplerate issue:

I thought about this some time ago, when I was experimenting
with sample interpolation.
In the case of streaming buffers with variable samplerate,
you have to deal with odd buffer sizes which might continuously change.
For example in the case of quadratic interpolation we have to look ahead 
at least 2 samples.
But what if the user wants to resample the data at 10times the original pitch ?
That means in the worst case we have to look ahead 10+2 = 12 samples
in order to be able to perform the interpolation.
If we assume that we use a 3rd order cubic spline interpolator, maybe combined
with a high -order lowpass filter (to eliminate/reduce aliasing when playing at
high pitches), and suppose that there is a user which wildly drives on his MIDI
keyboard's pitch wheel,  then you will quickly realize that
streamed variable samplerate / interpolation, is not a trivial task anymore.
(Opposed to doing linear interpolation on a continuous array of samples).


I'm actually following a DSP course at our university, and maybe I could
design/implement such an interpolator as mini-thesis for the exam. 
The goal would be to have an interpolator which works well in a RT enviroment,
and tries to maximize audio quality.
(Of course if you need a very high number of voices, you have to use a less
expensive method).

I think the variable sample-rate proposal of David will save us a lot of
troubles later.
For example changing the resampler with a pitch shifter would be very useful.
If you have enough CPU power just use a very high quality pitch shifter instead
of the resampler, for your sample playback engine.
( in our case the resampler reads the source sample at variable rate,
depending on the actual pitch, while pitch shifter has a constant input data
rate).
 
As for the data streamer daemon, there is no problem to implement variable
sample-rate support:
just tell the daemon to periodically check how many samples are left in each
channel buffer, and sort this data.
Refill the most empty channel first.
Using this approach, the streamer daemon, automatically gives bigger priority
to channels which are played at higher pitches, (or higher samplerates).
Of course this works as long as you don't overload the disk.
( ie playing track1 at 200x speed would not work since it would generate a disk
load of 30MB/sec ( 150x200). )

Using one streaming thread per disk would work best, since you can minimize
seeking overhead (by using large buffers).
The only thing which still worries me is user interaction:
If an external program does medium disk I/O on the audio disk, then we will
miss deadlines, since we don't have a guaranteed rate I/O subsystem.
Perhaps some people will come up with a solution in not too distant future.
I'm very curious if BeOS is able to handle this.
( run a harddisk recorder , and in background a large file copy which tries
to disturb the hd recorder). 

PS: Paul , 32 bytes max event size seems to little to mee too.

Just assume I have a custom made 3d speaker system consisting of 16 speakers,
where I can control the volume , and 4 eq bands for each speaker.
I want at least float precision:
16 * (1+4) * sizeof(float) = 320 bytes

I want to send a quite dense stream of 3d events to simulate accurate movements
of objects in the 3d audio space.
Of course I want to send the status of the whole 3d configuration in one event
without messing event splitting etc.

If we can, we sould avoid the MAX_EVENT_SIZE value,
or at least keep this on acceptable values.

comments ?

regards,
Benno.

From - Wed Oct 20 01:24:34 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA29145
	for <slinkp@ulster.net>; Tue, 19 Oct 1999 22:27:15 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA20426 for linux-audio-dev-list; Tue, 19 Oct 1999 21:55:01 -0400
Received: from mb06.swip.net (mb06.swip.net [193.12.122.210]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA20423 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 19 Oct 1999 21:54:58 -0400
Received: from localhost.localdomain (d212-151-59-80.swipnet.se [212.151.59.80]) 
          by mb06.swip.net (8.8.8/8.8.8) with SMTP 
          id DAA11858; 
          Wed, 20 Oct 1999 03:49:33 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Benno Senoner <sbenno@gardena.net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] variable samplerate plugins, streaming etc. Was: back to the API
Date: Wed, 20 Oct 1999 03:26:37 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910180157.VAA23224@renoir.op.net> <99101902051700.00441@localhost.localdomain> <99102002312301.00570@localhost.localdomain>
In-Reply-To: <99102002312301.00570@localhost.localdomain>
MIME-Version: 1.0
Message-Id: <99102003564601.00468@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb06.swip.net id DAA11858
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id WAA29145
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 45d1b91c81df9c627efce2565acc3d8b

On Wed, 20 Oct 1999, Benno Senoner wrote:
> I was a bit busy the last 3 weeks, but
> I followed the API discussion.
> 
> One of the important things is the vaiable samplerate issue:
> 
> I thought about this some time ago, when I was experimenting
> with sample interpolation.
> In the case of streaming buffers with variable samplerate,
> you have to deal with odd buffer sizes which might continuously change.
> For example in the case of quadratic interpolation we have to look ahead 
> at least 2 samples.
> But what if the user wants to resample the data at 10times the original pitch ?
> That means in the worst case we have to look ahead 10+2 = 12 samples
> in order to be able to perform the interpolation.
> If we assume that we use a 3rd order cubic spline interpolator, maybe combined
> with a high -order lowpass filter (to eliminate/reduce aliasing when playing at
> high pitches), and suppose that there is a user which wildly drives on his MIDI
> keyboard's pitch wheel,  then you will quickly realize that
> streamed variable samplerate / interpolation, is not a trivial task anymore.
> (Opposed to doing linear interpolation on a continuous array of samples).

True. I wouldn't recommend using it for this purpose. I meant to
support it as a framework far communication between the streamer and
the interpolator, so that both (or at least one) can be plugins
without working around the API.

> I'm actually following a DSP course at our university, and maybe I could
> design/implement such an interpolator as mini-thesis for the exam. 
> The goal would be to have an interpolator which works well in a RT enviroment,
> and tries to maximize audio quality.
> (Of course if you need a very high number of voices, you have to use a less
> expensive method).

Or a faster CPU, or two. :-)
Plug in some quad G4 466 boards? *drewl* (Uhm, sorry... :-)

> I think the variable sample-rate proposal of David will save us a lot of
> troubles later.

That was the idea. It can do some other neat tricks as well, and the
plugin doesn't have to know much about it. There will be some "fun"
stuff around the lookahead handling, though. It'll have to be done as
with the "old" system, but (still) for each buffer. Oh, the engine
can still use circular buffers or whatever - the plugin just wants to
know where the data is, just as before.

> For example changing the resampler with a pitch shifter would be very useful.
> If you have enough CPU power just use a very high quality pitch shifter instead
> of the resampler, for your sample playback engine.
> ( in our case the resampler reads the source sample at variable rate,
> depending on the actual pitch, while pitch shifter has a constant input data
> rate).

There are some synths that do this... Not exactly in the "affordable"
price class, IIRC. Would be very cool, handy and useful.

> As for the data streamer daemon, there is no problem to implement variable
> sample-rate support:
> just tell the daemon to periodically check how many samples are left in each
> channel buffer, and sort this data.
> Refill the most empty channel first.
> Using this approach, the streamer daemon, automatically gives bigger priority
> to channels which are played at higher pitches, (or higher samplerates).
> Of course this works as long as you don't overload the disk.
> ( ie playing track1 at 200x speed would not work since it would generate a disk
> load of 30MB/sec ( 150x200). )
> 
> Using one streaming thread per disk would work best, since you can minimize
> seeking overhead (by using large buffers).
> The only thing which still worries me is user interaction:
> If an external program does medium disk I/O on the audio disk, then we will
> miss deadlines, since we don't have a guaranteed rate I/O subsystem.
> Perhaps some people will come up with a solution in not too distant future.
> I'm very curious if BeOS is able to handle this.
> ( run a harddisk recorder , and in background a large file copy which tries
> to disturb the hd recorder). 
> 
> PS: Paul , 32 bytes max event size seems to little to mee too.
> 
> Just assume I have a custom made 3d speaker system consisting of 16 speakers,
> where I can control the volume , and 4 eq bands for each speaker.
> I want at least float precision:
> 16 * (1+4) * sizeof(float) = 320 bytes

I don't know if this is the right approach, really... As we have
timestamps, it's safe to send the data as individual events, _at
least they are true real time, and timestamped_. There *is* a problem
with out-of-band events, but those shouldn't really be used for this
anyway.

For performance reasons, however, array events and other
optimizations are still interesting.

> I want to send a quite dense stream of 3d events to simulate accurate movements
> of objects in the 3d audio space.
> Of course I want to send the status of the whole 3d configuration in one event
> without messing event splitting etc.

Problem: What if you only want to change a few parameters? Indexing
the sound sources like synth voices seems sensible to me, and makes
it possible to control each sound source dynamically.

However, what about video and other nasty things? If we are to use
fixed size events, we'd better make sure we don't hit the wall as
soon as people start using the API...

> If we can, we sould avoid the MAX_EVENT_SIZE value,
> or at least keep this on acceptable values.

Not really possible, but what about 1024 bytes or so? Ok, I wouldn't
recommend pumping that kind of events through the system at high
rates, but you can use them if you have to.

BTW, even with fixed size event structs, it should be possible to
tell the exact size of events, so that gateways or proxys don't have
to copy the full struct all the time.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Thu Oct 21 01:31:42 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA17003
	for <slinkp@ulster.net>; Wed, 20 Oct 1999 09:11:36 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA25160 for linux-audio-dev-list; Wed, 20 Oct 1999 08:40:40 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA25157 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 20 Oct 1999 08:40:37 -0400
Received: from op.net (d-bm2-02.ppp.op.net [209.152.194.34]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id IAA17743 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 20 Oct 1999 08:35:13 -0400 (EDT)
Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id BAA22774; Wed, 20 Oct 1999 01:47:04 -0400
Date: Wed, 20 Oct 1999 01:47:04 -0400
Message-Id: <199910200547.BAA22774@op.net>
From: Paul Barton-Davis <pbd@Op.Net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] heads down, no talking
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 9ca7488a2d244f71ae981a0950ba34cd

i think that several people (myself included) may feel that the S/N
ratio on the API discussion between David and myself has gotten too
low. Its not that we're not talking about important stuff. Instead,
we're not talking about something for which there is any coherent high
level plan, Gunter's efforts nothwithstanding.

i'm going to bow out of any API discussions for the time being, and
instead of discussing it plan to actually implement a system similar
to the one described. although the details of the event system may
need to be thrown away, much of the code (dlopen() etc.) will probably
be pretty close to what any API would use.

--p

From - Thu Oct 21 01:31:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA01554
	for <slinkp@ulster.net>; Wed, 20 Oct 1999 06:29:35 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA24931 for linux-audio-dev-list; Wed, 20 Oct 1999 05:50:28 -0400
Received: from p-biset.issy.cnet.fr (p-biset.issy.cnet.fr [139.100.0.33]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id FAA24928 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 20 Oct 1999 05:50:25 -0400
Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0)
	id <4Q2TLCLW>; Wed, 20 Oct 1999 11:44:20 +0200
Message-ID: <F09BA6AD2FB2D211BFAC00805F312C89B58650@p-heron.issy.cnet.fr>
From: MOULET Xavier CNET/DMR/ISS <xavier.moulet@cnet.francetelecom.fr>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Newbie
Date: Wed, 20 Oct 1999 11:44:19 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: d4a591a46d427a44dfe177bbffa7b102

Hi David & all,

I used to want to write a complete audio linux thing and when it came down
to the architecture of the audio core, it all boiled down to the same
conclusions as you did .. then i checked your mailing list and your
excellent and great project. Wow. I'm impressed.

As a matter of fact, koobase is now Brahms (for the links of the web page)

I just joined the list and am impressed of the level of the discussion.
I think great things are gonna happen here.

May I ask a few question ? Maybe the thing I will write have already been
discussed, maybe it would be worth reading.I take the chance. Sorry for any
inconvenience/dumb question.

1) Is there a draft of the API/architecture ... Is there a FAQ ?

 (Following to be read if answer to 1 is No/No ;^) )

2) I understood it would be only a CORE engine, a la (esd (which actually is
a mixer), the aRts core, or more accurately Be Media ? (I checked the Be
BOOK, here are excellent ideas to get inspired by ...). Just a thing ..
would it be coded in C ? C++ ? COBOL ?

3) Do you really intend to rewrite ALL the ALSA drivers ? isn't it a too
hard task ?

4) I think it would be a good thing to have a unique type Id for the streams
with subtypes ? To be extremely generic, why not think about a tree /
attributes scheme (in a string).
(eg. : /audio/timedomain/?depth=16&voices=2&Fs=44100 or
/video/mpeg4/?dummy=1&i_dunno_anything_about_mpeg4=5 for a MPEG4 video
stream , MP3 streams would fit into /audio/freqdomain/...)

A node would check about the input type by checking (ie with a regexp-style
constraint string) the strings of the type to be checked . (ex :
/audio/timedomain/AIFF/?depth=[16|8]&voices=* for a driver to match the
audio streams of 16 or 8 bits and any number of voices)

5)  just came in where it was about resampling : I dont't think (cubic or
not) interpolation is a good idea. When it comes to interpolation, when you
use a ploynomial interpolation, you make some nonlinear computation. Thus,
you DISTORT your signal. A better way is to
a) lowpass the signal with Fs (TO-BE Sampling Frequency)
b) downsample the signal

OR 

a) add some ZEROES between the samples to upsample the signal (there you
don't change the spectrum of your signal, then
b) lowpass the signal to cut the frequencies above the OLD sampling
Frequency.

Thus, you have NO LOSS (at all, I MEAN).

There may be ways to make some rational quantification (eg. 4/7) 

Maybe you can have a look at the DSP FAQ which surely explains it better
than I do. Of course it may be _very_ time consuming, but for a final mix,
who cares ?

6) Another Idea that I had is that we need several levels of libraries / API
: 
- Common DSP things (resampling, file loading (AudioFile / Custom ...) ,
fast mixing, FFTs (maybe by using FFTW)
- A "node manager api" (like a window manager)
- Some example/basic plugins (and, first of all and most important, a
DO-NOTHING plugin to make a TEMPLATE of simple plugins)
- and, finally, a connexion with some kind of media players or higher
levels.

7) Do you support (or plan to support) multiple time references (eg
different sound cards --> different clocks)? It can be handled with a
general time reference (64 bit to be _very_ precise, and the fact that every
clock should be able to convert itself to&from thsi ref. clock time, which
wouldn't exist by itself, only in a reference basis between clocks)

8) Of course I would like to help the project, but can you tell me : who is
working on the project ? Do you have a timeline ? when did it start (The
rt-linux thing, not the amiga ?)
I could be a little help in programming, and maybe a better help in DSP (I
passed all my exams of DSP...). My personnal goal is to make a Gnome/GTK+
virtual studio & arranger studio, and i am lloking for an ausio core : I
think I found what i need, and I would participate at this one instead of
building my own.

From - Thu Oct 21 01:31:47 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA21640
	for <slinkp@ulster.net>; Wed, 20 Oct 1999 16:13:06 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA25825 for linux-audio-dev-list; Wed, 20 Oct 1999 15:42:52 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA25821 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 20 Oct 1999 15:42:39 -0400
From: est@hyperreal.org
Received: (qmail 15927 invoked by uid 162); 20 Oct 1999 19:37:15 -0000
Message-ID: <19991020193715.15926.qmail@hyperreal.org>
Subject: [linux-audio-dev] GtkRgb and GtkLevelHold widgets
To: gtk-list@redhat.com, pygtk@daa.com.au,
        linux-audio-dev@ginette.musique.umontreal.ca
Date: Wed, 20 Oct 1999 12:37:15 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 83047697e586b7c84749f0b3dcdb4b67

I've written my first attempt at a full-dress gtk+ widget.  It
encapsulates some gdkrgb functionality on resizable areas.  Widgets
that want to do a lot of multi-color drawing can conveniently derive
from it.  It was motivated largely by the desire to make writing
`scopes' for audio applications easier, so, I also wrote a flexible
level/hold meter widget that uses it.  A Python binding is included
for the meter widget.

Check it out at: http://www.hyperreal.org/~est/gtkrgb/gtkrgb-0.0.1.tar.gz

I'm particularly interested to hear about ways in which my widget
coding is improper. :)

Note that the Python binding when run in demo mode sometimes core
dumps when quitting.  I'd like to figure out why this happens!

Best Regards,

Eric

From - Thu Oct 21 01:31:49 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA12018
	for <slinkp@ulster.net>; Wed, 20 Oct 1999 21:47:49 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA26308 for linux-audio-dev-list; Wed, 20 Oct 1999 21:19:13 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA26304 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 20 Oct 1999 21:19:10 -0400
Received: from localhost.localdomain (d212-151-109-70.swipnet.se [212.151.109.70]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id DAA15487; 
          Thu, 21 Oct 1999 03:13:41 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] heads down, no talking
Date: Thu, 21 Oct 1999 01:20:45 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910200547.BAA22774@op.net>
In-Reply-To: <199910200547.BAA22774@op.net>
MIME-Version: 1.0
Message-Id: <99102101351501.00463@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id DAA15487
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA12018
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c650ed84c9f435c7f9da04ad1f5cf61c

On Wed, 20 Oct 1999, Paul Barton-Davis wrote:
> i think that several people (myself included) may feel that the S/N
> ratio on the API discussion between David and myself has gotten too
> low. Its not that we're not talking about important stuff. Instead,
> we're not talking about something for which there is any coherent high
> level plan, Gunter's efforts nothwithstanding.

I have actually been getting the same feeling lately. There is too
much information and too little structured documetation and *code*
ATM. It's beginning to get hard to keep track of it all without
forgetting some details.

> i'm going to bow out of any API discussions for the time being, and
> instead of discussing it plan to actually implement a system similar
> to the one described. although the details of the event system may
> need to be thrown away, much of the code (dlopen() etc.) will probably
> be pretty close to what any API would use.

I'll take the chance to actually start writing that document, and
implementing some of the things we have discussed. First, I'm going
to investigate the event system; connecting and fixed vs. dynamic
event size. (I have a feeling that the latter can be more efficient
*and* more flexible, and the difference in complexity is starting to
look smaller the more I think about both systems. Let's see if I'm
missing something.)

Let's hack! :-)


//David


PS. Ideas are still welcome, of course! There will just be
significantly less traffic on the list for a while. :-)


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Thu Oct 21 01:31:51 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA12421
	for <slinkp@ulster.net>; Wed, 20 Oct 1999 21:50:26 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA26312 for linux-audio-dev-list; Wed, 20 Oct 1999 21:19:16 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA26309 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 20 Oct 1999 21:19:13 -0400
Received: from localhost.localdomain (d212-151-109-70.swipnet.se [212.151.109.70]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id DAA15497; 
          Thu, 21 Oct 1999 03:13:43 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: MOULET Xavier CNET/DMR/ISS <xavier.moulet@cnet.francetelecom.fr>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Newbie
Date: Thu, 21 Oct 1999 01:36:52 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <F09BA6AD2FB2D211BFAC00805F312C89B58650@p-heron.issy.cnet.fr>
In-Reply-To: <F09BA6AD2FB2D211BFAC00805F312C89B58650@p-heron.issy.cnet.fr>
MIME-Version: 1.0
Message-Id: <99102103205402.00463@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id DAA15497
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA12421
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e5423e02705bb4af510bb60f062105fd

On Wed, 20 Oct 1999, MOULET Xavier CNET/DMR/ISS wrote:
> Hi David & all,
> 
> I used to want to write a complete audio linux thing and when it came down
> to the architecture of the audio core, it all boiled down to the same
> conclusions as you did .. then i checked your mailing list and your
> excellent and great project. Wow. I'm impressed.
> 
> As a matter of fact, koobase is now Brahms (for the links of the web page)
> 
> I just joined the list and am impressed of the level of the discussion.
> I think great things are gonna happen here.
> 
> May I ask a few question ? Maybe the thing I will write have already been
> discussed, maybe it would be worth reading.I take the chance. Sorry for any
> inconvenience/dumb question.
> 
> 1) Is there a draft of the API/architecture ... Is there a FAQ ?

Nope, not yet. I'm going to gather the ideas we have discussed so far
into a document of that kind, and post it for comments and additions,
before I redirect the console input from the mail client to the code
editor for a while.

>  (Following to be read if answer to 1 is No/No ;^) )

Ok, I'll read on, then... :-)

> 2) I understood it would be only a CORE engine, a la (esd (which actually is
> a mixer), the aRts core, or more accurately Be Media ? (I checked the Be
> BOOK, here are excellent ideas to get inspired by ...). Just a thing ..
> would it be coded in C ? C++ ? COBOL ?

First, the point isn't the engine, but rather the *API*. The main
goal is to create a standard API, so that we can get rid of the
current 110% incompatibility problem we have now - converting
plugins from umpteen API's when they could all use the same one.
It'll be binary compatibility.

The API will be C. It's too low level, and not complex enough to
justify C++. The performance requirements are rather extreme, as we
don't want people to avoid the API for being too inefficient, so the
abstraction that C++ so nicely supports cannot be used much anyway.
(Virtual member funcs for example - we won't do function calls *at
all* from within plugins in the average case, not even direct ones!)

(BTW, my Audiality project is kind of asleep, except for some
occasional hacking on the Driver Programming Interface, and of
course, the API discussion.)

> 3) Do you really intend to rewrite ALL the ALSA drivers ? isn't it a too
> hard task ?

Hmm... First of all; we don't really need to. The low latency patch
provides BeOS class performance in normal Linux user space, so engine
implementations can use whatever drivers they like.

However, it's not unlikely that Jaroslav will find some parts of our
API useful, and use them to improve his design further. That could
mean we get hardcore event communication right into the driver
subsystem (ALSA shows up as a client), which would mean sample
accurate sync with multiple sound cards, and other groovy high end
features. Porting ALSA to RTLinux (using my DPI, which will provide a
95% standard kernel compatible API) would make sub sample accurate
lock *without flywheel* possible.

> 4) I think it would be a good thing to have a unique type Id for the streams
> with subtypes ? To be extremely generic, why not think about a tree /
> attributes scheme (in a string).
> (eg. : /audio/timedomain/?depth=16&voices=2&Fs=44100 or
> /video/mpeg4/?dummy=1&i_dunno_anything_about_mpeg4=5 for a MPEG4 video
> stream , MP3 streams would fit into /audio/freqdomain/...)
> 
> A node would check about the input type by checking (ie with a regexp-style
> constraint string) the strings of the type to be checked . (ex :
> /audio/timedomain/AIFF/?depth=[16|8]&voices=* for a driver to match the
> audio streams of 16 or 8 bits and any number of voices)

There will be something like that, yes, but once set up, an actual
stream is nothing but a raw data stream. Somewhat like pipes, but
optimized for real time, high bandwidth streaming. (For example,
there are no read/write functions - the data is carried in buffers,
that may use shared memory to avoid copying. The latest idea is
controlling this using the event system.)

The init protocol seems to be going into the event system, as that
allows most of it to be used in the plugin API as well as the client
API.

> 5)  just came in where it was about resampling : I dont't think (cubic or
> not) interpolation is a good idea. When it comes to interpolation, when you
> use a ploynomial interpolation, you make some nonlinear computation. Thus,
> you DISTORT your signal. A better way is to
> a) lowpass the signal with Fs (TO-BE Sampling Frequency)
> b) downsample the signal
> 
> OR 
> 
> a) add some ZEROES between the samples to upsample the signal (there you
> don't change the spectrum of your signal, then
> b) lowpass the signal to cut the frequencies above the OLD sampling
> Frequency.
> 
> Thus, you have NO LOSS (at all, I MEAN).
> 
> There may be ways to make some rational quantification (eg. 4/7) 
> 
> Maybe you can have a look at the DSP FAQ which surely explains it better
> than I do. Of course it may be _very_ time consuming, but for a final mix,
> who cares ?

We deal mainly with real time, so we need a decent compromise as
well. (Actually, many users may never do off-line processing!)

We have discussed various resampling methods and come to the
conclusion that the only way is to try a few variants, and see which
one is fastest when using high enough accuracy to make it sound good.

> 6) Another Idea that I had is that we need several levels of libraries / API
> : 
> - Common DSP things (resampling,

Plugin.

> file loading (AudioFile / Custom ...) ,

Engine (separate library), or an external client.

> fast mixing, FFTs (maybe by using FFTW)

Plugins.

> - A "node manager api" (like a window manager)

Yes.

> - Some example/basic plugins (and, first of all and most important, a
> DO-NOTHING plugin to make a TEMPLATE of simple plugins)

Well, there's lots of GPLed signal processing code out there. Just
start porting it! :-)

> - and, finally, a connexion with some kind of media players or higher
> levels.

Yep. A client API (similar to Benno's client/server proposal) with
an interface to the same event and stream system that the plugins
use. The idea is to keep these two versions of the API very similar,
so that you can turn plugins into clients and vice versa without too
much effort. It also simplifies integration, as you can easily
implement gateways for connecting things accross engines running
inside separate applications (=clients).

> 7) Do you support (or plan to support) multiple time references (eg
> different sound cards --> different clocks)? It can be handled with a
> general time reference (64 bit to be _very_ precise, and the fact that every
> clock should be able to convert itself to&from thsi ref. clock time, which
> wouldn't exist by itself, only in a reference basis between clocks)

There is one time base in a normal system; the master audio card.
Plugins inside engines will only see the local time, which is
measured in samples (or possibly fractions of samples for plugins
that want that), and relative to one of the external clients the
engine is connected to - in the normal case a sound card, or a
central mixing daemon.

Of course, you may run engines in different threads, synchronized to
different clients, and these will obviously have individual time
references. Whenever they connect to each other, they will have to be
aware of the fact that they may have different time bases.

<implementation>
Right now, I'd suggest using the resync points used for sensor
threads, when timestamping buffers sent to clients we're not synced
to: compare the most recent resync points to get the current offset
between the clients. Keep track of the *change* of the offset over
time to calculate the drift to use for resampling.
</implementation>

> 8) Of course I would like to help the project, but can you tell me : who is
> working on the project ?

Audiality:	Me (if anyone at all)

The API:	The ones who are discussing it on this list.

> Do you have a timeline ?

Well, "alpha spec ASAP", I guess... Anyway, IMO, getting it right is
slightly more important than getting it together and hacking away
ASAP. The alpha spec when it's released should be seen as very
unstable, as we'll probably find problems when people start using it.
Those problems will be *fixed* in a technically acceptable way; not
kept around as "holy legacy stuff" and worked around, as is often done
in the proprietary world.

> when did it start (The
> rt-linux thing, not the amiga ?)

The most interesting part that I've been involved in started with the
discussion on this list (whenever that was). A few weeks before
that, I got in touch with Benno and some other people, shortly after
publishing the Audiality/RTLinux site.

>From the AGC site ( http://www.angelfire.com/ar/agc/progress.html ):

"...the AGC Project is asleep, and probably will be for at least a
few months. (Jun 25, 1999) This is in favor for another project that
is more important to me, and has a better chance of becoming a
successful Free/Open Source project: The Audiality Project."

So, the Audiality/Linux site got up sometime around June 25...
However, that's not really relevant to the API design project. Some
of my ideas have developed over quite a few years, and nothing special
happened before this discussion took off.

> I could be a little help in programming, and maybe a better help in DSP (I
> passed all my exams of DSP...). My personnal goal is to make a Gnome/GTK+
> virtual studio & arranger studio, and i am lloking for an ausio core : I
> think I found what i need, and I would participate at this one instead of
> building my own.

That's exactly what we want with this; people getting involved in
making this *The* standard, rather than adding to the already way
too big pool of incompatible "standards".

So, point out any problems you find - your DSP knowledge may help
here. The new API is supposed to *work* in real life, so if it
doesn't, we just have to fix it somehow. Otherwise we'd be wasting
our time on this project.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Oct 23 16:43:15 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA15955
	for <slinkp@ulster.net>; Thu, 21 Oct 1999 10:18:04 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA01258 for linux-audio-dev-list; Thu, 21 Oct 1999 09:46:33 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA01255 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 21 Oct 1999 09:46:29 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m11eIRm-000dyYC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Thu, 21 Oct 1999 15:40:02 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Thu, 21 Oct 1999 15:40:02 +0200 (CEST)
To: David Olofson <audiality@swipnet.se>
Cc: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] heads down, no talking
In-Reply-To: <99102101351501.00463@localhost.localdomain>
References: <199910200547.BAA22774@op.net>
	<99102101351501.00463@localhost.localdomain>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14351.5872.176593.72236@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id KAA15955
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0b91e72b3e0030027f86b0a8f9bf6281

David Olofson writes:
 > On Wed, 20 Oct 1999, Paul Barton-Davis wrote:
 > > i think that several people (myself included) may feel that the S/N
 > > ratio on the API discussion between David and myself has gotten too
 > > low. Its not that we're not talking about important stuff. Instead,
 > > we're not talking about something for which there is any coherent high
 > > level plan, Gunter's efforts nothwithstanding.
 > 
 > I have actually been getting the same feeling lately. There is too
 > much information and too little structured documetation and *code*
 > ATM. It's beginning to get hard to keep track of it all without
 > forgetting some details.
 > 


 Yes, go for it !

 I guess several developers on the list are awaiting some 
 documentation/implementation of the ideas thrown together, 
 I for my part found it very hard to keep the big picture together,
 so its time someone paints it ...

 Guenter 

From - Sat Oct 23 16:43:29 1999
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id OAA22973
	for <slinkp@ulster.net>; Thu, 21 Oct 1999 14:34:09 -0400
Received: from someip.ppp.op.net (d-bm3-10.ppp.op.net [209.152.194.80]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id OAA13935 for <slinkp@ulster.net>; Thu, 21 Oct 1999 14:30:39 -0400 (EDT)
Message-Id: <199910211830.OAA13935@renoir.op.net>
To: Paul Winkler <slinkp@ulster.net>
Subject: Re: hdr 
In-reply-to: Your message of "Thu, 21 Oct 1999 02:10:15 EDT."
             <380EAE47.C71CC2DC@ulster.net> 
Date: Thu, 21 Oct 1999 15:27:57 -0400
From: Paul Barton-Davis <pbd@Op.Net>
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: d4c39654d9506a7a4c5745d728e62b65

>> so i suspect it should be invisible. i need to think more about
>> this
>> would work on an ADAT, for example.
>
>Well, presumably they have a very good idea of what the latencies
>involved are, and those will never change, so they just build the
>compensation right in.

well, maybe.

i talked to my studio friend, and he said that the ADAT lets you set
up a per-track (one-time) delay.  This is a cool general feature - it
can be for any amount of time - even minutes (quite an accomplishment
given that they really are using streaming media). he pointed out that
in a studio, this work is always done with the ears, and so its quite
possible that even with a manually applied delay, there really is a
millisecond or 10 of out-of-sync-ness between the tracks, but thats OK. he
said that he personally had never had a problem with it, and he's been
using ADAT's for years. the delay can even be used for musical
effects: he's a drummer, and he said that you change the drumming
style by adding 1/10th to 1/4second delay to, say, a snare track
(except for the snare bleeding into the microphones on the other
drums).

so i think i want some kind of logarithmic "jogwheel" to let you
shuffle the start time of a track back and forth. it could default to
a well-intentioned guess about the audio latency inherent in the
app/kernel/soundcard. we could even store the expected latencies in
the little header that accompanies the track files.

but the key idea is that the start times implied by the fact that
something is at sample N in each track file are actually completely
mutable, so you can record them out of sync, and then play them back
in sync.

how does this sound ? wrong ?

--p

From - Sat Oct 23 16:43:30 1999
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id OAA23673
	for <slinkp@ulster.net>; Thu, 21 Oct 1999 14:38:14 -0400
Received: from someip.ppp.op.net (d-bm3-10.ppp.op.net [209.152.194.80]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id OAA14373 for <slinkp@ulster.net>; Thu, 21 Oct 1999 14:34:43 -0400 (EDT)
Message-Id: <199910211834.OAA14373@renoir.op.net>
To: Paul Winkler <slinkp@ulster.net>
Subject: Re: hdr 
In-reply-to: Your message of "Thu, 21 Oct 1999 02:10:15 EDT."
             <380EAE47.C71CC2DC@ulster.net> 
Date: Thu, 21 Oct 1999 15:32:02 -0400
From: Paul Barton-Davis <pbd@Op.Net>
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 251503a3eca260b0e2f0be6d01816e42

hmmm ... this objection:

>Especially since you'd have to do it after each new track is
>recorded, if you don't want the incorrect timing to affect your
>subsequent overdub performances!

still applies to the ADAT-like stuff i just wrote about. jim said
that, yeah, this does happen in the studio, but its part of the
engineers job. if the timing is really bad (i.e. non-technical
reasons), you would re-record that track.

clearly, we want to get software to do as much of the work for us as
it can, so i think that a loopback measurement makes a lot of
sense. this can be done easily without a cable on some soundcards, but
not at all on others. 

From - Sat Oct 23 16:43:31 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA08594
	for <slinkp@ulster.net>; Thu, 21 Oct 1999 16:21:41 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA01882 for linux-audio-dev-list; Thu, 21 Oct 1999 15:43:20 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA01879 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 21 Oct 1999 15:43:17 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46833AbPJUThW>; Thu, 21 Oct 1999 22:37:22 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <99102101351501.00463@localhost.localdomain> (message from David
	Olofson on Thu, 21 Oct 1999 01:20:45 +0200)
Subject: Re: [linux-audio-dev] heads down, no talking
Message-Id: <19991021193730Z46833-563+390@nic.funet.fi>
Date:   Thu, 21 Oct 1999 22:37:22 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 09eddb246836e3c309f5515548b9eccf

>I have actually been getting the same feeling lately. There is too
>much information and too little structured documetation and *code*

I quitted following the discussion weeks ago, and have wondered how
you have succeeded to get code written while posting 100+ mails per
month.  :-|

Yours,

Juhana

From - Sat Oct 23 16:43:54 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA09490
	for <slinkp@ulster.net>; Fri, 22 Oct 1999 14:38:57 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA07705 for linux-audio-dev-list; Fri, 22 Oct 1999 13:56:42 -0400
Received: from iona.abel.net.uk (iona.abel.net.uk [212.1.130.142]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA07702 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 22 Oct 1999 13:56:38 -0400
Message-Id: <199910221756.NAA07702@ginette.musique.umontreal.ca>
Received: (qmail 24218 invoked from network); 22 Oct 1999 17:51:04 -0000
Received: from ppp-1-139.cvx6.telinco.net (HELO default) (212.1.153.139)
  by iona.abel.net.uk with SMTP; 22 Oct 1999 17:51:04 -0000
From: "Paul Kellett" <paul.kellett@maxim.abel.co.uk>
To: <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] potential instrument formats for the linux API ?
Date: Fri, 22 Oct 1999 06:35:41 +0100
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: a282766621a658bd360783421bbdf249

> Are the soundfont specifications free ?

http://www.soundfont.com/sftech.html or www.wotsit.org


> Is it flexible enough to meet our requirements ?

Should be, but seems a bit complicated and carries some old baggage. DLS is
simpler (now) and more flexible (one day) and holds it's samples in WAV
format.


> Any infos about the AKAI sampleformat (good/bad/license problems etc.)

That's where I come in: http://www.abel.co.uk/~maxim/akai/akaiinfo.htm

The S1000 format is ok, but supports a lot of features you wouldn't
necessarily include in a softsynth, and the sample format can be a pain (2
mono files instead of stereo).



Paul.

-- 
paul.kellett@maxim.abel.co.uk
http://www.abel.co.uk/~maxim/



From - Sat Oct 23 16:43:48 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA11339
	for <slinkp@ulster.net>; Fri, 22 Oct 1999 11:24:33 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA07343 for linux-audio-dev-list; Fri, 22 Oct 1999 10:34:12 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA07340 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 22 Oct 1999 10:34:06 -0400
Received: from localhost.localdomain (IDENT:root@[194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id QAA14034;
	Fri, 22 Oct 1999 16:28:17 +0200
Received: from localhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with SMTP id QAA00735;
	Fri, 22 Oct 1999 16:25:11 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Guenter Geiger <geiger@epy.co.at>, David Olofson <audiality@swipnet.se>
Subject: Re: [linux-audio-dev] heads down, no talking , big picture
Date: Fri, 22 Oct 1999 16:11:33 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
References: <199910200547.BAA22774@op.net> <99102101351501.00463@localhost.localdomain> <14351.5872.176593.72236@gige>
In-Reply-To: <14351.5872.176593.72236@gige>
MIME-Version: 1.0
Message-Id: <99102216251102.00679@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by em.gardena.net id QAA14034
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id LAA11339
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3aab1a7f814e2d07c6de16a9431c176c

On Thu, 21 Oct 1999, Guenter Geiger wrote:

> 
>  Yes, go for it !
> 
>  I guess several developers on the list are awaiting some 
>  documentation/implementation of the ideas thrown together, 
>  I for my part found it very hard to keep the big picture together,
>  so its time someone paints it ...
> 
>  Guenter

I agree.
I'd suggest that David and Paul should put toghether the basic event system,
(since they know the "big picture" best)
which should include the handling of basic plugin processing,
event routing to subnets,  handling the event routing to multiple listeners /
receivers etc.
It would be nice to provide a simple working engine, and a sample plugin
implementation.
What we need is to document how the engine does work, maybe in terms of flow
diagrams to better understand the "big picture".

In the mean time I will try to hack toghether my audio client/server model
which we could then integrate in the main engine.

Combine all with a nice /dev/dsp wrapper , et voila' , our alpha multimedia
system (API/engine) is here.
:-)

PS: did we agree on the name (what was the final name) ?  I lost the discussion.
:-)

regards,
Benno.
 

From - Sat Oct 23 16:43:52 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA29656
	for <slinkp@ulster.net>; Fri, 22 Oct 1999 13:19:55 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA07525 for linux-audio-dev-list; Fri, 22 Oct 1999 12:12:28 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA07522 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 22 Oct 1999 12:12:22 -0400
Received: from localhost.localdomain (IDENT:root@[194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id SAA15584
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 22 Oct 1999 18:06:33 +0200
Received: from localhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with SMTP id SAA01432
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 22 Oct 1999 18:07:14 +0200
From: Benno Senoner <sbenno@gardena.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] potential instrument formats for the linux API ?
Date: Fri, 22 Oct 1999 17:57:43 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <99102218071406.00679@localhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 0f8604305876d7b5069a0adcd5d649ab

I was wondering if there are any suitable format to store instruments for our
upcoming linux audio system ?

Are the soundfont specifications free ?
Is it flexible enough to meet our requirements ?
Any infos about the AKAI sampleformat (good/bad/ license problems etc.)

Of course we should again take a modular approach, where you can
add your preferred sample/instrument import module.

The maximum of fun would be to put an AKAI S1000/S2000 CD in your CDROM drive,
load it in your softsynth, and play the instruments as you were on a real AKAI
sample , with correct (or at least good emulated) filter / envelope settings.
:-)

regards,
Benno.

From - Sat Oct 23 16:43:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA15427
	for <slinkp@ulster.net>; Fri, 22 Oct 1999 18:37:51 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA08144 for linux-audio-dev-list; Fri, 22 Oct 1999 17:57:45 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA08141 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 22 Oct 1999 17:57:42 -0400
Received: from localhost.localdomain (d212-151-101-43.swipnet.se [212.151.101.43]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id XAA05135; 
          Fri, 22 Oct 1999 23:52:01 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Benno Senoner <sbenno@gardena.net>, Guenter Geiger <geiger@epy.co.at>
Subject: Re: [linux-audio-dev] heads down, no talking , big picture
Date: Fri, 22 Oct 1999 20:33:21 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
References: <199910200547.BAA22774@op.net> <14351.5872.176593.72236@gige> <99102216251102.00679@localhost.localdomain>
In-Reply-To: <99102216251102.00679@localhost.localdomain>
MIME-Version: 1.0
Message-Id: <99102222472300.00470@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id XAA05135
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA15427
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 06e9bcde4b51a56e9d02d7d7ac86da36

On Fri, 22 Oct 1999, Benno Senoner wrote:
> On Thu, 21 Oct 1999, Guenter Geiger wrote:
> 
> > 
> >  Yes, go for it !
> > 
> >  I guess several developers on the list are awaiting some 
> >  documentation/implementation of the ideas thrown together, 
> >  I for my part found it very hard to keep the big picture together,
> >  so its time someone paints it ...
> > 
> >  Guenter
> 
> I agree.
> I'd suggest that David and Paul should put toghether the basic event system,
> (since they know the "big picture" best)
> which should include the handling of basic plugin processing,
> event routing to subnets,  handling the event routing to multiple listeners /
> receivers etc.

I'll start hacking my implementation tonight, hopefully. (I'm
checking out a 22" monitor, and I need to get a *real* video card
running to see what the monitor can do...)

The plan is to try out the qm_heap for events + a fixed buffer pool
for the streams. I'll probably have only one plugin callback function
for everything, including init, to see what that design actually
looks like in real life.

> It would be nice to provide a simple working engine, and a sample plugin
> implementation.
> What we need is to document how the engine does work, maybe in terms of flow
> diagrams to better understand the "big picture".

I hacked an HTML "framework" yesterday, and I'll start filling in the
details of the system as I deal with each part of my implementation.
The overview and diagrams will probably come in later, but I might
have a "useful" document in a few days.

> PS: did we agree on the name (what was the final name) ?  I lost the discussion.
> :-)

Uhm, don't know... The logo on my doc says "The MuCoS Multimedia
Communication System", until I get a better suggestion. (I could
upload or post a page layout example if you'd like to see the logo and
layout...)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Oct 23 16:44:05 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA25325
	for <slinkp@ulster.net>; Sat, 23 Oct 1999 09:41:32 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA13122 for linux-audio-dev-list; Sat, 23 Oct 1999 08:58:49 -0400
Received: from iona.abel.net.uk (iona.abel.net.uk [212.1.130.142]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id IAA13119 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 23 Oct 1999 08:58:41 -0400
Message-Id: <199910231258.IAA13119@ginette.musique.umontreal.ca>
Received: (qmail 30964 invoked from network); 23 Oct 1999 12:52:59 -0000
Received: from ppp-1-62.cvx5.telinco.net (HELO default) (212.1.149.62)
  by iona.abel.net.uk with SMTP; 23 Oct 1999 12:52:59 -0000
From: "Paul Kellett" <paul.kellett@maxim.abel.co.uk>
To: <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] potential instrument formats for the linux API ?
Date: Sat, 23 Oct 1999 01:47:40 +0100
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 013c62e8af180e82a274ed5b2aeba0f0

See also: http://www.midi.org/sasbf.htm


Paul.

-- 
paul.kellett@maxim.abel.co.uk
http://www.abel.co.uk/~maxim/


From - Sat Oct 23 20:27:50 1999
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id SAA15029
	for <slinkp@ulster.net>; Sat, 23 Oct 1999 18:36:39 -0400
Received: from someip.ppp.op.net (d-bm3-00.ppp.op.net [209.152.194.64]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id SAA21803 for <slinkp@ulster.net>; Sat, 23 Oct 1999 18:32:49 -0400 (EDT)
Message-Id: <199910232232.SAA21803@renoir.op.net>
To: Paul Winkler <slinkp@ulster.net>
Subject: Re: hdr 
In-reply-to: Your message of "Sat, 23 Oct 1999 17:18:53 EDT."
             <3812263D.82A2FD33@ulster.net> 
Date: Sat, 23 Oct 1999 18:33:20 -0400
From: Paul Barton-Davis <pbd@Op.Net>
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 8d8855276ca7781c9432d83d0891e447

>> and so its quite
>> possible that even with a manually applied delay, there really is a
>> millisecond or 10 of out-of-sync-ness between the tracks, but thats OK.
>
>I don't think that can possibly be OK. I've heard about the
>adjustable track-delay, but I alesis _has to_ ship the machines
>calibrated so that unless you adjust this delay, tracks really are
>in sync. If you recorded 2 mics with any amount of bleed between
>them (say, 2 mics on an acoustic guitar) to two tracks that had even
>1 ms of delay between them, you'd get comb-filtering when you mix
>the tracks. 

on the one hand, i agree entirely. but on the other: how would you go
about doing this ? either the tracks from the two mics are recorded at
the same time, in which case, there is no problem (though the mic guys
will go on about inter-mic latency and echo - yes, echo, really!), or
they are not. If they are not recorded at the same time, you're back
to regular musician-induced latencies which will be much larger than
10ms.

>of the ADCs), but I've never heard anyone complain that they cause
>comb filtering between tracks untill you adjust them all by hand.

no, of course not. because they were all recorded at the same time,
*or* they were from different takes in which the most signficant
delays were musician induced and acoustically acceptable. i mean, who
records the same instrument on two tracks on two *different* takes
(and maybe from different mics) without expecting something a little
"interesting" ?

anything recorded in a single take will always be in sync,
obviously. anything recorded in more than one take has likely much
larger latencies and variations than are induced by the soundcard/cpu,
and is extremely unlikely to be composed of two tracks that are
intended to represent an identical 100% in sync sound source. or am i
missing something ? do you have a scenario in mind where this is not
true ?

>Cool.  But I do think there's a case to be made for trying to record
>them in sync, because then you wouldn't have to do anything before
>you started fiddling with the tracks in, say, snd or  mix or
>whatever: the files would already be on disc with the first sample
>of each track corresponding correctly to the first sample of all
>others.

agreed. but i don't think this is actually a well-defined goal. what
is the first sample ? do you want the start of first 20ms of silence
that occurs before the musician realizes that its time to play to
count as "the first sample" ?

--p

From - Mon Oct 25 09:44:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA11254
	for <slinkp@ulster.net>; Sat, 23 Oct 1999 23:23:15 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA14622 for linux-audio-dev-list; Sat, 23 Oct 1999 22:42:45 -0400
Received: from kaybee.org (kaybee.resnet.gatech.edu [128.61.15.250]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA14619 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 23 Oct 1999 22:42:41 -0400
Received: from localhost (rob@localhost)
	by kaybee.org (8.8.7/8.8.7) with ESMTP id WAA07584;
	Sat, 23 Oct 1999 22:36:57 -0400
Date: Sat, 23 Oct 1999 22:36:57 -0400 (EDT)
From: rob <rob@kaybee.org>
To: Benno Senoner <sbenno@gardena.net>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] potential instrument formats for the linux
 API ?
In-Reply-To: <99102218071406.00679@localhost.localdomain>
Message-ID: <Pine.LNX.4.10.9910232224340.7578-100000@kaybee.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: a95b2ec9be4faa3afd4baa0e0ecff952

On Fri, 22 Oct 1999, Benno Senoner wrote:

> The maximum of fun would be to put an AKAI S1000/S2000 CD in your CDROM drive,
> load it in your softsynth, and play the instruments as you were on a real AKAI
> sample , with correct (or at least good emulated) filter / envelope settings.

	i've got a gtk app for crude akai cd -> .wav and a program that
plays akai samples from midi input (t'was on hold while i was waiting for
2.2 rtlinux to become stable).  the reading routines were based on
someones perlscript who reveresed engineered most of the format.  

http://www.async.cx/pics/browseshot.jpg
http://www.async.cx/abrowse-0.0.0.tar.gz

and

http://www.async.cx/projects/sampler/

for the code of the akai sampler player thingy.  the timing sucks since it
was a pre-soft-rt patch in user mode. 

it's messy.  it still compiles on my box, but it might have some bit rot
for newer installs.

			rob

----
Rob Melby
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
Internet: rob@kaybee.org, gt4255a@prism.gatech.edu

From - Mon Oct 25 09:44:11 1999
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id IAA12123
	for <slinkp@ulster.net>; Sun, 24 Oct 1999 08:11:41 -0400
Received: from someip.ppp.op.net (d-bm3-0f.ppp.op.net [209.152.194.79]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id IAA24801 for <slinkp@ulster.net>; Sun, 24 Oct 1999 08:07:46 -0400 (EDT)
Message-Id: <199910241207.IAA24801@renoir.op.net>
To: Paul Winkler <slinkp@ulster.net>
Subject: Re: hdr 
In-reply-to: Your message of "Sat, 23 Oct 1999 20:56:25 EDT."
             <38125939.274E8FFB@ulster.net> 
Date: Sun, 24 Oct 1999 08:08:26 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Status: U
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 700a1673e298a7fc167f79f8a798bffb

>Actually, scratch that: I just thought of a scenario that happens
>all the time: Sending a recorded track out into a piece of outboard
>gear and re-recording the results to a new track (or to a final
>stereo mix in the computer). If you mix the processed track with the
>straight track, you might get undesirable coloration if the timing
>isn't preserved accurately.
>Maybe that's a nit-picky example, but it's forseeable that this be
>an issue for some users of hdr.

not nitpicky - this is an extremely common scenario.

however, its also very very hard to do with arbitrary (digital)
outboard gear. you have no idea what the delays in the outboard piece
might be, so the best you can do is to skew the new track to take into
account the delay in the soundcard+cpu loopback circuit. in all
likelihood, this won't be good enough, however, and you may want to
shuttle the new track by the, oh, 2-7ms delay caused by the outboard
processor (the Event Layla does about 7ms). but this is dependent on
the outboard gear, and might even depend on what you're asking it to do.

OTOH, for outboard analog gear, the effective delay is zero samples (i
still have a hard time getting my head around this fact :), so it
would still be worthwhile eliminating the loopback delay.

>assuming another ideal hypothetical situation:if a musician with
>flawless timing hits a note with a peak that coincides with a peak
>in the monitor output, which peak could be found at, say, sample
>20000 of the pre-recorded tracks, then the new note's peak should
>occur at sample 20000 of the newly recorded track.

agreed. but to do this, we do have to make the assumption that the
musician's head is at the monitor cone (i.e. 0 sample delay between
the DAC and the musician's own tone generator). that's OK, but if
you're going to be really picky, it will still be wrong in many
recording situations.

>Another way to look at it: If you use an analog machine with a
>perfectly aligned record head, and take the monitor signal off the
>record head (which is what they always do), you get perfect
>synchronization, always. 

thats because its an analog signal with effectively zero time delays. 
the equivalent in the digital realm would be to route the recorded
tracks out through the DAC, mix the new track's analog signal into the
result, and feed it back into the ADC. we all know that this is a bad
idea, but this would produce the same result, timing wise.

so, the challenge is to do the same thing without ruining the
recording with multiple D-A-D conversions. and we know how to do that:
measure the loopback delay caused by precisely this kind of setup, and
then build that in. i will try to make sure that i build this in to
HDR at a fairly deep level and provide a nice interface for
manipulating it.

>can sometimes be mind-bogglingly picky about timing; it's very
>reassuring to be able to know that your recording system is not
>altering your performance at all.

you mean the *timing* right ? :) there are no assurances that its not
altering other aspects of your performance - this a recording!

work on hdr has temporarily halted: i am busy "porting" Quasimodo to
use the GNU autoconf/automake/libtool system, with the end result
being 5 standalone libraries plus a small main() function. 4 of the
libraries are used by hdr, so its hardly unrelated. But man, its way
more work than I would have anticipated!

--p

From - Mon Oct 25 09:44:14 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA03278
	for <slinkp@ulster.net>; Sun, 24 Oct 1999 12:17:52 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA19045 for linux-audio-dev-list; Sun, 24 Oct 1999 11:30:44 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA19042 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 24 Oct 1999 11:30:38 -0400
Received: from localhost.localdomain (IDENT:root@[194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id RAA14999;
	Sun, 24 Oct 1999 17:24:26 +0200
Received: from localhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with SMTP id RAA02848;
	Sun, 24 Oct 1999 17:25:12 +0200
From: Benno Senoner <sbenno@gardena.net>
To: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] streaming from disk to terminatorX added (via mmap)
Date: Sun, 24 Oct 1999 17:14:07 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: alkoit00@fht-esslingen.de
MIME-Version: 1.0
Message-Id: <99102417251100.02718@localhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 3ccdf4ef728f6f1b479d635737ca4b82

for those that are interested:

Yesterday I went on terminatorX's (the scratching app)  homepage (
http://termX.cjb.net ), and read in the FAQ that it doesn't support streaming
from disk, because it would require a complete redesign of the app.
But fortunately Alexander was wrong:
:-)
use mmap and it's powerful caching algorithms.

I added from disk streaming because I think that many users
running on low memory boxes could run into big troubles
when scratching large audiofiles.
( The audiofile could not fit into the swaparea, and the
loading of the file could take very long, since it has to be swapped out,
etc.)

the patch is here:

http://www.gardena.net/benno/linux/terminatorX-3.2-mmap.patch


Basically what I changed is:
instead of loading the file into RAM, I mmap() the entire file 
into memory.
Since the kernel loads pages of the file into mem when they
are needed, it could cause audio-dropouts when working with
low audio buffer sizes (low latency) since, the playing thread
might wait too long for the kernel which tries to load the pages
into mem.

One trick to avoid this it to add a low priority thread , which does
basically read-ahead and read-behind, by accessing to pages 
before and past the actual playing position.
It doesn't matter if this thread blocks for a moment, 
since it doesn't play any audio data.
The audio thread will always find the needed pages in memory and
will not drop out.

With this approach I was able to scratch a 100MB mono file,
on a 16MB RAM box, running X , KDE and Netscape (what a pain to load netscape :-) ) !
(using SCHED_FIFO scheduling)

ATTENTION:

sometimes: there might  occur audio dropouts during streaming from disk,but
that is not the fault of the app but, it's a common problem of Linux.

For dropout free low-latency performance apply the low-latency patches
at
http://www.gardena.net/benno/linux/audio

and tune your EIDE as described in the page
( /sbin/hdparm -c 1 -m 8 -u 1 -d 1 /dev/hda  for example)

Linux 2.4 will contain the low-latency patches as default,
and this will be a great benefit for realtime apps like terminator-X.

I hope that scratchers running on low RAM boxes will enjoy the mmap patch !
:-)

BUGS:

- the 44byte WAV header isn't skipped
- mpg123 and sox support doesn't work (would require decompressing
to a temporary file)
- might not work on BIGENDIAN boxes

Suggestions to the author:  (any official word from you Alexander ?)

- always use mmap since it will work well on big RAM boxes too,
and doesn't eat up all you system memory.

-in order to support MP3s and other fileformats decompress/convert this
files first to a temporary WAV file and mmap() this into mem.

To speed up things even more you could save a the sample graph into
a little file the first time you load the audio file, so that on subsequent
loads, the 100MB audio file will "load" almost istantaneously in to mem.
(thanks to mmap() ).

It would be possible to support direct disk streaming of MP3 files,
but that is not a trivial task since you can't access an MP3 in
random order, since the windowing filter depends on the previous
filter state information.
One way could be to store the filterstates of every mpeg frame into 
a separate file and then reload the filter during seeks into the file. 
But that would require to include an entire mp3 player with modified
windowing filter code.

PS: Now if we could get one of these turntables recorded with special
static waves (saw waves), we could add add turntable motion detection
and get the same features as "finalscratch" on BeOS:
scratching an audiofile in realtime using a real turntable.
:-)

regards,

Benno.
sbenno@gardena.net


From - Mon Oct 25 09:44:16 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA14258
	for <slinkp@ulster.net>; Sun, 24 Oct 1999 13:54:52 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA19203 for linux-audio-dev-list; Sun, 24 Oct 1999 13:12:05 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA19200 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 24 Oct 1999 13:12:02 -0400
Received: from someip.ppp.op.net (d-bm3-0f.ppp.op.net [209.152.194.79]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id NAA14710; Sun, 24 Oct 1999 13:06:18 -0400 (EDT)
Message-Id: <199910241706.NAA14710@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: Re: [linux-audio-dev] streaming from disk to terminatorX added (via mmap) 
In-reply-to: Your message of "Sun, 24 Oct 1999 17:14:07 +0200."
             <99102417251100.02718@localhost.localdomain> 
Date: Sun, 24 Oct 1999 13:07:02 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5b0d30a88c744f1d1160fa06997e9e1d

Benno writes:

>Since the kernel loads pages of the file into mem when they are
>needed, it could cause audio-dropouts when working with low audio
>buffer sizes (low latency) since, the playing thread might wait too
>long for the kernel which tries to load the pages into mem.

>One trick to avoid this it to add a low priority thread , which does
>basically read-ahead and read-behind, by accessing to pages before
>and past the actual playing position.  It doesn't matter if this
>thread blocks for a moment, since it doesn't play any audio data.
>The audio thread will always find the needed pages in memory and will
>not drop out.

i know that est@hyperreal.org will have something to say about this :)
well, perhaps not, but he should. oolaboola (sp?) has been evolving
toward some fairly sophisticated memory management to handle this kind
of stuff.

From - Mon Oct 25 09:44:17 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA14271
	for <slinkp@ulster.net>; Sun, 24 Oct 1999 13:54:55 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA19212 for linux-audio-dev-list; Sun, 24 Oct 1999 13:15:22 -0400
Received: from alsa.alsa-project.org (alsa.jcu.cz [160.217.1.49]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA19209 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 24 Oct 1999 13:15:19 -0400
Received: from localhost (andy@localhost)
	by alsa.alsa-project.org (8.8.8/8.8.8) with ESMTP id TAA01405;
	Sun, 24 Oct 1999 19:09:28 +0200
Date: Sun, 24 Oct 1999 19:09:27 +0200 (MEST)
From: Andy Lo A Foe <andy@alsa-project.org>
To: Benno Senoner <sbenno@gardena.net>
cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu,
        alkoit00@fht-esslingen.de
Subject: Re: [linux-audio-dev] streaming from disk to terminatorX added (via
 mmap)
In-Reply-To: <99102417251100.02718@localhost.localdomain>
Message-ID: <Pine.LNX.4.05.9910241907220.297-100000@alsa.alsa-project.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 89fc027cb953993a21d1af0a5f3feed4

On Sun, 24 Oct 1999, Benno Senoner wrote:

> Suggestions to the author:  (any official word from you Alexander ?)
> 
> - always use mmap since it will work well on big RAM boxes too,
> and doesn't eat up all you system memory.
> 
> -in order to support MP3s and other fileformats decompress/convert this
> files first to a temporary WAV file and mmap() this into mem.
> 
> To speed up things even more you could save a the sample graph into
> a little file the first time you load the audio file, so that on subsequent
> loads, the 100MB audio file will "load" almost istantaneously in to mem.
> (thanks to mmap() ).
> 
> It would be possible to support direct disk streaming of MP3 files,
> but that is not a trivial task since you can't access an MP3 in
> random order, since the windowing filter depends on the previous
> filter state information.
> One way could be to store the filterstates of every mpeg frame into 
> a separate file and then reload the filter during seeks into the file. 
> But that would require to include an entire mp3 player with modified
> windowing filter code.
> 
> PS: Now if we could get one of these turntables recorded with special
> static waves (saw waves), we could add add turntable motion detection
> and get the same features as "finalscratch" on BeOS:
> scratching an audiofile in realtime using a real turntable.
> :-)

<shameless plug>

You might want to check out alsaplayer, http://www.alsa-project.org/~andy/
It does 'direct streaming from disk' for just about any format without
using mmap. It uses a ring buffer system and threading to cache data and
there is code for very low latency modes using SCHED_FIFO.
If you really want to emulate "finalscratch" just put the scratching mouse
functionality of terminatorX in some sort of plugin for alsaplayer. It
supports variable speed control (negative too, which is needed for
'scratching'). With a fast enough CDDA capable CDROM you can even
'scratch' your music CDs in realtime :-)

</shameless plug>

Andy
--
AlsaPlayer, http://www.alsa-project.org/~andy/

From - Mon Oct 25 09:44:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA19507
	for <slinkp@ulster.net>; Sun, 24 Oct 1999 14:47:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA19268 for linux-audio-dev-list; Sun, 24 Oct 1999 14:08:35 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA19265 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 24 Oct 1999 14:08:32 -0400
Received: from localhost.localdomain (d212-151-59-100.swipnet.se [212.151.59.100]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id UAA01131; 
          Sun, 24 Oct 1999 20:02:40 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Benno Senoner <sbenno@gardena.net>,
        linux-audio-dev@ginette.musique.umontreal.ca,
        linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: streaming from disk to terminatorX added (via mmap)
Date: Sun, 24 Oct 1999 19:42:18 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: alkoit00@fht-esslingen.de
References: <99102417251100.02718@localhost.localdomain>
In-Reply-To: <99102417251100.02718@localhost.localdomain>
MIME-Version: 1.0
Message-Id: <99102420100100.00454@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id UAA01131
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id OAA19507
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 8e2c31e9d3c0f48d5337ac941143628a

On Sun, 24 Oct 1999, Benno Senoner wrote:
> PS: Now if we could get one of these turntables recorded with special
> static waves (saw waves), we could add add turntable motion detection
> and get the same features as "finalscratch" on BeOS:
> scratching an audiofile in realtime using a real turntable.
> :-)

Uhm, I have just developed a sensor decoding method that could be
useful for this. It's probably overkill, as it's accurate to some 128
bits/period of the input signal with input signals of around that
resolution. It's just that I most probably can't release the
details... :-(

Anyway, I have a clue about how to do it, so I could give some hints
if needed.

And there are other ways than a special LP. For example, a quadrature
decoder; get two reflective optisensors (UV LED + photodiode in a
single package - handy! :-), and use an encoder stripe around the
turntable disk. The encoder strip should look like this:

Sensor 1: ####    ####    ####    ####    ####
Sensor 2:   ####    ####    ####    ####    ####

Note: 90 degree phase diff!

Then run the "sensor 1" signal into the U/_D input of a binary
counter. (Standard chip - use 4xxx chips [CMOS], as they're less
sensitive to Vcc errors. Do *not* use buffered chips as triggers for
reading the sensors - they can start to oscillate and fry!) The
"sensor 2" signal goes to the count input of the chip. The chip is
then hooked up to a parallel port or something, so that you can read
the current value.

Of course, you may also rip out the electronics from a mouse.
(Preferably a PS/2 one, as they have 30-150 Hz update rate, as
opposed to 10-30 for serial mice...) That's two channels and some
buttons + decoder and interface - and there are drivers. :-) Remove
the LEDs and photodiodes/transistors from the mouse PCB, and replace
them with wires to the new detectors.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Mon Oct 25 09:44:22 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA00983
	for <slinkp@ulster.net>; Sun, 24 Oct 1999 17:14:11 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA19428 for linux-audio-dev-list; Sun, 24 Oct 1999 16:38:27 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id QAA19425 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 24 Oct 1999 16:38:24 -0400
From: est@hyperreal.org
Received: (qmail 15024 invoked by uid 162); 24 Oct 1999 20:32:41 -0000
Message-ID: <19991024203241.15023.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] streaming from disk to terminatorX added (via
 mmap)
In-Reply-To: <199910241706.NAA14710@renoir.op.net> from Paul Barton-Davis at
 "Oct 24, 1999 01:07:02 pm"
To: Paul Barton-Davis <pbd@Op.Net>
Date: Sun, 24 Oct 1999 13:32:41 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c01c48b82b2166a5d44ddfc49a039103

Paul Barton-Davis discourseth:
> Benno writes:
> 
> >Since the kernel loads pages of the file into mem when they are
> >needed, it could cause audio-dropouts when working with low audio
> >buffer sizes (low latency) since, the playing thread might wait too
> >long for the kernel which tries to load the pages into mem.
> 
> >One trick to avoid this it to add a low priority thread , which does
> >basically read-ahead and read-behind, by accessing to pages before
> >and past the actual playing position.  It doesn't matter if this
> >thread blocks for a moment, since it doesn't play any audio data.
> >The audio thread will always find the needed pages in memory and will
> >not drop out.
> 
> i know that est@hyperreal.org will have something to say about this :)

Yes, I've been busy vacationing (which I still am :)

I don't see how mmap() can be reliable for this sort of thing.  Even
if you touch pages to bring them in, you could get unlucky.  Also,
this assumes we aren't mlocked to begin with which means that *any*
part of our process could be paged with resultant delays.  If we *do*
mlock() everything, the we need enough RAM for the entire sound file
and I'm not even sure exactly what would happen when doing the mmap().

> well, perhaps not, but he should. oolaboola (sp?)

Indeed..that's the usual translitteration. :)

> has been evolving
> toward some fairly sophisticated memory management to handle this kind
> of stuff.

Yes, and it's all ultimately based around intelligent advance `file'
(meaning `slow device') reads.  alsaplayer's buffering scheme may (as
Andy suggests) also be adequate.  oola has more support for loops and
marks but it doesn't yet handle negative rates.

Eric

From - Mon Oct 25 09:44:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA21595
	for <slinkp@ulster.net>; Sun, 24 Oct 1999 20:05:27 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA19648 for linux-audio-dev-list; Sun, 24 Oct 1999 19:32:29 -0400
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA19645 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 24 Oct 1999 19:32:26 -0400
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S46507AbPJXX0V>; Mon, 25 Oct 1999 02:26:21 +0300
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: sbenno@gardena.net
CC: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu,
        alkoit00@fht-esslingen.de
In-reply-to: <99102417251100.02718@localhost.localdomain> (message from Benno
	Senoner on Sun, 24 Oct 1999 17:14:07 +0200)
Subject: [linux-audio-dev] Re: streaming from disk to terminatorX added (via mmap)
Message-Id: <19991024232629Z46507-565+534@nic.funet.fi>
Date:   Mon, 25 Oct 1999 02:26:21 +0300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 7fdc15846a19267ede571c02e95197f9

>From:   Benno Senoner <sbenno@gardena.net>
>
>- the 44byte WAV header isn't skipped

I suggest the full parse of WAV file because some editors put extra
chunks to end. Actually a full parse is not needed because we need
just to find the offset and length for mmapping, but don't just skip!

Yours,

Juhana

From - Mon Oct 25 09:44:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA08492
	for <slinkp@ulster.net>; Sun, 24 Oct 1999 22:34:26 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA19881 for linux-audio-dev-list; Sun, 24 Oct 1999 21:55:44 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA19878 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 24 Oct 1999 21:55:41 -0400
Received: from someip.ppp.op.net (d-bm2-04.ppp.op.net [209.152.194.36]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id VAA17685; Sun, 24 Oct 1999 21:49:56 -0400 (EDT)
Message-Id: <199910250149.VAA17685@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: Re: [linux-audio-dev] Re: streaming from disk to terminatorX added (via mmap) 
In-reply-to: Your message of "Mon, 25 Oct 1999 02:27:00 EDT."
             <3813F834.D59E238E@42.fht-esslingen.de> 
Date: Sun, 24 Oct 1999 22:45:02 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 8dcc92bed9e231acf75a19382e581079

 [ re: mmap ]

>Hmmmm.... Well I'd prefer a configure switch for the following
>reasons:
>
>- big endian machines

just FYI: my C++ libsoundfile uses mmap(), but still requires
applications to "read" the data. it is significantly faster than using
read(2) internally, however, so there might be an argument for using
mmap regardless of the endianness, and then using arch-dependent
macros to fetch the data from the mmapped area. for example, on a
little endian machine reading from a little endian RIFF/WAV file, the
macros are essentially no-ops. likewise for reading bigendian AIFF's
on bigendian machines. but for the opposite cases, the macros can do
the work necessary, and i think you'll still find mmap to be your
friend.

except, as est noted, if you're using mlockall ...

>- the next release of tX will allow you to load MANY (as many as you
>want) samples in multiple turntables. If all these are mmap'ed files I
>guess your disk-head will jump around like mad when playing.

actually, no more than it would if you use a 4K memory buffer :) 

>- With 6 to 8 tables playing my system is pretty loaded in these cases
>it might be a performance win to have the samples in the memory
>already.. (well these are just assumptions - we should get your code
>applied to the new stuff to see whether it's true...)

benno's code makes sure it *is* in RAM already. just not all of it
at one time.

--p

From - Mon Oct 25 09:44:44 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA19243
	for <slinkp@ulster.net>; Mon, 25 Oct 1999 00:30:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA19999 for linux-audio-dev-list; Sun, 24 Oct 1999 23:52:46 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA19996 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 24 Oct 1999 23:52:39 -0400
Received: from someip.ppp.op.net (d-bm2-04.ppp.op.net [209.152.194.36]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id XAA24692 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 24 Oct 1999 23:46:54 -0400 (EDT)
Message-Id: <199910250346.XAA24692@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] back to the API 
In-reply-to: Your message of "Tue, 19 Oct 1999 21:57:17 +0200."
             <99101923180800.00468@localhost.localdomain> 
Date: Mon, 25 Oct 1999 00:42:02 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 9dde43d3cb60ff2cf67493c8f0f2ea94

one tiny comment, while i'm clearing out some old mail:

>> they send events that say:
>> 
>>      "XXX has changed by +4"
>>      "YYY has changed, new value is 13.4554"
>>      "ZZZ has been incremented"
>> 
>> in each case, XXX, YYY or ZZZ is the target_id of the change, which is
>> assigned by the engine when the plugin declares its "parameters", and
>> is looked up by the plugin during event processing to decide if it
>> really cares.
>
>Well, I believe plug-in code should be as simple as possible, so I
>don't see why alternative ways of changing parameters makes sense...

the alternatives allow the event source to not have to know the
current value of the object being changed. this allows more
flexibility in possible representations to the user, and also avoids
an attempt to cache values when it can be avoided.

having a button that says "XXX has changed by +0.5" is a much better
design than a UI that is *forced* to know the current value of XXX in
order to send the event. OTOH, when a button selects a known value,
having to know the old value is also pretty silly.

Of course, if it wants to display the value of XXX, it has to know it,
but its easy to imagine UI elements that don't need to work like
this. why force them to ?

--p

From - Mon Oct 25 09:44:34 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA29540
	for <slinkp@ulster.net>; Sun, 24 Oct 1999 21:06:59 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA19754 for linux-audio-dev-list; Sun, 24 Oct 1999 20:32:53 -0400
Received: from rhhx01.fht-esslingen.de (rhhx01.fht-esslingen.de [134.108.56.1]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA19751 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 24 Oct 1999 20:32:50 -0400
Received: from firewall.dc.com (rsra61.fht-esslingen.de [134.108.128.61])
	by rhhx01.fht-esslingen.de (8.9.3/8.9.3) with ESMTP id CAA00472;
	Mon, 25 Oct 1999 02:27:02 +0200 (METDST)
Received: from 42.fht-esslingen.de (machtnix.dc.com [192.168.192.168])
	by firewall.dc.com (8.9.3/8.9.3) with ESMTP id BAA00589;
	Mon, 25 Oct 1999 01:22:10 GMT
Message-ID: <3813F834.D59E238E@42.fht-esslingen.de>
Date: Mon, 25 Oct 1999 02:27:00 -0400
From: Alexander =?iso-8859-1?Q?K=F6nig?= <alex@rhlx01.fht-esslingen.de>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.12 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Benno Senoner <sbenno@gardena.net>
CC: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: streaming from disk to terminatorX added (via mmap)
References: <99102417251100.02718@localhost.localdomain>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by rhhx01.fht-esslingen.de id CAA00472
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA29540
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: fe112b9ef021f0e0b422508cf4b9d96c

Hi,

First of: thanks for your patch Benno! Now I applied it but I have a
problem... on my system I get a "no such device"-error. And all my
(mmap)manpage says is: Svr4 documents additional error codes ENXIO and
ENODEV. Do you have any idea what's wrong with my system? I am sorry if
this is a dumb question - I've never used mmap....

Now for the replying:

Benno Senoner wrote:
> for those that are interested:

I am :)

> Yesterday I went on terminatorX's (the scratching app)  homepage (
> http://termX.cjb.net ), and read in the FAQ that it doesn't support streaming
> from disk, because it would require a complete redesign of the app.
> But fortunately Alexander was wrong:
> :-)

Hehe, good to know. Yeah I didn't know how easy this is - dumb me ;)

<..>
> http://www.gardena.net/benno/linux/terminatorX-3.2-mmap.patch

Yeah, ok I have it. Now the problem is I've been working on tX quite a
lot lately and a lot of things have changed. But from looking at your
patch it looks like it should be possible to port your changes to the
new version easily. Please send me a mail, Benno, if you want to have
access to the CVS repository and maybe take a look at the new stuff
yourself. IMHO it would be cool if we could integrate your patch into
the sources, maybe wrapped into some #ifdef USE_MMAP / #endif statements
so the user could decide whether to use mmap or not with a configure
switch....

> Basically what I changed is:
<..>
> With this approach I was able to scratch a 100MB mono file,
> on a 16MB RAM box, running X , KDE and Netscape (what a pain to load netscape :-) ) !
> (using SCHED_FIFO scheduling)

Cool. That definitely helps a lot of people! mmap is really amazing ;)

<..>
> BUGS:
> 
> - the 44byte WAV header isn't skipped
> - mpg123 and sox support doesn't work (would require decompressing
> to a temporary file)
> - might not work on BIGENDIAN boxes

Well, AFAIK the plain tX 3.2 doesn't work on BIGENDIAN machines
either... (sorry big endian users) I plan to get that fixed before I
release the new version... Oh with mmap()-ed files we need to do the
BIGENDIAN-de/encoding right before actually processing a block and not
the way it's done now while loading. That should be possible... oh but
the usual big endian machines have enough memory, right? ;)

> Suggestions to the author:  (any official word from you Alexander ?)
>
> - always use mmap since it will work well on big RAM boxes too,
> and doesn't eat up all you system memory.

Hmmmm.... Well I'd prefer a configure switch for the following
reasons:

- big endian machines
- the next release of tX will allow you to load MANY (as many as you
want) samples in multiple turntables. If all these are mmap'ed files I
guess your disk-head will jump around like mad when playing.
- And the next release will no longer record into memory (yeah for the
same reason you introduced mmap(), Benno ;) but straight to harddisk -
now that would cause a lot of harddisk action with mmap()ed files too...
- With 6 to 8 tables playing my system is pretty loaded in these cases
it might be a performance win to have the samples in the memory
already.. (well these are just assumptions - we should get your code
applied to the new stuff to see whether it's true...)
- I don't want to drop mp3 and sox support (I know a LOT of people use
this)

So maybe you agree it would make sense giving the user the choice
whether to use mmap or not. And for the sake of mp3-compability I'd even
keep the loading-behaviour as the default behaviour. Well at least for
now...

> -in order to support MP3s and other fileformats decompress/convert this
> files first to a temporary WAV file and mmap() this into mem.

That'll work of course but I guess people with machines with enough mem
might prefer loading the file...

> To speed up things even more you could save a the sample graph into
> a little file the first time you load the audio file, so that on subsequent
> loads, the 100MB audio file will "load" almost istantaneously in to mem.
> (thanks to mmap() ).

Thats a cool idea. Now if that mmap() stuff works nicely with kernel 2.4
and mp3 would work with it (see below) it really would make sense to
switch to mmap completely... 

> It would be possible to support direct disk streaming of MP3 files,
> but that is not a trivial task since you can't access an MP3 in
<..>

It's done already! Take a look at Andy's brilliant alsaplayer:
http://www.alsa-project.org/~andy/

He does dynamic-mp3 decoding and it works beautifully...

(Hi Andy, I wrote that before I saw you already replied...)

> PS: Now if we could get one of these turntables recorded with special
> static waves (saw waves), we could add add turntable motion detection
> and get the same features as "finalscratch" on BeOS:
> scratching an audiofile in realtime using a real turntable.
> :-)

I've never seen finalscratch. But how do these static waves you're
talking about work? I'd really like to know how that works... Btw I use
a real turntable for scratching with tX BUT you cannot use it like a
real turntable (well while scratching you can, it wouldn't make sense if
you couldn't) but you still have to press space... I've prepared a
html-page (with some photos and explanation) for my tX-site already and
I'd say it finished. I plan to put it up on the page tomorrow... maybe
you want to take a look at that.

So I'm looking forward to hearing from you again, Benno

Bye,
Alex
-- 
_______________________________________________________________________
                            Alexander Knig - alex@42.fht-esslingen.de
                                                  http://termX.cjb.net

[From the Homer Quotables:]
 
Could this be the best day of my life?

                -- Homer Simpson
                   Homer the Heretic

From - Mon Oct 25 09:44:47 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA03400
	for <slinkp@ulster.net>; Mon, 25 Oct 1999 06:57:38 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA24325 for linux-audio-dev-list; Mon, 25 Oct 1999 06:22:17 -0400
Received: from upf.es (newton.upf.es [193.145.54.60]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA24322 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 25 Oct 1999 06:22:04 -0400
Received: from mtg150.upf.es (mtg150.upf.es [193.145.44.150])
	by upf.es (8.9.0/8.9.0) with SMTP id MAA12990;
	Mon, 25 Oct 1999 12:15:37 +0200 (MET DST)
From: Maarten de Boer <maarten.deboer@iua.upf.es>
Reply-To: maarten.deboer@iua.upf.es
To: alsa-user@alsa-project.org, alsa-devel@alsa-project.org,
        linux-audio-dev@ginette.musique.umontreal.ca, fltk@fltk.org
Subject: [linux-audio-dev] [ANNOUNCE] tapiir, a multi-tap-delay
Date: Mon, 25 Oct 1999 11:17:12 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <99102511232802.20785@mtg150.upf.es>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: ad7b4d8e583721dcefda7771dc22083d

Hello,

I would like to announce a program I wrote this weekend. Before I make
a public announce on freshmeat, I would like some people on this list
to give it a try. Please send me your comments/suggestions.

---
TAPIIR is a software multi-tap-delay. It allows you to setup 6 delay-lines
in a very flexible way, with stereo input/output. It uses multithreading
to combine a GUI with low-latency cd-quality audio. TAPIIR can be used
for example for guitar-effects-processing.

TAPIIR uses the FLTK library and the ALSA library.

Source code: 
ftp://www.things.nl/pub/maarten/tapiir-0.2.2.tgz

i386 binary, statically linked with fltk:
ftp://www.things.nl/pub/maarten/tapiir-static-0.2.2.tgz

---
Maarten

maarten.deboer@iua.upf.es
http://www.iua.upf.es/~mdeboer

From - Tue Oct 26 02:29:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA28538
	for <slinkp@ulster.net>; Mon, 25 Oct 1999 20:18:05 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA25610 for linux-audio-dev-list; Mon, 25 Oct 1999 19:47:57 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA25605 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 25 Oct 1999 19:47:52 -0400
Received: from localhost.localdomain (IDENT:root@[194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id BAA08980;
	Tue, 26 Oct 1999 01:41:40 +0200
Received: from localhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with SMTP id OAA00862;
	Mon, 25 Oct 1999 14:57:47 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Andy Lo A Foe <andy@alsa-project.org>
Subject: Re: [linux-audio-dev] streaming from disk to terminatorX added (via mmap)
Date: Mon, 25 Oct 1999 14:52:29 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu,
        alkoit00@fht-esslingen.de
References: <Pine.LNX.4.05.9910241907220.297-100000@alsa.alsa-project.org>
In-Reply-To: <Pine.LNX.4.05.9910241907220.297-100000@alsa.alsa-project.org>
MIME-Version: 1.0
Message-Id: <99102514574700.00665@localhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4213397d3faddf470ba61d56d5ea64ef

On Sun, 24 Oct 1999, Andy Lo A Foe wrote:

> 
> You might want to check out alsaplayer, http://www.alsa-project.org/~andy/
> It does 'direct streaming from disk' for just about any format without
> using mmap. It uses a ring buffer system and threading to cache data and
> there is code for very low latency modes using SCHED_FIFO.
> If you really want to emulate "finalscratch" just put the scratching mouse
> functionality of terminatorX in some sort of plugin for alsaplayer. It
> supports variable speed control (negative too, which is needed for
> 'scratching'). With a fast enough CDDA capable CDROM you can even
> 'scratch' your music CDs in realtime :-)
> 
>

I doubt it that a CDROM drive can keep up with a nervous scratcher.
:-)
The only solution is to keep in memory 100-200k samples before and past the
actual playing position, but I think reading backwards from a CDROM drive sucks
a lot.

regards,
Benno.

From - Tue Oct 26 02:29:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA27648
	for <slinkp@ulster.net>; Mon, 25 Oct 1999 20:13:32 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA25615 for linux-audio-dev-list; Mon, 25 Oct 1999 19:48:12 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA25612 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 25 Oct 1999 19:48:08 -0400
Received: from localhost.localdomain (IDENT:root@[194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id BAA08983;
	Tue, 26 Oct 1999 01:41:44 +0200
Received: from localhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with SMTP id PAA00899;
	Mon, 25 Oct 1999 15:16:37 +0200
From: Benno Senoner <sbenno@gardena.net>
To: est@hyperreal.org, Paul Barton-Davis <pbd@Op.Net>
Subject: Re: [linux-audio-dev] streaming from disk to terminatorX added (via mmap)
Date: Mon, 25 Oct 1999 14:58:29 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu,
        Alexander Knig <alex@rhlx01.fht-esslingen.de>
References: <19991024203241.15023.qmail@hyperreal.org>
In-Reply-To: <19991024203241.15023.qmail@hyperreal.org>
MIME-Version: 1.0
Message-Id: <99102515163701.00665@localhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7d015ef7cd075eee5c60aa059a0be7e8

On Sun, 24 Oct 1999, est@hyperreal.org wrote:

> I don't see how mmap() can be reliable for this sort of thing.  Even
> if you touch pages to bring them in, you could get unlucky.  Also,
> this assumes we aren't mlocked to begin with which means that *any*
> part of our process could be paged with resultant delays.  If we *do*
> mlock() everything, the we need enough RAM for the entire sound file
> and I'm not even sure exactly what would happen when doing the mmap().
> 
> > well, perhaps not, but he should. oolaboola (sp?)
> 
> Indeed..that's the usual translitteration. :)
> 
> > has been evolving
> > toward some fairly sophisticated memory management to handle this kind
> > of stuff.
> 
> Yes, and it's all ultimately based around intelligent advance `file'
> (meaning `slow device') reads.  alsaplayer's buffering scheme may (as
> Andy suggests) also be adequate.  oola has more support for loops and
> marks but it doesn't yet handle negative rates.
> 

Eric,
when not mlock()-ing the entire process (or at least the RT relevant data),
you have no chance to give ANY guarantee thet some pages could
not be swapped out.

What I'm trying to say: read() doesn't work better than mmap() in terms of
behaviour during swapping, because the kernel could easily swap out
your buffer where you read() in the data.
Your argument is not a valid argument to me.

Of course an even better solution than my "pagefaulter" thread ,
(but it will require root privileges), is to use a
thread which basically mlock() / munlock() the region around the 
actual playing position.
It's very easy to add to the pagefaulter thread:
instead of accessing to the pages just do the following in the while() loop:
(for example)

munlock() old range  ( old_start, old_len)

new_start=&samplebuffer[current_pos-100k];
new_len=200k;
( chekc the boundaries of start and len !)
mlock() new range (new_start,new_len)  


easy eh ?

SCHED_FIFO plus the above mlock()/munlock() is almost bulletproof.

normal scheduling plus the pagefaulter thread touching the pages is as reliable
as doing regular reads().
But here comes the linux low-latency problem:

In my tests using a buffer size of 100ms in terminator-X  (SCHED_FIFO) ,
I was able to play dropout-free audio on a 16MB RAM box,
running RH6.1 , X , KDE , netscape , 
10 processes which do  for(;;);   = CPU wasting loop
plus a cat /usr/bin/* >/dev/null running continuously 

of course 100ms is way too much for scratching in realtime,
but apply the lowlatency patches to the kernel and tune the disk and I'm sure
you can scratch trouble-free with 5ms latency or less.

I will add a feature to the pagefaulter thread which uses mlock()/munlock if
root privileges are available, so that even
Eric is satisfied.
:-)

someone still sceptic ?
:-)

PS: mlockall(MCL_CURRENT|MCL_FUTURE) is a bad idea because when you do the
mmap() of the large file the process tries to load all into mem,and my scheme
would not work. Better to use mlockall(MCL_CURRENT) and mlock()/munlock()
areas on demand.

regards,
Benno.
 

From - Tue Oct 26 02:29:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA28544
	for <slinkp@ulster.net>; Mon, 25 Oct 1999 20:18:06 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA25607 for linux-audio-dev-list; Mon, 25 Oct 1999 19:47:54 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA25602 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 25 Oct 1999 19:47:48 -0400
Received: from localhost.localdomain (IDENT:root@[194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id BAA08977;
	Tue, 26 Oct 1999 01:41:33 +0200
Received: from localhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with SMTP id QAA00966;
	Mon, 25 Oct 1999 16:14:15 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Alexander Knig <alex@rhlx01.fht-esslingen.de>
Subject: [linux-audio-dev] Re: streaming from disk to terminatorX added (via mmap)
Date: Mon, 25 Oct 1999 15:32:49 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu,
        Andy Lo A Foe <andy@alsa-project.org>
References: <99102417251100.02718@localhost.localdomain> <3813F834.D59E238E@42.fht-esslingen.de>
In-Reply-To: <3813F834.D59E238E@42.fht-esslingen.de>
MIME-Version: 1.0
Message-Id: <99102516141502.00665@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by em.gardena.net id BAA08977
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA28544
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: ec0bdc6273916974920fe3f1cf26ff15

On Mon, 25 Oct 1999, Alexander Knig wrote:
> Hi,
> 
> First of: thanks for your patch Benno! Now I applied it but I have a
> problem... on my system I get a "no such device"-error. And all my
> (mmap)manpage says is: Svr4 documents additional error codes ENXIO and
> ENODEV. Do you have any idea what's wrong with my system? I am sorry if
> this is a dumb question - I've never used mmap....

hmmm that is strange ...
where exactly after the mmap ?
try to check if MYFILESIZE is a valid value (page aligned size of the file),
if fileno(wav_in.handle) is a valid value etc

> 
> Yeah, ok I have it. Now the problem is I've been working on tX quite a
> lot lately and a lot of things have changed. But from looking at your
> patch it looks like it should be possible to port your changes to the
> new version easily. Please send me a mail, Benno, if you want to have
> access to the CVS repository and maybe take a look at the new stuff
> yourself. IMHO it would be cool if we could integrate your patch into
> the sources, maybe wrapped into some #ifdef USE_MMAP / #endif statements
> so the user could decide whether to use mmap or not with a configure
> switch....


> 
> > Basically what I changed is:
> <..>
> > With this approach I was able to scratch a 100MB mono file,
> > on a 16MB RAM box, running X , KDE and Netscape (what a pain to load netscape :-) ) !
> > (using SCHED_FIFO scheduling)
> 
> Cool. That definitely helps a lot of people! mmap is really amazing ;)
> 
> <..>
> > BUGS:
> > 
> > - the 44byte WAV header isn't skipped
> > - mpg123 and sox support doesn't work (would require decompressing
> > to a temporary file)
> > - might not work on BIGENDIAN boxes
> 
> Well, AFAIK the plain tX 3.2 doesn't work on BIGENDIAN machines
> either... (sorry big endian users) I plan to get that fixed before I
> release the new version... Oh with mmap()-ed files we need to do the
> BIGENDIAN-de/encoding right before actually processing a block and not
> the way it's done now while loading. That should be possible... oh but
> the usual big endian machines have enough memory, right? ;)

Ok skipping the WAV header is really easy , just add the offset to samplebuffer
before you start the engine, but subtract the value before doing any free()
or you will get nice segfaults because you are trying to free inexistent memory
areas.
For BIGENDIAN boxes, I'd suggest to do the byte swapping just before you process
the data, the overhead is very little compared to all the rest.


> 
> > Suggestions to the author:  (any official word from you Alexander ?)
> >
> > - always use mmap since it will work well on big RAM boxes too,
> > and doesn't eat up all you system memory.
> 
> Hmmmm.... Well I'd prefer a configure switch for the following
> reasons:
> 
> - big endian machines

use byte swapping on the fly

> - the next release of tX will allow you to load MANY (as many as you
> want) samples in multiple turntables. If all these are mmap'ed files I
> guess your disk-head will jump around like mad when playing.

the trick is the following:
actually I access to the pages about 10times / sec.
With multiple streams to reduce overhead you have to avoid
that all the files are accessed  10-20times/sec, but you have
to do this sequentially and must use larger in-memory buffers:
that means you should "read" the memory buffers at least
in 128k-256k blocks to keep the disk seeking down.

I esperimented with streaming of 60 mono ( 44khz 16bit) tracks from disk
and I had to use at least 1MB buffer per track to keep things somewhat
reliable.
( PII400 + 256MB RAM + IBM 16GB EDIE HD)
 

> - And the next release will no longer record into memory (yeah for the
> same reason you introduced mmap(), Benno ;) but straight to harddisk -
> now that would cause a lot of harddisk action with mmap()ed files too...
> - With 6 to 8 tables playing my system is pretty loaded in these cases
> it might be a performance win to have the samples in the memory
> already.. (well these are just assumptions - we should get your code
> applied to the new stuff to see whether it's true...)

How du you plan to keep into mem 8 files of 20MB in len (4min mono file)
= 160MB, not everyone has that amount of ram on his box.

Trust me: smart mmap() + mlocking() will work well and reliably on 8 tracks
while saving the mix on the disk, using no more that 500kb-1Mb per track.


> - I don't want to drop mp3 and sox support (I know a LOT of people use
> this)

for mp3:
if this is really true that Andy has managed to play mp3s backwards *CORRECTLY*
without any distortion, then if I were You, I would include his mp3 code.

Andy are you saving filterstate information in your alsa player ?
that means what happens if I play the file from the beginning to almost the end,
and then I reverse the playing direction and play the file until it reaches the
start ?
Does all this process sound 100% correctly ?
It would require to save the filter state of every played MPEG frame right ?


SOX: you can provide 2 methods: direct in mem loading or converting to a
temporary file and then mmap() the file into mem.
let's the user take the choice.

> 
> So maybe you agree it would make sense giving the user the choice
> whether to use mmap or not. And for the sake of mp3-compability I'd even
> keep the loading-behaviour as the default behaviour. Well at least for
> now...

IMHO on low mem boxes, it's better to first decompress the mp3 to a temporary
wav file and then mmap() this into mem, instead of loading all into mem
(which would swapout almost the entire file to the swaparea), and would take
even more time than the pure decompressing of the mp3 to the wav file.
Remember in your case the probability that swapping might occur is much higher
since your file in memory used up almost all physical memory.
Instead in the mmap()ed case there is still physical memory free for other
things, since mmap() buffers only the most recent pages.

> 
> > -in order to support MP3s and other fileformats decompress/convert this
> > files first to a temporary WAV file and mmap() this into mem.
> 
> That'll work of course but I guess people with machines with enough mem
> might prefer loading the file...

Yea, provide both, as you can see from the patch, the pure mmap()ing of
the file requires very little effort: instead of malloc()ing a memory region 
and read the file into mem, just mmap() the file in that region.

> 
> > To speed up things even more you could save a the sample graph into
> > a little file the first time you load the audio file, so that on subsequent
> > loads, the 100MB audio file will "load" almost istantaneously in to mem.
> > (thanks to mmap() ).
> 
> Thats a cool idea. Now if that mmap() stuff works nicely with kernel 2.4
> and mp3 would work with it (see below) it really would make sense to
> switch to mmap completely... 

mmap() already worked nicely with most linux kernels, and in 2.4 it will work
even better due to the improved LRU paging algorithms.

> 
> > PS: Now if we could get one of these turntables recorded with special
> > static waves (saw waves), we could add add turntable motion detection
> > and get the same features as "finalscratch" on BeOS:
> > scratching an audiofile in realtime using a real turntable.
> > :-)
> 
> I've never seen finalscratch. But how do these static waves you're
> talking about work? I'd really like to know how that works... Btw I use
> a real turntable for scratching with tX BUT you cannot use it like a
> real turntable (well while scratching you can, it wouldn't make sense if
> you couldn't) but you still have to press space... I've prepared a
> html-page (with some photos and explanation) for my tX-site already and
> I'd say it finished. I plan to put it up on the page tomorrow... maybe
> you want to take a look at that.
> 
> So I'm looking forward to hearing from you again, Benno

Finalscratch I have not the link handy 
 look at http://www.be.com   or http://www.lebuzz.com and search
for finalscratch in the audio apps section and you will find the link.
(or alternatively try a search engine like google or so, should find the URL
too)

Basically as far I understand they sample (using the soundcard) a static wave
recorded on the turntable and compute the actual rotational speed.
Then just feed this value to the tX engine, and your
mp3 on-turntable scratcher is here.
:-)

In the next days I will add mlock()/munlock() support to tX let's see it there
are any benefits during high system load.


Alex, if you want to mail me privately you can mail me in german too,
( I'm from Suedtirol  :-)  )

Benno.

From - Tue Oct 26 02:29:28 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA28056
	for <slinkp@ulster.net>; Mon, 25 Oct 1999 20:15:34 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA25600 for linux-audio-dev-list; Mon, 25 Oct 1999 19:47:43 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA25597 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 25 Oct 1999 19:47:38 -0400
Received: from localhost.localdomain (IDENT:root@[194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id BAA08974;
	Tue, 26 Oct 1999 01:41:25 +0200
Received: from localhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with SMTP id QAA01022;
	Mon, 25 Oct 1999 16:43:11 +0200
From: Benno Senoner <sbenno@gardena.net>
To: David Olofson <audiality@swipnet.se>,
        linux-audio-dev@ginette.musique.umontreal.ca,
        linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: streaming from disk to terminatorX added (via mmap)
Date: Mon, 25 Oct 1999 16:32:02 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: alkoit00@fht-esslingen.de
References: <99102417251100.02718@localhost.localdomain> <99102420100100.00454@localhost.localdomain>
In-Reply-To: <99102420100100.00454@localhost.localdomain>
MIME-Version: 1.0
Message-Id: <99102516431103.00665@localhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: b2bac6654b2b7ef159cd201ef917afa3

On Sun, 24 Oct 1999, David Olofson wrote:
> On Sun, 24 Oct 1999, Benno Senoner wrote:
> > PS: Now if we could get one of these turntables recorded with special
> > static waves (saw waves), we could add add turntable motion detection
> > and get the same features as "finalscratch" on BeOS:
> > scratching an audiofile in realtime using a real turntable.
> > :-)
> 
> Uhm, I have just developed a sensor decoding method that could be
> useful for this. It's probably overkill, as it's accurate to some 128
> bits/period of the input signal with input signals of around that
> resolution. It's just that I most probably can't release the
> details... :-(
> 

David, your solution looks nicely,
but I'm more for a plug-n-play solution:

2 turntable players
2 soundcards
1 PC loaded with mp3

use the 2 soundcard's inputs to detect turntable speed (py playing the static
waves on the turntable),
use the 2 audio outputs for the mix and prelisten (phones) channel.

IMHO the precision provided by sampling the turnables's static waves
is enough to get decent scratches, and the use of a "noise gate" when
the turntable is rotating at default speed will give you the final touch of
perfection.
:-)

David, I'cant remember but what would be the optimal method to detect
the speed of the turntables via audio input ?

form of the wave ?
SAW WAVE , which frequency ?

and then the algorithm ?
couting the number of zero crosses/sign changes ?
how o detect motion inversion ?
through looking at the resulting waveform ? :
if the next value is less than the previous 
AND you are not at end of the period (the jump is too big),
then you detected motion inversion.
right ?

The finalscratch people seemed wrong to think that only BeOS can provide
the horsepower to run a scratch-mp3s-on-turntable engine.

Seems that linux , will soon even begin to eat marketshare into the DJ sector.
:-)
( As David said: your next console could be powered by a GPLed audio engine
running Linux  :-)  )

Benno.

From - Tue Oct 26 02:29:25 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA14754
	for <slinkp@ulster.net>; Mon, 25 Oct 1999 18:57:05 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA25450 for linux-audio-dev-list; Mon, 25 Oct 1999 18:22:11 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA25447 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 25 Oct 1999 18:22:08 -0400
Received: from localhost.localdomain (d212-151-34-132.swipnet.se [212.151.34.132]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA28929; 
          Tue, 26 Oct 1999 00:16:17 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] back to the API
Date: Tue, 26 Oct 1999 00:00:14 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910250346.XAA24692@renoir.op.net>
In-Reply-To: <199910250346.XAA24692@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99102600234300.03060@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id AAA28929
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA14754
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 793b90ca8d00bac456a19dd29ccb23b3

On Mon, 25 Oct 1999, Paul Barton-Davis wrote:
> >Well, I believe plug-in code should be as simple as possible, so I
> >don't see why alternative ways of changing parameters makes sense...
> 
> the alternatives allow the event source to not have to know the
> current value of the object being changed. this allows more
> flexibility in possible representations to the user, and also avoids
> an attempt to cache values when it can be avoided.
> 
> having a button that says "XXX has changed by +0.5" is a much better
> design than a UI that is *forced* to know the current value of XXX in
> order to send the event. OTOH, when a button selects a known value,
> having to know the old value is also pretty silly.
> 
> Of course, if it wants to display the value of XXX, it has to know it,
> but its easy to imagine UI elements that don't need to work like
> this. why force them to ?

Ok... It adds complexity to the event system definition (plugins
*have to* support both) and automation code (position tracking), but
it might not be that bad. And there is complexity involved with
keeping track of the current value of a parameter as well.

OTOH, sending inc/dec events to plugins is kind of like moving a
part of the UI into the plugin, IMO. It might be a little speed
optimization when used, and even simplify things in those cases. But
how often do you use inc/dec buttons without any indicator? I can't
remember seeing *any* plugin GUI that has such a function, and from
the user POV, I don't think I want to see any - how would you know
what you're doing?

* Sliders know their position anyway - trying to work around
  that only results in position/parameter sync bugs.

* Inc/dec buttons affect some kind of display. (Well, I've
  seen other similar things that don't work like that, and
  that's usually a very annoying experience. "Where the h*ll
  am I!?")

* "Mode select" style buttons (radio) send fixed values. No
  inc/dec events here.

I'm probably missing something, 'cause actually I can't see much point
in supporting inc/dec and similar things at plugin level at all...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Oct 26 02:29:22 1999
Received: from taz.ulster.net (root@taz.ulster.net [208.148.73.10])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id SAA08542
	for <slinkp@ulster.net>; Mon, 25 Oct 1999 18:21:39 -0400
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34]) by taz.ulster.net (8.8.5/8.7.3) with SMTP id SAA07815 for <slinkp@ulster.net>; Mon, 25 Oct 1999 18:24:33 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA25374 for linux-audio-dev-list; Mon, 25 Oct 1999 17:53:57 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA25371 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 25 Oct 1999 17:53:55 -0400
Received: from someip.ppp.op.net (d-bm3-0e.ppp.op.net [209.152.194.78]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id RAA16689; Mon, 25 Oct 1999 17:48:06 -0400 (EDT)
Message-Id: <199910252148.RAA16689@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: Re: [linux-audio-dev] Re: streaming from disk to terminatorX added (via mmap) 
In-reply-to: Your message of "Mon, 25 Oct 1999 22:57:09 EDT."
             <38151885.7A650570@42.fht-esslingen.de> 
Date: Mon, 25 Oct 1999 18:43:25 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d40b106c81f08143404529c5a1be9976

In message <38151885.7A650570@42.fht-esslingen.de>you write:
>Paul Barton-Davis wrote:
>> just FYI: my C++ libsoundfile uses mmap(), but still requires
>> applications to "read" the data. it is significantly faster than using
>> read(2) internally, however, so there might be an argument for using
>> mmap regardless of the endianness, and then using arch-dependent
>> macros to fetch the data from the mmapped area. for example, on a
>> little endian machine reading from a little endian RIFF/WAV file, the
>> macros are essentially no-ops.
>
>No-ops? Do you mean you don't generate ANY code for this? If so: HOW?

sorry, not very accurate. for example:

       int16 foo;
       unsigned char *p;

       foo = get_little_endian_int16 (p)

on an LE machine, this is just:

       foo = *((int16 *) p);

on a BE machine, its a bit more complex.

the first case is what i meant by a "noop", not a literal NOOP.

>??? Yeah sure, using a limited buffer will have the same effect but the
>way tX currently does it is like the good ole trackers did it: it loads
>the samples COMPLETELY in RAM so there is no disk-activity at all while
>playing....

not so, unless you use mlockall. you mean, completely in VM. not quite
the same thing.

>> benno's code makes sure it *is* in RAM already. just not all of it
>> at one time.
>
>Yeah, you are right. I guess what I wanted to say was: If you mmap()
>files instead of loading there's a lot of other stuff happening aside
>for audio-rendering (you know like mmap()-code, fs-code, ide-code...)
>Now if you have a lot of turntables and some effects enabled your CPU
>may be pretty busy getting the audio ready for playback and that
>additional code may be too much.. well still: it's just an assumption ;)

unless you mlock(all) the pages on which your soundfile lives, there
is no reason why the CPU has to do anymore work in the mmap(2) case
than in the "malloc(3); read (2)" case, assuming that after mmap() you
touch every page of the mmapped-file (this makes it equivalent to the
"read" case, since there, the reading-in touched very page of the data
too). in both cases, a page may be paged out, and cause a page fault,
requiring the CPU to initiate a fetch. if its not paged out, no extra
cost either way.

--p

From - Tue Oct 26 02:29:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA08399
	for <slinkp@ulster.net>; Mon, 25 Oct 1999 21:33:36 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA25720 for linux-audio-dev-list; Mon, 25 Oct 1999 21:02:09 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA25717 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 25 Oct 1999 21:02:05 -0400
Received: from localhost.localdomain (d212-151-34-132.swipnet.se [212.151.34.132]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA20224; 
          Tue, 26 Oct 1999 02:56:14 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Benno Senoner <sbenno@gardena.net>,
        linux-audio-dev@ginette.musique.umontreal.ca,
        linux-sound@vger.rutgers.edu
Subject: Re: [linux-audio-dev] Re: streaming from disk to terminatorX added (via mmap)
Date: Tue, 26 Oct 1999 02:33:34 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: alkoit00@fht-esslingen.de
References: <99102417251100.02718@localhost.localdomain> <99102420100100.00454@localhost.localdomain> <99102516431103.00665@localhost.localdomain>
In-Reply-To: <99102516431103.00665@localhost.localdomain>
MIME-Version: 1.0
Message-Id: <99102603033903.03060@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id CAA20224
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA08399
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 334aaab1ce52f7e92557f8d2e5b24ed0

On Mon, 25 Oct 1999, Benno Senoner wrote:
> David, your solution looks nicely,
> but I'm more for a plug-n-play solution:
> 
> 2 turntable players
> 2 soundcards
> 1 PC loaded with mp3
> 
> use the 2 soundcard's inputs to detect turntable speed (py playing the static
> waves on the turntable),
> use the 2 audio outputs for the mix and prelisten (phones) channel.
> 
> IMHO the precision provided by sampling the turnables's static waves
> is enough to get decent scratches, and the use of a "noise gate" when
> the turntable is rotating at default speed will give you the final touch of
> perfection.
> :-)

Well, decoding "audio style" signals into speed (or ratherposition) is
*exactly* what my decoding method does. Only, in this case it can
be simplified quite a bit. :-) (I have a carrier frequency to deal
with, and *very* high precision is required. Nice collection of
signal enhacers and trackers already, and I'm still working on it...)

> David, I'cant remember but what would be the optimal method to detect
> the speed of the turntables via audio input ?
> 
> form of the wave ?
> SAW WAVE , which frequency ?

Two alternatives I can think of right now;

1) A "ramp" (saw) wave.

2) Two sine waves (stereo), 90 degrees out of phase.

> and then the algorithm ?

1) Phase lock to the zero crossings.

2) "angle" = atan(left/right). Phase lock and count quadrant.

> couting the number of zero crosses/sign changes ?

1) Yes. (That's about all you can do in any easy way, due to
   the effect the analog cicuitry has on the saw wave...)

2) Yes, for the phase locking. The atan() gives the current
   position within the current quadrant, so you can use a low
   frequency waveform ==> very high upper speed limit.

> how o detect motion inversion ?

1) Check the ramp climb/fall tendency around the zero
   crossing. Be aware that the signal may not look all that
   much like a saw wave at high speeds!

2) The atan() fixes the high precision part. Check the
   right/left relation to see if you should count up or down
   in the zero crossings. (Note: The zero crossings are
   alternating between left and right; one for each quadrant
   crossing.) A simpler way (if you have nice signals) is to
   just check which one of +90 or -90 degrees places the new
   reading closest to the previous one.

> through looking at the resulting waveform ? :
> if the next value is less than the previous 
> AND you are not at end of the period (the jump is too big),
> then you detected motion inversion.
> right ?

Yes, but you'd better integrate some (reset when the "jump" is
detected!), or you may not get the result you expect. Next problem;
the jump won't be anything like sharp and easy to detect in real
life, at least not if you're looking for changes in the signal on "DC
dynamis level" at the same time...

> The finalscratch people seemed wrong to think that only BeOS can provide
> the horsepower to run a scratch-mp3s-on-turntable engine.

Hmm... The horsepower is in the *box*. Real time support is the
"only" special feature needed for this - and we're probably beating
them on that by now.

> Seems that linux , will soon even begin to eat marketshare into the DJ sector.
> :-)
> ( As David said: your next console could be powered by a GPLed audio engine
> running Linux  :-)  )

Why not? As far as I can see, it's really more about performance and
being able to do it reliably, than about tons of features that will
take years to hack. That is, no one without a real OS performance
edge can compete. Go for it! :-)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Oct 26 02:29:18 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA02645
	for <slinkp@ulster.net>; Mon, 25 Oct 1999 17:48:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA25317 for linux-audio-dev-list; Mon, 25 Oct 1999 17:16:05 -0400
Received: from rhhx01.fht-esslingen.de (rhhx01.fht-esslingen.de [134.108.56.1]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA25314 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 25 Oct 1999 17:16:02 -0400
Received: from firewall.dc.com (rsra16.fht-esslingen.de [134.108.128.16])
	by rhhx01.fht-esslingen.de (8.9.3/8.9.3) with ESMTP id XAA04104;
	Mon, 25 Oct 1999 23:10:06 +0200 (METDST)
Received: from 42.fht-esslingen.de (machtnix.dc.com [192.168.192.168])
	by firewall.dc.com (8.9.3/8.9.3) with ESMTP id WAA00471;
	Mon, 25 Oct 1999 22:05:10 GMT
Message-ID: <38151885.7A650570@42.fht-esslingen.de>
Date: Mon, 25 Oct 1999 22:57:09 -0400
From: Alexander =?iso-8859-1?Q?K=F6nig?= <alex@rhlx01.fht-esslingen.de>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.12 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Barton-Davis <pbd@Op.Net>
CC: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: Re: [linux-audio-dev] Re: streaming from disk to terminatorX added (via 
 mmap)
References: <199910250149.VAA17685@renoir.op.net>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by rhhx01.fht-esslingen.de id XAA04104
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id RAA02645
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4428ff675e926fad374d5fea8e189d1a

Paul Barton-Davis wrote:
> just FYI: my C++ libsoundfile uses mmap(), but still requires
> applications to "read" the data. it is significantly faster than using
> read(2) internally, however, so there might be an argument for using
> mmap regardless of the endianness, and then using arch-dependent
> macros to fetch the data from the mmapped area. for example, on a
> little endian machine reading from a little endian RIFF/WAV file, the
> macros are essentially no-ops.

No-ops? Do you mean you don't generate ANY code for this? If so: HOW?

<..>
> >- the next release of tX will allow you to load MANY (as many as you
> >want) samples in multiple turntables. If all these are mmap'ed files I
> >guess your disk-head will jump around like mad when playing.
> 
> actually, no more than it would if you use a 4K memory buffer :)

??? Yeah sure, using a limited buffer will have the same effect but the
way tX currently does it is like the good ole trackers did it: it loads
the samples COMPLETELY in RAM so there is no disk-activity at all while
playing....

> >- With 6 to 8 tables playing my system is pretty loaded in these cases
> >it might be a performance win to have the samples in the memory
> >already.. (well these are just assumptions - we should get your code
> >applied to the new stuff to see whether it's true...)
> 
> benno's code makes sure it *is* in RAM already. just not all of it
> at one time.

Yeah, you are right. I guess what I wanted to say was: If you mmap()
files instead of loading there's a lot of other stuff happening aside
for audio-rendering (you know like mmap()-code, fs-code, ide-code...)
Now if you have a lot of turntables and some effects enabled your CPU
may be pretty busy getting the audio ready for playback and that
additional code may be too much.. well still: it's just an assumption ;)

Bye, Alex
-- 
_______________________________________________________________________
                            Alexander Knig - alex@42.fht-esslingen.de
                                                  http://termX.cjb.net

[From the Homer Quotables:]
 
I'll work from midnight to eight, come home, sleep for
five minutes, eat breakfast, sleep six more minutes,
shower, then I have ten minutes to bask in Lisa's love,
then I'm off to the power plant fresh as a daisy.

		-- Homer Simpson
		   Lisa's Pony


From - Tue Oct 26 04:09:17 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id DAA11795
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 03:42:49 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id DAA29999 for linux-audio-dev-list; Tue, 26 Oct 1999 03:05:36 -0400
Received: from alsa.alsa-project.org (alsa.jcu.cz [160.217.1.49]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA29996 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 03:05:32 -0400
Received: from localhost (andy@localhost)
	by alsa.alsa-project.org (8.8.8/8.8.8) with ESMTP id IAA24890;
	Tue, 26 Oct 1999 08:59:40 +0200
Date: Tue, 26 Oct 1999 08:59:40 +0200 (MEST)
From: Andy Lo A Foe <andy@alsa-project.org>
To: Benno Senoner <sbenno@gardena.net>
cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu,
        alkoit00@fht-esslingen.de
Subject: Re: [linux-audio-dev] streaming from disk to terminatorX added (via
 mmap)
In-Reply-To: <99102514574700.00665@localhost.localdomain>
Message-ID: <Pine.LNX.4.05.9910260854120.24753-100000@alsa.alsa-project.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0eb8db3670a63920459eae64573890b5

On Mon, 25 Oct 1999, Benno Senoner wrote:

> I doubt it that a CDROM drive can keep up with a nervous scratcher.
> :-)

Well, my Hitachi DVD-ROM does very well. I can get sustained playback 
at 500% (that's like ripping at 5 speed). Reverse playback works at up to
-400% reliably, that's enough for most 'scratching' purposes, unless the
DJs speed their records up 10x for a period of a few seconds :)

> The only solution is to keep in memory 100-200k samples before and past the
> actual playing position, but I think reading backwards from a CDROM drive sucks
> a lot.

Oh, actually I never read 'backwards' from a CD, or for that matter decode
an mp3 backwards. The ringbuffer is about 300K so that's enough for about
2 seconds of music.

Andy
--
AlsaPlayer, http://www.alsa-project.org/~andy/

From - Tue Oct 26 04:09:20 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id DAA11803
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 03:42:52 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id DAA00024 for linux-audio-dev-list; Tue, 26 Oct 1999 03:09:57 -0400
Received: from alsa.alsa-project.org (alsa.jcu.cz [160.217.1.49]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA00021 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 03:09:54 -0400
Received: from localhost (andy@localhost)
	by alsa.alsa-project.org (8.8.8/8.8.8) with ESMTP id JAA24966;
	Tue, 26 Oct 1999 09:04:00 +0200
Date: Tue, 26 Oct 1999 09:04:00 +0200 (MEST)
From: Andy Lo A Foe <andy@alsa-project.org>
To: Benno Senoner <sbenno@gardena.net>
cc: David Olofson <audiality@swipnet.se>,
        linux-audio-dev@ginette.musique.umontreal.ca,
        linux-sound@vger.rutgers.edu, alkoit00@fht-esslingen.de
Subject: Re: [linux-audio-dev] Re: streaming from disk to terminatorX added
 (via mmap)
In-Reply-To: <99102516431103.00665@localhost.localdomain>
Message-ID: <Pine.LNX.4.05.9910260901140.24753-100000@alsa.alsa-project.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f8b8528a47f7a0be461ad953dc26934b

On Mon, 25 Oct 1999, Benno Senoner wrote:

> The finalscratch people seemed wrong to think that only BeOS can provide
> the horsepower to run a scratch-mp3s-on-turntable engine.

I have volunteered to port the software to Linux (the original author of
finalscratch lives in my town and I know him from BeOS meetings). Haven't
heard anything back. I'm starting to think the decision to port to Linux 
is more political than technical :)

Andy
--
AlsaPlayer, http://www.alsa-project.org/~andy/

From - Tue Oct 26 22:26:31 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA20571
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 06:30:51 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id DAA00120 for linux-audio-dev-list; Tue, 26 Oct 1999 03:56:38 -0400
Received: from alsa.alsa-project.org (alsa.jcu.cz [160.217.1.49]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA00117 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 03:56:33 -0400
Received: from localhost (andy@localhost)
	by alsa.alsa-project.org (8.8.8/8.8.8) with ESMTP id JAA25598;
	Tue, 26 Oct 1999 09:50:37 +0200
Date: Tue, 26 Oct 1999 09:50:37 +0200 (MEST)
From: Andy Lo A Foe <andy@alsa-project.org>
To: Benno Senoner <sbenno@gardena.net>
cc: =?X-UNKNOWN?Q?Alexander_K=F6nig?= <alex@rhlx01.fht-esslingen.de>,
        linux-audio-dev@ginette.musique.umontreal.ca,
        linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: streaming from disk to terminatorX added (via mmap)
In-Reply-To: <99102516141502.00665@localhost.localdomain>
Message-ID: <Pine.LNX.4.05.9910260908140.24753-100000@alsa.alsa-project.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 773bef048d7814594f6d40fed978fe85

On Mon, 25 Oct 1999, Benno Senoner wrote:

> for mp3:
> if this is really true that Andy has managed to play mp3s backwards *CORRECTLY*
> without any distortion, then if I were You, I would include his mp3 code.
> 
> Andy are you saving filterstate information in your alsa player ?

No

> that means what happens if I play the file from the beginning to almost the end,
> and then I reverse the playing direction and play the file until it reaches the
> start ? Does all this process sound 100% correctly ?

Yes

> It would require to save the filter state of every played MPEG frame right ?

It works like this: the ringbuffer I use is segmented;

		
	disk/cdrom based mp3/cdda/wav/etc		
		|
		|
	audio decoder thread
	decodes mp3/cdda/wav/etc
	fills the framebuffer segments
		|
		|

[|---------|---------|---------|----------|---------|] ringbuffer
             segment			
					|
					|
				audio reader thread
				reads framebuffer segments
				and feeds the soundcard
					|
					|
				    soundcard	


A segment holds a number of decoded frames (usually 2 or 3) and also
remembers the number of the first frame. So lets say we want to play 
a mp3 backwards starting at frame 1000. The tricky part is to keep the
ringbuffer full with the right frames all the time. As soon as one segment
is used up by the audio reader thread it releases a semaphore on which the
audio decoder thread is blocking on. The audio decoder thread wakes up and
check if there are any segments that needs to be filled. But wait you say,
what if you need to fill a segment with frames 1000 to 998? Decoding frame
1000, then 999 and then 998 won't work because of the way mp3s are
encoded. What do you do then? You seek to frame 995 and start decoding
from there. You throw all data away up to and including frame 997. By this
time your mp3 decoding engine is recovered from the 'seek' operation. Now
you store the next 3 frames in your ringbuffer. The audio reader thread,
when detecting negative speed, simply reads a segment backwards so in
this case it starts at frame 1000. The segment before the current one
must contain frame 995 to 997 (first jump to frame 992, decode 3
frames and discard them, decode the needed data), and so on...
The decoder thread is also a couple of segments ahead of the reader
thread. So when you do rapid positive and negative speed switching
(scratching) the decoder thread is actually idling since none of the
segments get discarded. 

Comments? :)

Andy

PS. On my lowly PII 233 I can actually play quite a few mp3's (tested with
7), each with different speed, simultaneously. This is with ALSA and a Trident
4DWave NX card that does hardware mixing.
--
AlsaPlayer, http://www.alsa-project.org/~andy/

From - Tue Oct 26 02:29:40 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA05898
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 01:44:00 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id BAA29769 for linux-audio-dev-list; Tue, 26 Oct 1999 01:16:17 -0400
Received: from rhhx01.fht-esslingen.de (rhhx01.fht-esslingen.de [134.108.56.1]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA29765 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 01:16:13 -0400
Received: from firewall.dc.com (rsra23.fht-esslingen.de [134.108.128.23])
	by rhhx01.fht-esslingen.de (8.9.3/8.9.3) with ESMTP id HAA11302;
	Tue, 26 Oct 1999 07:10:20 +0200 (METDST)
Received: from 42.fht-esslingen.de (machtnix.dc.com [192.168.192.168])
	by firewall.dc.com (8.9.3/8.9.3) with ESMTP id GAA01162;
	Tue, 26 Oct 1999 06:05:36 GMT
Message-ID: <38158C18.41C92BEC@42.fht-esslingen.de>
Date: Tue, 26 Oct 1999 07:10:16 -0400
From: Alexander =?iso-8859-1?Q?K=F6nig?= <alex@rhlx01.fht-esslingen.de>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.12 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Barton-Davis <pbd@Op.Net>
CC: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: Re: [linux-audio-dev] Re: streaming from disk to terminatorX added (via 
 mmap)
References: <199910252148.RAA16689@renoir.op.net>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by rhhx01.fht-esslingen.de id HAA11302
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id BAA05898
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0b7831f65985ff92338426b32b551019

First of: thanks for explaining all of this... I was looking through the
"api-glasses" and not at what *really* happens (at pageing level) I
guess.

Paul Barton-Davis wrote:
<..>
[byteswapping]
> on an LE machine, this is just:
> 
>        foo = *((int16 *) p);
> 
> on a BE machine, its a bit more complex.
> 
> the first case is what i meant by a "noop", not a literal NOOP.

Yeah well was thinking "BE" when I said that would need a little more
work. You know currently (on BE machines) tX byteswaps the (whole) data
while loading. Now this of course is not possible with mmap(). This
means the loop that has to be done in realtime looks like this:
with malloc()/read(): 
	- process_sample
	- bytes_swap_sample // for audiodevice
with mmap():
	- bytes_swap_sample //from wav 
	- process_sample 
	- byte_swap_sample // for audiodevice

Well, after considering what "process_sample" actually means (a LOT of
code ;) you are right: byteswapping is nearly a noop, even on BE
machines...

<..>
> >the samples COMPLETELY in RAM so there is no disk-activity at all while
> >playing....
> 
> not so, unless you use mlockall. you mean, completely in VM. not quite
> the same thing.

Yes, Sorry :)

<..>
> unless you mlock(all) the pages on which your soundfile lives, there
> is no reason why the CPU has to do anymore work in the mmap(2) case
> than in the "malloc(3); read (2)" case, assuming that after mmap() you
> touch every page of the mmapped-file (this makes it equivalent to the
> "read" case, since there, the reading-in touched very page of the data
> too). in both cases, a page may be paged out, and cause a page fault,
> requiring the CPU to initiate a fetch. if its not paged out, no extra
> cost either way.

Yes! Thanks.

So that means:

- Let's say I have a machine that can easily store a certain
sample-setup completely without swapping in memory (with malloc/read).
Now let's say instead of malloc/read I mmap() and "read" through the
whole file before playing the first time (to display the data). Then the
complete file will be in memory just like with malloc/read (still
assuming it fits in memory). This way there will be no disk-activity
while playing, either way, right?

- to get that more precise: The swap-out criteria for a mmap()'ed page
and a malloced()-page (not mlocked()) are the same, right?

Then I agree: mmap()ing wav-files is definitely the better way of doing
it. Thanks for makeing that clear. Still there are those other problems
that would keep me (for now!) from using the mmap-way as the default
way:
- I would have to drop sox/mpg123 (unmapable ;) which would really annoy
a lot of people. Although that could be helped by somehow including
Andy's "magic" mp3-decoding - but I have no idea how complex this would
be.
- And I have no idea wether mmap()ing files is available on other
platforms (where tX will be ported to) - this is of course just a lack
of knowledge
- The "builtin" wav-header analyzing routines are based on wavtools and
they are somewhat problematic. Or no they're not but they force you to
use 16Bit/44Khz/Mono Wav files only and that's a little bit annoying
which is why I went on an used sox... Btw could give me a link to your
libsoundfile?

Well there are solutions to all of these points I guess. We'll see.
Thanks again!

Bye, Alex
-- 
_______________________________________________________________________
                            Alexander Knig - alex@42.fht-esslingen.de
                                                  http://termX.cjb.net

[From the Homer Quotables:]
 
Twenty of the suckiest minutes of my life.

		-- Homer Simpson
		   Burns, Baby Burns

From - Tue Oct 26 22:26:34 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA04499
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 09:06:34 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA01280 for linux-audio-dev-list; Tue, 26 Oct 1999 08:34:22 -0400
Received: from gate.suse.cz (perex.cb.cesnet.cz [194.212.165.105]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA01277 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 08:34:18 -0400
Received: from localhost (perex@localhost)
	by gate.suse.cz (8.8.8/8.8.8) with ESMTP id OAA16781;
	Tue, 26 Oct 1999 14:31:06 +0200
X-Authentication-Warning: gate.suse.cz: perex owned process doing -bs
Date: Tue, 26 Oct 1999 14:31:06 +0200 (MEST)
From: Jaroslav Kysela <perex@suse.cz>
To: Paul Barton-Davis <pbd@Op.Net>
cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: Re: [linux-audio-dev] Re: streaming from disk to terminatorX added
 (via mmap) 
In-Reply-To: <199910252148.RAA16689@renoir.op.net>
Message-ID: <Pine.LNX.4.05.9910260904550.15659-100000@gate.suse.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d7f358bef69eab3a307fd8d5ec20d472

On Mon, 25 Oct 1999, Paul Barton-Davis wrote:

> In message <38151885.7A650570@42.fht-esslingen.de>you write:
> >Paul Barton-Davis wrote:
> >> just FYI: my C++ libsoundfile uses mmap(), but still requires
> >> applications to "read" the data. it is significantly faster than using
> >> read(2) internally, however, so there might be an argument for using
> >> mmap regardless of the endianness, and then using arch-dependent
> >> macros to fetch the data from the mmapped area. for example, on a
> >> little endian machine reading from a little endian RIFF/WAV file, the
> >> macros are essentially no-ops.
> >
> >No-ops? Do you mean you don't generate ANY code for this? If so: HOW?
> 
> sorry, not very accurate. for example:
> 
>        int16 foo;
>        unsigned char *p;
> 
>        foo = get_little_endian_int16 (p)
> 
> on an LE machine, this is just:
> 
>        foo = *((int16 *) p);
> 
> on a BE machine, its a bit more complex.

Not very much:

	#include <byteswap.h>

	foo = bswap_16(*((int16 *)p));

The defined macros from GLIBC already does byte swapping in the best way
for given architecture.

							Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA project  http://www.alsa-project.org


From - Tue Oct 26 22:26:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA19350
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 10:43:22 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA01495 for linux-audio-dev-list; Tue, 26 Oct 1999 10:01:32 -0400
Received: from tango.birch.net (birch.net [209.251.184.60]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA01492 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 10:01:29 -0400
Received: from dustin (host1-174.birch.net [216.212.1.174])
	by tango.birch.net  with SMTP id IAA11200
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 08:55:38 -0500 (CDT)
From: "Dustin Barlow" <dbarlow@omnids.com>
To: <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Looking for linux sound apps/ csound aps for bundling with Enoch.
Date: Tue, 26 Oct 1999 08:53:39 -0500
Message-ID: <NBBBLDPIAKJHFKEBAIAFKECCIIAA.dbarlow@omnids.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 573277543c69539c14eb10e99a0962ce

Greetings all,

I have the priviledge of heading up the audio development on a
brand new linux distribution called Enoch.  I am very excited
about Enoch and I wanted to share it with you and extend the
opportunity to anyone who wants to get involved.

Enoch is different from other linux distributions in that there
will be multiple versions that are optimized for all the various
processors.  Enoch's main goal is to remain streamlined and fast.
Daniel Robbins, the creator of Enoch, is very interested in 
making Enoch a digital audio friendly linux environment
that will have a bunch of audio applications and utilities to 
help push linux into the main stream of digital audio production. 
If you'd like more detailed information about Enoch, go to
http://enoch.masslinux.com or http://www.proteinpak.com

You are also encouraged to stop by on irc at irc.linux.com #enoch
if you have any questions.

What I am interested in is collecting from all of you applications
that you would like to have bundled in this special audio version
of Enoch.  We are planning to also include a build of csound as 
well so csound related utilities are also needed.  All these
apps will be distributed under the GNU/GPL license and the authors
will retain their full rights.

If you would be interested in being a contributor to this
project, please email me at dbarlow@omnids.com and give me a
short explaination of what applications you have written or
plan to write for the linux/X platform.  We are looking for
apps for both csound and apps that don't use csound...so 
basically if it is sound related, and for linux/X then 
let me know.

If anyone is interested in writing sound card drivers for some
of the high end cards not supported by ALSA and OSS, then contact
me as well.  

This is a great opportunity to get your application in the
face of linux of users, so please contact me if you are interested!

Thanks for the bandwidth,

Dustin Barlow
dbarlow@omnids.com

 

From - Tue Oct 26 22:26:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA25876
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 11:23:27 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA01563 for linux-audio-dev-list; Tue, 26 Oct 1999 10:38:03 -0400
Received: from bashir.belgium.eu.net (bashir.Belgium.EU.net [193.74.208.147]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA01560 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 10:38:00 -0400
Received: from (adial096.liege.eunet.be [195.207.174.96])
	by bashir.belgium.eu.net  with SMTP id QAA18590 
	for <linux-audio-dev@ginette.musique.umontreal.ca>;
	Tue, 26 Oct 1999 16:32:01 +0200 (MET DST)
Subject: Re: [linux-audio-dev] Re: streaming from disk to terminatorX added (via  mmap)
From: Benjamin GOLINVAUX <golinvaux@benjamin.net>
Reply-To: Benjamin GOLINVAUX <golinvaux@benjamin.net>
In-Reply-To: <38158C18.41C92BEC@42.fht-esslingen.de>
Message-ID: <000357c9852525d3_mailit@relay.eunet.be>
References: <199910252148.RAA16689@renoir.op.net> <38158C18.41C92BEC@42.fht-esslingen.de>
Date: Tue, 26 Oct 1999 16:26:03 +0200
X-Mailer: BeatWare Mail-It 2.0.3
X-BeOS-Platform: Intel or clone
X-Priority: 3 (Normal)
To: linux-audio-dev@ginette.musique.umontreal.ca
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 217a999418b2800e2c512c801a61ed9a


Just a general remark about any DJ style applications :

Aren't there more than forwards/backwards FX *at the contrained speed* when 
scratchin' ?

I expect the contraints on the needle may induce some second-order effects 
(since it
is maybe bending, maybe the speed curve is not linear but has an inflexion 
point when
the bending of the needle reverses).

Wonder how a sine wave looks like when scratched.

Any comments ?


Benjamin-



From - Tue Oct 26 22:26:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA03464
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 12:27:46 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA01748 for linux-audio-dev-list; Tue, 26 Oct 1999 11:41:54 -0400
Received: from shell.dhp.com (shell.dhp.com [199.245.105.1]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA01745 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 11:41:50 -0400
Received: by shell.dhp.com (Postfix, from userid 668)
	id 6B1DA1AC01; Tue, 26 Oct 1999 11:35:56 -0400 (EDT)
Date: Tue, 26 Oct 1999 11:35:56 -0400 (EDT)
From: Billy Biggs <vektor@DIV8.NET>
To: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] External MIDI Sync using OSS/Free
Message-ID: <Pine.LNX.4.04.9910261125060.21194-100000@shell.dhp.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 3391ab0db5df059e1838cb7918d626d3

Hi,

  My sequencer (http://www.div8.net/ttrk) mainly runs off of external MIDI
sync, and drives a mess of synths and stuff.  I use /dev/sequencer for
MIDI input and output.

  Since I'm both reading incomming MIDI, and sending outgoing MIDI, and
since I like to change the tempo on the fly, I have to do annoying
predictions in order to stay in sync.  Blech.

  Anyways, one thing I've found is that the /dev/sequencer clock is
different for incomming and outgoing.  So, in order to do a prediction a
few ticks ahead, I can't just add to the incomming time and blast out
messages.  As well, the outgoing clock seems difficult to predict.

  This is really annoying for song starts.  Every time I get a song start,
I call SNDCTL_SEQ_GETTIME, and take the difference between it and the
timecode on the start message.  I then apply that difference to every
outgoing packet.

  Is there a way that I could do this more efficiently?  Since my app
might not get swapped in until late after the start arrived, and then I
have to call the ioctl.  This error then remains for the entire duration
of the song.

  Any advice?
--
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

From - Tue Oct 26 22:26:44 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA03389
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 13:53:06 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA02409 for linux-audio-dev-list; Tue, 26 Oct 1999 13:16:15 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA02406 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 13:16:11 -0400
From: est@hyperreal.org
Received: (qmail 14381 invoked by uid 162); 26 Oct 1999 17:10:05 -0000
Message-ID: <19991026171005.14380.qmail@hyperreal.org>
Subject: [linux-audio-dev] mmap()/mlockall()/read()
In-Reply-To: <99102515163701.00665@localhost.localdomain> from Benno Senoner
 at "Oct 25, 1999 02:58:29 pm"
To: Benno Senoner <sbenno@gardena.net>
Date: Tue, 26 Oct 1999 10:10:05 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 7c4acb2e4d569bf8d3f70ada4e412121

Benno Senoner discourseth:
> 
> Eric,
> when not mlock()-ing the entire process (or at least the RT relevant data),
> you have no chance to give ANY guarantee thet some pages could
> not be swapped out.

That's exactly my concern..I have no guarantees that I won't run into
N page-faults in a given period and miss my deadlines.  Unfortunately,
locking and mapping aren't that flexible.  I need to use
mlockall(MCL_CURRENT | MCL_FUTURE) to make sure I have no page faults.
Then anything I mmap() will be initially locked as well..even though
it may be larger than my RAM.  A MAP_UNLOCKED option to mmap() would
be a non-portable solution.

> What I'm trying to say: read() doesn't work better than mmap() in terms of
> behaviour during swapping, because the kernel could easily swap out
> your buffer where you read() in the data.

Actually, the last time I tested this extensively (with a 2.0.x kernel
I think), mmap() was much better performing than read()..for a while.
When sequential accessing of a file got to a point around my RAM
limits, the disk activity became insane.  Maybe things are better now.

> I will add a feature to the pagefaulter thread which uses mlock()/munlock if
> root privileges are available, so that even
> Eric is satisfied.
> :-)

Eric is hard to satisfy. :)

> PS: mlockall(MCL_CURRENT|MCL_FUTURE) is a bad idea because when you do the
> mmap() of the large file the process tries to load all into mem,and my scheme
> would not work. Better to use mlockall(MCL_CURRENT) and mlock()/munlock()
> areas on demand.

This is a useful solution in some circumstances.  However, it means I
can't use malloc()/new, may have trouble with shared libraries or
dynamically loaded plugins and have to worry about reserving stack
space.  It's not the way I want to work.

Eric

From - Tue Oct 26 22:26:49 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA04751
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 14:02:45 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA02433 for linux-audio-dev-list; Tue, 26 Oct 1999 13:26:29 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA02430 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 13:26:24 -0400
From: est@hyperreal.org
Received: (qmail 20740 invoked by uid 162); 26 Oct 1999 17:20:29 -0000
Message-ID: <19991026172029.20739.qmail@hyperreal.org>
Subject: [linux-audio-dev] mp3 seeking
In-Reply-To: <Pine.LNX.4.05.9910260908140.24753-100000@alsa.alsa-project.org>
 from Andy Lo A Foe at "Oct 26, 1999 09:50:37 am"
To: Andy Lo A Foe <andy@alsa-project.org>
Date: Tue, 26 Oct 1999 10:20:29 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: a398f67fa08a7bd05ba0816d9d2f822c

Andy Lo A Foe discourseth:
> A segment holds a number of decoded frames (usually 2 or 3) and also
> remembers the number of the first frame. So lets say we want to play 
> a mp3 backwards starting at frame 1000. The tricky part is to keep the
> ringbuffer full with the right frames all the time. As soon as one segment
> is used up by the audio reader thread it releases a semaphore on which the
> audio decoder thread is blocking on. The audio decoder thread wakes up and
> check if there are any segments that needs to be filled. But wait you say,
> what if you need to fill a segment with frames 1000 to 998? Decoding frame
> 1000, then 999 and then 998 won't work because of the way mp3s are
> encoded. What do you do then? You seek to frame 995 and start decoding
> from there. You throw all data away up to and including frame 997. By this
> time your mp3 decoding engine is recovered from the 'seek' operation.

Andy,

First, I must thank you for alsaplayer since I'm using an adaptation
of your adaptation of the mpg123 code in the next major release of
oolaboola.  I'm encapsulating it in a separate process (called
mp3serv) to get re-entrancy.  I may move to the xing decoder but the
process interface will remain the same.

Now to the question of seeking. :)

My understanding was that it *may* take more than 3 frames of priming
to resynchronize.  One of the xing/freemap people got me the logic but
I haven't implemented it yet.

Another issue is how to find a given frame in the first place.  Given
that each frame may have an extra byte of padding, a multiplication is
(audibly!) unreliable.  I've implemented a table-of-contents mechanism
to deal with this.

Best,

Eric

From - Tue Oct 26 22:26:42 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA02474
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 13:46:41 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA02356 for linux-audio-dev-list; Tue, 26 Oct 1999 12:58:27 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA02353 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 12:58:24 -0400
Received: from someip.ppp.op.net (d-bm2-1d.ppp.op.net [209.152.194.61]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id MAA03645; Tue, 26 Oct 1999 12:52:29 -0400 (EDT)
Message-Id: <199910261652.MAA03645@renoir.op.net>
To: Billy Biggs <vektor@DIV8.NET>
cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: Re: [linux-audio-dev] External MIDI Sync using OSS/Free 
In-reply-to: Your message of "Tue, 26 Oct 1999 11:35:56 EDT."
             <Pine.LNX.4.04.9910261125060.21194-100000@shell.dhp.com> 
Date: Tue, 26 Oct 1999 13:47:59 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b913e6493251713f1ec759177994ef1c

>  My sequencer (http://www.div8.net/ttrk) mainly runs off of external MIDI
>sync, and drives a mess of synths and stuff.  I use /dev/sequencer for
>MIDI input and output.

advice #1: do not use /dev/sequencer

two reasons. it doesn't exist in ALSA, which will (soon-ish) be the
default sound driver system for Linux. but more importantly, its a
horrible system. i won't list the problems with it here, but there are
many. 

instead, just let the user specify the MIDI device files to use, and
then use them as "raw" read(2)/write(2) files. this works with OSS,
ALSA, Solaris and a number of other systems. then do most of your
timing stuff at user level. i don't know what your resolution needs to
be, but my "analog MIDI sequencer" program SoftWerk does all its
timing in user space (it has too - it doesn't know what to send to the
MIDI interface until its actually time to send it) and is accurate
down to about 20ms without any special priviledges. it can get a lot
more accurate than that if it needs to. OTOH, SoftWerk is an "old
school" sequencer, from back before the days of the first digital
sequencers. it has a fixed number of event steps per fixed number of
event steps, which is not what most people these days mean by "sequencer".

advice #2: if you really have external MIDI sync (do you mean MIDI clock,
or other stuff ?), then just use that to provide timing for your
application. if you have sensible hardware for your MIDI interface,
then your application will be woken up very rapidly (at least if it
runs SCHED_FIFO) after the MIDI clock byte (or any other MIDI message)
is ready to read.

if you don't have external clock, then you'd be better off using the
real time clock for timing. 

advice 3: install ALSA, and use the ALSA sequencer. its a vastly more
evolved kernel sequencer system, though its still going through some
beta-testing. we would welcome your involvement in that process.

>  Is there a way that I could do this more efficiently?  Since my app
>might not get swapped in until late after the start arrived, and then I
>have to call the ioctl.  This error then remains for the entire duration
>of the song.

use SCHED_FIFO if you can. the only downside is that it does require
that either your program, or a "helper/starter" program run setuid
root. this will reduce to the delay between your program being "ready
to run because MIDI data is available" and "running" to a virtually
insignificant time.

--p

From - Tue Oct 26 22:26:47 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA04558
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 14:01:23 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA02420 for linux-audio-dev-list; Tue, 26 Oct 1999 13:22:49 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA02417 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 13:22:47 -0400
Received: from someip.ppp.op.net (d-bm2-1d.ppp.op.net [209.152.194.61]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id NAA05993; Tue, 26 Oct 1999 13:16:47 -0400 (EDT)
Message-Id: <199910261716.NAA05993@renoir.op.net>
To: "Dustin Barlow" <dbarlow@omnids.com>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Looking for linux sound apps/ csound aps for bundling with Enoch. 
In-reply-to: Your message of "Tue, 26 Oct 1999 08:53:39 CDT."
             <NBBBLDPIAKJHFKEBAIAFKECCIIAA.dbarlow@omnids.com> 
Date: Tue, 26 Oct 1999 14:12:18 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0923a07a33e9eca63125e5a45960ea6f

>What I am interested in is collecting from all of you applications
>that you would like to have bundled in this special audio version
>of Enoch.  We are planning to also include a build of csound as 
>well so csound related utilities are also needed.  All these
>apps will be distributed under the GNU/GPL license and the authors
>will retain their full rights.

just a small legal note: you can't distribute csound under this
license, since it was never released under this license. csound is not
GPL'ed. 

--p


From - Tue Oct 26 22:26:52 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA21827
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 15:56:47 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA02585 for linux-audio-dev-list; Tue, 26 Oct 1999 14:55:45 -0400
Received: from shell.dhp.com (shell.dhp.com [199.245.105.1]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA02582 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 14:55:42 -0400
Received: by shell.dhp.com (Postfix, from userid 668)
	id 9798B1ABFE; Tue, 26 Oct 1999 14:49:44 -0400 (EDT)
Date: Tue, 26 Oct 1999 14:49:44 -0400 (EDT)
From: Billy Biggs <vektor@DIV8.NET>
To: Paul Barton-Davis <pbd@Op.Net>
Cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: Re: [linux-audio-dev] External MIDI Sync using OSS/Free 
In-Reply-To: <199910261652.MAA03645@renoir.op.net>
Message-ID: <Pine.LNX.4.04.9910261432040.26913-100000@shell.dhp.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 89e6a1ffeba8ac64f73d66bdcc47882b

On Tue, 26 Oct 1999, Paul Barton-Davis wrote:

> advice #1: do not use /dev/sequencer
[ solution, use /dev/midi* ]

  This is pretty useless IMHO.  My sequencer started off writing out
/dev/midi, and it was consistently off-sync.  Badly off sync.  Up to half
a second off sync.  I don't know if you have a significantly better box
than I do, but mine just puked.

  Oh yeah, and I got flamed real bad by diz. :)

  Trying to up the priority on the process helped significantly, but a
simple switch to /dev/sequencer let my app stay usermode and still be
reasonably responsive.

  I wish there were a better way to sync audio though, specifically sync
of audio to MIDI.  /dev/dsp has a crappy interface to this.  Does ALSA
provide any reasonable mechanism of syncing different inferfaces?

  In OSS, the clock between outgoing and incomming MIDI aren't the same.
In ALSA, I'd hope that would be fixed.  Does audio and sequencer also have
the same clock?

  What about syncing multiple soundcards?  I've found this to be next to
impossible under thud using OSS.

> advice 3: install ALSA, and use the ALSA sequencer. its a vastly more
> evolved kernel sequencer system, though its still going through some
> beta-testing. we would welcome your involvement in that process.

  I know that I should definitely look into this.  Promise I will.
Honest.

--
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

From - Tue Oct 26 22:26:53 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA25563
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 16:22:23 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA02642 for linux-audio-dev-list; Tue, 26 Oct 1999 15:11:15 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA02639 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 15:11:12 -0400
Received: from someip.ppp.op.net (d-bm2-1d.ppp.op.net [209.152.194.61]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id PAA17355; Tue, 26 Oct 1999 15:05:07 -0400 (EDT)
Message-Id: <199910261905.PAA17355@renoir.op.net>
To: Billy Biggs <vektor@DIV8.NET>
cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: Re: [linux-audio-dev] External MIDI Sync using OSS/Free 
In-reply-to: Your message of "Tue, 26 Oct 1999 14:49:44 EDT."
             <Pine.LNX.4.04.9910261432040.26913-100000@shell.dhp.com> 
Date: Tue, 26 Oct 1999 16:00:38 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f7a75a56598b178cead686b86b8b8363

>> advice #1: do not use /dev/sequencer
>[ solution, use /dev/midi* ]
>
>  This is pretty useless IMHO.  My sequencer started off writing out
>/dev/midi, and it was consistently off-sync.  Badly off sync.  Up to half
>a second off sync.  I don't know if you have a significantly better box
>than I do, but mine just puked.

did you open it O_NONBLOCK, and which kernel were you using ? support
for O_NONBLOCK was added (by me) somewhere during the 2.1 development
series. if you tried /dev/midi on 2.0 or earlier, you'll find it works
a *lot* better under 2.2.

previously, the driver would block until there were 32 bytes of data
to read. this is a disaster! if you use select(2) and open
(...O_NONBLOCK...)  i think you'll find you stay totally in sync.

this used to be a standard problem with /dev/midi, which was one
of the reasons I fixed it :)

>  I wish there were a better way to sync audio though, specifically sync
>of audio to MIDI.  /dev/dsp has a crappy interface to this.  Does ALSA
>provide any reasonable mechanism of syncing different inferfaces?

well, it has a more evolved timer interface, but its not clear that
anyone has tried using it for anything real. 

personally, most of my current applications are so phase-locked to a
soundcard DAC that i can get "perfect" sync timing from that. some
applications (and MIDI-only sequencers are a very good example of
them) are not like this, however, since they do no audio output :)

>  In OSS, the clock between outgoing and incomming MIDI aren't the same.
>In ALSA, I'd hope that would be fixed.  Does audio and sequencer also have
>the same clock?

i don't know the answer to either of these questions. jaroslav reads
linux-audio-dev, so he may be able to help you.

>  What about syncing multiple soundcards?  I've found this to be next to
>impossible under thud using OSS.

as has been discussed here a number of times, this is far from
trivial. clock rates from card to card, even the same brand, and even
from (warm) day to (cold) day vary, so its not just a matter of
finding a way to get them to all start at the same time. 

in addition, you *cannot* simultaneously issue a command to every card
to start playing/recording, so unless the soundcard h/w supports a
"start when first sample > XXX is seen" command (not many do), you can
*never* get them truly synchronized. ALSA does let you get pretty
close though. I think that Benno or someone else did some tests of
this.

From - Tue Oct 26 22:27:01 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA01490
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 17:15:00 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA02756 for linux-audio-dev-list; Tue, 26 Oct 1999 16:16:51 -0400
Received: from gauss.deltav.hu (gauss.deltav.hu [194.9.64.225]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA02753 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 16:16:48 -0400
Received: from boksi (70.dial02.deltav.hu [194.9.64.70]) by gauss.deltav.hu
          (Netscape Messaging Server 3.6)  with ESMTP id AAA5F51
          for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Tue, 26 Oct 1999 22:14:29 +0200
Received: from reactor by boksi with local (Exim 1.92 #1 (Debian))
	id 11gD2Q-00003J-00; Tue, 26 Oct 1999 22:17:46 +0200
Message-ID: <19991026221746.A167@boksi>
Date: Tue, 26 Oct 1999 22:17:46 +0200
From: reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: streaming from disk to terminatorX added (via  mmap)
Reply-To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
References: <199910252148.RAA16689@renoir.op.net> <38158C18.41C92BEC@42.fht-esslingen.de> <000357c9852525d3_mailit@relay.eunet.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91.2
In-Reply-To: <000357c9852525d3_mailit@relay.eunet.be>; from Benjamin GOLINVAUX on Tue, Oct 26, 1999 at 04:26:03PM +0200
Organization: CTP media laboratories
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 57cdaa1d60aba04e15679fcb3aa9511c

 % Benjamin wrote % 

 >% Wonder how a sine wave looks like when scratched.

nice :)

i have a Johnny Cash record, which has 2 seconds of sinewave in the
middle of a song, because Johnny said "bad" words :)

anyway, what do you expect to see?
it should be just a sinewave with changing frequency.
i can send you a sample, if you're interested.

-- 

(reactor/CTPmedia) (http://linux.gyakg.u-szeged.hu/~reactor/index.html)
(linux audiowarez) (http://www.bright.net/~dlphilp/linuxsound/toc.html)

From - Tue Oct 26 22:27:08 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA09922
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 18:09:32 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA02858 for linux-audio-dev-list; Tue, 26 Oct 1999 17:13:59 -0400
Received: from bashir.belgium.eu.net (bashir.Belgium.EU.net [193.74.208.147]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA02855 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 17:13:56 -0400
Received: from (adial134.liege.eunet.be [195.207.174.134])
	by bashir.belgium.eu.net  with SMTP id XAA02155 
	for <linux-audio-dev@ginette.musique.umontreal.ca>;
	Tue, 26 Oct 1999 23:08:04 +0200 (MET DST)
Subject: Re: [linux-audio-dev] Re: streaming from disk to terminatorX added (via  mmap)
From: Benjamin GOLINVAUX <golinvaux@benjamin.net>
Reply-To: Benjamin GOLINVAUX <golinvaux@benjamin.net>
In-Reply-To: <19991026221746.A167@boksi>
Message-ID: <000357cf0e542c53_mailit@relay.eunet.be>
References: <199910252148.RAA16689@renoir.op.net> <38158C18.41C92BEC@42.fht-esslingen.de> <000357c9852525d3_mailit@relay.eunet.be> <19991026221746.A167@boksi>
Date: Tue, 26 Oct 1999 23:02:20 +0200
X-Mailer: BeatWare Mail-It 2.0.3
X-BeOS-Platform: Intel or clone
X-Priority: 3 (Normal)
To: linux-audio-dev@ginette.musique.umontreal.ca
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: af3281826bca41203250b46ab7bad5c7

>anyway, what do you expect to see?
>it should be just a sinewave with changing frequency.
>i can send you a sample, if you're interested.

I expect to see a sinewave with changing frequency + side effects
from the needle.

Furthermore, the derivate of the frequency vs time is probably not 
always proportional to the speed of the disk surface wrt to the turntable
(in a more formal way).

Benjamin



From - Tue Oct 26 22:27:05 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA09651
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 18:07:33 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA02846 for linux-audio-dev-list; Tue, 26 Oct 1999 17:11:14 -0400
Received: from hme0.smtp04.sprint.ca (hme0.smtp04.sprint.ca [207.107.250.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA02843 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 17:11:11 -0400
Received: from vektor.div8.net (root@spc-isp-ktc-uas-07-69.sprint.ca [209.148.133.16])
	by hme0.smtp04.sprint.ca (8.8.8/8.8.8) with ESMTP id RAA09950;
	Tue, 26 Oct 1999 17:05:04 -0400 (EDT)
Received: from localhost by div8.net
	via sendmail with smtp
	id <m11gDn7-00092gC@vektor.div8.net> (Debian Smail3.2.0.102)
	for <pbd@Op.Net>; Tue, 26 Oct 1999 17:06:01 -0400 (EDT) 
Date: Tue, 26 Oct 1999 17:06:01 -0400 (EDT)
From: Billy Biggs <vektor@DIV8.NET>
To: Paul Barton-Davis <pbd@Op.Net>
cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Sync Issues (was Re: External MIDI Sync using OSS/Free)
In-Reply-To: <199910261905.PAA17355@renoir.op.net>
Message-ID: <Pine.LNX.3.96.991026165644.6242A-100000@vektor.div8.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: c37cc9e5650fc28be492e118e846c07e

On Tue, 26 Oct 1999, Paul Barton-Davis wrote:

> >> advice #1: do not use /dev/sequencer, solution, use /dev/midi*
> >
> >  This is pretty useless IMHO.  My sequencer started off writing out
> >/dev/midi, and it was consistently off-sync.  Badly off sync.
> 
> did you open it O_NONBLOCK, and which kernel were you using ?

  I was using O_RDWR | O_NONBLOCK, under a 2.2 kernel.  I was trying to do
drumrolls, 16th notes, at 140bpm or 150bpm.  It was no good.

  Well, I recorded some songs using it, but I had to avoid playing too
many notes in rapid succession on any one track, and damned if I trigger
drums with it.

> personally, most of my current applications are so phase-locked to a
> soundcard DAC that i can get "perfect" sync timing from that. some
> applications (and MIDI-only sequencers are a very good example of
> them) are not like this, however, since they do no audio output :)

  One requirement for ttrk was that it be able to trigger samples on beat,
in sync with incomming MIDI.  This is a pain in the ass, since I have to
know exactly where in the audio output I am in order to do the prediction
correctly.  The clock on (at least the OSS) /dev/dsp is no good, since it
gives you no indication of when underruns occur.

  Damn annoying.

  I currently have ttrk setup to just 'turn on' the sample as soon as it
sees the corresponding MIDI sync tick.  It's no good for drum samples or
loops or anything, but I can trigger cheezy sci-fi samples and they don't
sound _too_ out of place.  Ugh.

> >  What about syncing multiple soundcards?  I've found this to be next to
> >impossible under thud using OSS.
> 
> as has been discussed here a number of times, this is far from
> trivial. clock rates from card to card, even the same brand, and even
> from (warm) day to (cold) day vary, so its not just a matter of
> finding a way to get them to all start at the same time. 

  Yes, it is a pain, but there should be a better hacked job at least of
doing it.  When I still had Windows around, Sonic Foundry ACID had no
trouble at least faking some sync between my two AudioPCI cards.  I can't
get it as good as they did. :/

  There should also be API support for it.  I hope to soon (within the
next year) get a soundcard that has multiple dsps inside it, for
outputting multi-track stuff.  I'm really worried about how much I'm going
to have to code myself though.....

--
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

From - Tue Oct 26 22:27:03 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA09510
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 18:06:21 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA02853 for linux-audio-dev-list; Tue, 26 Oct 1999 17:13:24 -0400
Received: from gate.suse.cz (perex.cb.cesnet.cz [194.212.165.105]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA02850 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 17:13:21 -0400
Received: from localhost (perex@localhost)
	by gate.suse.cz (8.8.8/8.8.8) with ESMTP id XAA18634;
	Tue, 26 Oct 1999 23:10:23 +0200
X-Authentication-Warning: gate.suse.cz: perex owned process doing -bs
Date: Tue, 26 Oct 1999 23:10:22 +0200 (MEST)
From: Jaroslav Kysela <perex@suse.cz>
To: Billy Biggs <vektor@DIV8.NET>
cc: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca,
        linux-sound@vger.rutgers.edu
Subject: Re: [linux-audio-dev] External MIDI Sync using OSS/Free 
In-Reply-To: <Pine.LNX.4.04.9910261432040.26913-100000@shell.dhp.com>
Message-ID: <Pine.LNX.4.05.9910262308580.18562-100000@gate.suse.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: dd662ed3666a935c221797630031a11c

On Tue, 26 Oct 1999, Billy Biggs wrote:

>   I wish there were a better way to sync audio though, specifically sync
> of audio to MIDI.  /dev/dsp has a crappy interface to this.  Does ALSA
> provide any reasonable mechanism of syncing different inferfaces?
> 
>   In OSS, the clock between outgoing and incomming MIDI aren't the same.
> In ALSA, I'd hope that would be fixed.  Does audio and sequencer also have
> the same clock?

Yes, if you choose the PCM device as the timer source.

>   What about syncing multiple soundcards?  I've found this to be next to
> impossible under thud using OSS.

No probs.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA project  http://www.alsa-project.org

From - Tue Oct 26 22:27:11 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA11563
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 18:19:28 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA02878 for linux-audio-dev-list; Tue, 26 Oct 1999 17:21:11 -0400
Received: from gate.suse.cz (perex.cb.cesnet.cz [194.212.165.105]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA02875 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 17:21:07 -0400
Received: from localhost (perex@localhost)
	by gate.suse.cz (8.8.8/8.8.8) with ESMTP id XAA18672;
	Tue, 26 Oct 1999 23:18:17 +0200
X-Authentication-Warning: gate.suse.cz: perex owned process doing -bs
Date: Tue, 26 Oct 1999 23:18:17 +0200 (MEST)
From: Jaroslav Kysela <perex@suse.cz>
To: Billy Biggs <vektor@DIV8.NET>
cc: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca,
        linux-sound@vger.rutgers.edu
Subject: Re: [linux-audio-dev] External MIDI Sync using OSS/Free 
In-Reply-To: <Pine.LNX.4.05.9910262308580.18562-100000@gate.suse.cz>
Message-ID: <Pine.LNX.4.05.9910262314020.18562-100000@gate.suse.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 506021da4098fc3aab169f8019411544

On Tue, 26 Oct 1999, Jaroslav Kysela wrote:

> >   What about syncing multiple soundcards?  I've found this to be next to
> > impossible under thud using OSS.
> 
> No probs.

Oops. Before I receive some flames, the correction is here:

There are problems with different clock sources for the chips on multiple
soundcards. ALSA driver currently doesn't support multiple soundcards
which can be synced together. The new PCM API covers this possibility,
but the driver for some hardware, which supports this feature, has not
been written yet.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA project  http://www.alsa-project.org

From - Tue Oct 26 22:27:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA21261
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 19:22:39 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA02974 for linux-audio-dev-list; Tue, 26 Oct 1999 18:24:03 -0400
Received: from chekov.Belgium.EU.net (chekov.belgium.eu.net [193.74.208.161]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA02971 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 18:24:00 -0400
Received: from (adial134.liege.eunet.be [195.207.174.134])
	by chekov.Belgium.EU.net  with SMTP id AAA20570 
	for <linux-audio-dev@ginette.musique.umontreal.ca>;
	Wed, 27 Oct 1999 00:18:06 +0200 (MET DST)
Subject: Re: [linux-audio-dev] Re: streaming from disk to terminatorX added (via  mmap)
From: Benjamin GOLINVAUX <golinvaux@benjamin.net>
Reply-To: Benjamin GOLINVAUX <golinvaux@benjamin.net>
In-Reply-To: <19991026221746.A167@boksi>
Message-ID: <000357cf544df31f_mailit@relay.eunet.be>
References: <199910252148.RAA16689@renoir.op.net> <38158C18.41C92BEC@42.fht-esslingen.de> <000357c9852525d3_mailit@relay.eunet.be> <19991026221746.A167@boksi>
Date: Tue, 26 Oct 1999 23:21:54 +0200
X-Mailer: BeatWare Mail-It 2.0.3
X-BeOS-Platform: Intel or clone
X-Priority: 3 (Normal)
To: linux-audio-dev@ginette.musique.umontreal.ca
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 9f4260d784e9789b9807ed6994299ce8

Scratching a compact disc player (if possible) would probably lead
to slow (wrt audio period) frequency change, i.e. at the speed of 
the hand.

But since I tried to manually build a "scratched" sample some time ago and 
found it 
did not sound like the real thing, I assumed there were probably some weird 
effects.

Maybe it is the same phenomenon as the bow on violin strings : we hear a 
distinctive
sound whose excitation is the friction between bow and string. As the needle 
does not
'glide' perfectly on the disc as a laser beam, maybe there is some kind of 
added
"needle violin" sound added to the variations on the disc surface.

A useful experiment might be to find some seconds of silence, then "scratch 
the silence"
and try to devise a method to dynamically generate this sound (which is not 
silence,
 is it ?) and add the resulting signal to regular scratched sample.

Strong hypothesis of linearity, but it could be nice (especiallly if the x 
axis of mouse 
could vary the ratio "direct signal"/"scratched silence".

Just blind guesses.



Benjamin


From - Tue Oct 26 22:27:22 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA31113
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 20:28:47 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA03044 for linux-audio-dev-list; Tue, 26 Oct 1999 19:26:05 -0400
Received: from hme0.smtp04.sprint.ca (hme0.smtp04.sprint.ca [207.107.250.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA03041 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 19:26:03 -0400
Received: from vektor.div8.net (root@spc-isp-ktc-uas-8-30.sprint.ca [209.148.133.81])
	by hme0.smtp04.sprint.ca (8.8.8/8.8.8) with ESMTP id TAA14548;
	Tue, 26 Oct 1999 19:20:08 -0400 (EDT)
Received: from localhost by div8.net
	via sendmail with smtp
	id <m11gFtw-00092gC@vektor.div8.net> (Debian Smail3.2.0.102)
	for <pbd@Op.Net>; Tue, 26 Oct 1999 19:21:12 -0400 (EDT) 
Date: Tue, 26 Oct 1999 19:21:12 -0400 (EDT)
From: Billy Biggs <vektor@DIV8.NET>
To: Paul Barton-Davis <pbd@Op.Net>
cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: Sync Issues (was Re: External MIDI Sync using OSS/Free) 
In-Reply-To: <199910262252.SAA09996@renoir.op.net>
Message-ID: <Pine.LNX.3.96.991026191131.6810A-100000@vektor.div8.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: ccb51fc6145409bfa7dde24d7439304f

On Tue, 26 Oct 1999, Paul Barton-Davis wrote:

> >  I was using O_RDWR | O_NONBLOCK, under a 2.2 kernel.  I was trying to do
> >drumrolls, 16th notes, at 140bpm or 150bpm.  It was no good.
> 
> hmm. i should try some stuff like this myself, but i haven't written
> an audio sequencer yet :)

  I'm sorry, you have me confused.  This was using /dev/midi, only
outputting MIDI notes.

> let me just clarify one thing: so ttrk is an audio+MIDI sequencer ? it
> does output audio as well as MIDI (or just audio ?)

  ttrk is currently only useful as a MIDI sequencer, but it happily opens
all audio devices available and will attempt to play samples on beat.

>      * soundcard has N fragments "queued" in its hardware buffer by 
>        the driver
>      * you're about to assemble the audio data for the next fragment
>      * you check for MIDI data
>      * MIDI data is here - you decide to include sample X in the next
>        fragment (and future ones too, most likely, since most samples
>        last longer than the fragment size).
> 
> where is the timing problem ? i am sure i am missing something, given
> that my MIDI related work has been almost entirely MIDI-only.

  Here's one algorithm I tried to use for a while, you'll see the problem:

   - There are N fragments "queued" by the hardware buffer in the
     soundcard
   - I check to see if i'm at the start of a new beat, if I am then
     - If there are samples to play, start playing them in this fragment
     - If there are MIDI notes to play, queue them to be played at
       time per fragment * N in the future

  The sync problem comes from not getting swapped in enough such that
you'll send out the MIDI data at the instant that the audio out the
soundcard actually gets played.

  This all gets worse once you have to know more about the audio buffer
location, for example, when you're trying to sync to an external MIDI
source, and already have alot of error due to your estimates about the
external sync's tempo and your predicted next beat.

  These days, I'm using three threads.  One for midi, one for audio, and
one for the GUI.

> >  There should also be API support for it.  I hope to soon (within the
> >next year) get a soundcard that has multiple dsps inside it, for
> 
> do you really mean DSP's ? the only cards I know like this are things
> like the Creamware Pulsar and SCOPE, and the Yamaha DSP Factory. Linux
> support for these is not likely to be forthcoming (though I may write
> the drivers for Creamware).

  Drivers had better be forthcomming.  Yes, I'm talking about cards like
those, such as the Event Layla and Darla, etc.  Without them, it makes
Linux pretty useless as a multitrack platform...

  Well, at least pretty annoying.  Personally, I have two AudioPCI cards
and a dedicated MPU-401 card for MIDI.  Each of the AudioPCI cards have
two dsps, giving me four /dev/dsp devices.

--
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

From - Tue Oct 26 22:27:20 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA25924
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 19:53:36 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA03001 for linux-audio-dev-list; Tue, 26 Oct 1999 18:58:26 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA02998 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 18:58:23 -0400
Received: from someip.ppp.op.net (d-bm2-12.ppp.op.net [209.152.194.50]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id SAA09996; Tue, 26 Oct 1999 18:52:27 -0400 (EDT)
Message-Id: <199910262252.SAA09996@renoir.op.net>
To: Billy Biggs <vektor@DIV8.NET>
cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: Re: [linux-audio-dev] Sync Issues (was Re: External MIDI Sync using OSS/Free) 
In-reply-to: Your message of "Tue, 26 Oct 1999 17:06:01 EDT."
             <Pine.LNX.3.96.991026165644.6242A-100000@vektor.div8.net> 
Date: Tue, 26 Oct 1999 19:48:02 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: fddccb88fc3bb04718bfbb8612f0ce3c

>  I was using O_RDWR | O_NONBLOCK, under a 2.2 kernel.  I was trying to do

good start ...

>drumrolls, 16th notes, at 140bpm or 150bpm.  It was no good.

hmm. i should try some stuff like this myself, but i haven't written
an audio sequencer yet :)

let me just clarify one thing: so ttrk is an audio+MIDI sequencer ? it
does output audio as well as MIDI (or just audio ?)

>  One requirement for ttrk was that it be able to trigger samples on beat,
>in sync with incomming MIDI.  This is a pain in the ass, since I have to
>know exactly where in the audio output I am in order to do the prediction
>correctly.  The clock on (at least the OSS) /dev/dsp is no good, since it
>gives you no indication of when underruns occur.

assuming you've got the buffering set up right, you shouldn't have any
underruns, and if you do, then you're already in deep water. surely
your situation is just:

     * soundcard has N fragments "queued" in its hardware buffer by 
       the driver
     * you're about to assemble the audio data for the next fragment
     * you check for MIDI data
     * MIDI data is here - you decide to include sample X in the next
       fragment (and future ones too, most likely, since most samples
       last longer than the fragment size).

where is the timing problem ? i am sure i am missing something, given
that my MIDI related work has been almost entirely MIDI-only.

>  Yes, it is a pain, but there should be a better hacked job at least of
>doing it.  When I still had Windows around, Sonic Foundry ACID had no
>trouble at least faking some sync between my two AudioPCI cards.  I can't
>get it as good as they did. :/

ALSA will do a good job. don't know if its "as good".

>  There should also be API support for it.  I hope to soon (within the
>next year) get a soundcard that has multiple dsps inside it, for

do you really mean DSP's ? the only cards I know like this are things
like the Creamware Pulsar and SCOPE, and the Yamaha DSP Factory. Linux
support for these is not likely to be forthcoming (though I may write
the drivers for Creamware).

>outputting multi-track stuff.  I'm really worried about how much I'm going
>to have to code myself though.....

something like the Trident 4D-NX cards under ALSA support this pretty
transparently, since the card does hardware mixing of up to 16 (or 32,
can't recall) audio streams, and ALSA supports multiple open calls -
it just assigns each successive open a new channel on the 4D-NX. the
card costs $39+postage, and ALSA costs nothing :)

--p

From - Tue Oct 26 22:27:25 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA06732
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 21:21:07 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA03144 for linux-audio-dev-list; Tue, 26 Oct 1999 20:25:24 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id UAA03141 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 20:25:22 -0400
From: est@hyperreal.org
Received: (qmail 26464 invoked by uid 162); 27 Oct 1999 00:19:30 -0000
Message-ID: <19991027001930.26463.qmail@hyperreal.org>
Subject: [linux-audio-dev] pci128 line-in help
To: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Date: Tue, 26 Oct 1999 17:19:30 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 67f048b587936afc0e904059e679b1cf

I can't seem to get my pci128 line-in to work.  This is using the
(es1370) OSS driver distributed with the 2.2.7 kernel.  I've tried all
the obvious mixer settings as well as all the private ioctl()s the
driver has, checked my hardware, etc.  Can anyone think of anything I
might be missing?

Thanks,

Eric

From - Tue Oct 26 22:27:27 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA13681
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 22:06:19 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA03205 for linux-audio-dev-list; Tue, 26 Oct 1999 21:04:49 -0400
Received: from charon.host4u.net (charon.host4u.net [209.150.128.172]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA03202 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 21:04:46 -0400
Received: from spiritship.localdomain (1Cust119.tnt1.fort-collins.co.da.uu.net [63.14.29.119])
	by charon.host4u.net (8.8.5/8.8.5) with SMTP id TAA06976;
	Tue, 26 Oct 1999 19:58:41 -0500
From: llornkcor <llornkcor@llornkcor.com>
Organization: llornkcor rocknroll
To: est@hyperreal.org, linux-audio-dev@ginette.musique.umontreal.ca,
        linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: pci128 line-in help
Date: Tue, 26 Oct 1999 18:50:23 -0600
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <19991027001930.26463.qmail@hyperreal.org>
In-Reply-To: <19991027001930.26463.qmail@hyperreal.org>
MIME-Version: 1.0
Message-Id: <99102618585501.00779@spiritship.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 4628c4d8bbe303ed30893eca4ca1ab28

I have a pci 128, and the mic input is the default, so you'll have to make sure
to select the line input using a mixer. If you've already done that, try
looking at /dev/dsp, or /dev/dsp1. If you are trying to listen to something and
record at the same time (full-duplex) the OSS driver that comes with the kernel
doesn't support it. So, if the line out is open, it won't record anything.
Sometimes, some sound apps don't close /dev/dsp correctly.Try ALSA or the
commercial OSS driver from 4front. 

On Tue, 26 Oct 1999, est@hyperreal.org wrote:
> I can't seem to get my pci128 line-in to work.  This is using the
> (es1370) OSS driver distributed with the 2.2.7 kernel.  I've tried all
> the obvious mixer settings as well as all the private ioctl()s the
> driver has, checked my hardware, etc.  Can anyone think of anything I
> might be missing?
> 
> Thanks,
> 
> Eric
-- 
"When the doors of perception are cleansed everything appears as it truly is - infinite."   - William Blake 

llornkcor rocknroll 
SpiritShip MultiMedia Recording Studio
http://www.llornkcor.com

From - Tue Oct 26 22:26:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA31762
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 17:01:59 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA02740 for linux-audio-dev-list; Tue, 26 Oct 1999 16:05:25 -0400
Received: from rhhx01.fht-esslingen.de (rhhx01.fht-esslingen.de [134.108.56.1]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA02721 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 16:04:01 -0400
Received: from firewall.dc.com (rsra77.fht-esslingen.de [134.108.128.77])
	by rhhx01.fht-esslingen.de (8.9.3/8.9.3) with ESMTP id VAA01188;
	Tue, 26 Oct 1999 21:57:28 +0200 (METDST)
Received: from 42.fht-esslingen.de (machtnix.dc.com [192.168.192.168])
	by firewall.dc.com (8.9.3/8.9.3) with ESMTP id UAA01088;
	Tue, 26 Oct 1999 20:52:37 GMT
Message-ID: <381656AF.FFF7C304@42.fht-esslingen.de>
Date: Tue, 26 Oct 1999 21:34:39 -0400
From: Alexander =?iso-8859-1?Q?K=F6nig?= <alex@rhlx01.fht-esslingen.de>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.12 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Benno Senoner <sbenno@gardena.net>
CC: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu,
        Andy Lo A Foe <andy@alsa-project.org>
Subject: [linux-audio-dev] Re: streaming from disk to terminatorX added (via mmap)
References: <99102417251100.02718@localhost.localdomain> <3813F834.D59E238E@42.fht-esslingen.de> <99102516141502.00665@localhost.localdomain>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by rhhx01.fht-esslingen.de id VAA01188
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id RAA31762
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 00dc2c6849107902fc37b0cd71be38be

Hi again...

Benno Senoner wrote:
> > problem... on my system I get a "no such device"-error. And all my
> > (mmap)manpage says is: Svr4 documents additional error codes ENXIO and
> > ENODEV. Do you have any idea what's wrong with my system? I am sorry if
> > this is a dumb question - I've never used mmap....
> 
> hmmm that is strange ...
> where exactly after the mmap ?
> try to check if MYFILESIZE is a valid value (page aligned size of the file),
> if fileno(wav_in.handle) is a valid value etc

Oops - just as I expected a *really* dumb question. I changed the
configure script to use mpg123/sox as default if available and that of
course does not work with mmap()... well a --enable-wavonly fixed this
:( Sorry! Oh yeah: it works beautifully on big mem machines ;) So I
guess "no such device" just tells me this FILE* is not on a device (as
it is a pipe)... Yes, see my face red.

<..>
> For BIGENDIAN boxes, I'd suggest to do the byte swapping just before you process
> the data, the overhead is very little compared to all the rest.

Yeah - while discussing this with Paul I actually came to the same
conclusion. It's a joke compared to the rest that's done with the
sample...

<..>
> use byte swapping on the fly

Agreed :)

<..>
> I esperimented with streaming of 60 mono ( 44khz 16bit) tracks from disk
> and I had to use at least 1MB buffer per track to keep things somewhat
> reliable.
> ( PII400 + 256MB RAM + IBM 16GB EDIE HD)

Hey we should try to get the mmap()-code to the new tX soon - I'd really
like to see this :)

> How du you plan to keep into mem 8 files of 20MB in len (4min mono file)
> = 160MB, not everyone has that amount of ram on his box.

Yeah well, from it's design-idea you actually have shorter and looping
samples (yes and maybe one or two big ones) as only then you can
actually sync those turntables nicely... but: you are right!

> Trust me: smart mmap() + mlocking() will work well and reliably on 8 tracks
> while saving the mix on the disk, using no more that 500kb-1Mb per track.

Yeah. Accepted. Let me see it ;)

> for mp3:
> if this is really true that Andy has managed to play mp3s backwards *CORRECTLY*
> without any distortion, then if I were You, I would include his mp3 code.

Yes actually I'd like to have that... Hi, Andy ;) But if you take a look
at the current tX (it should be avialable via anonymous CVS from 
:pserver:terminatorX@rhlx01.fht-esslingen.de:/cvs/terminatorX
oh, if you check it out: first step: press "add turntable" ;)
you'll see: I have a lot of other things to do for tX too :( But having
a tX that would allow mmap()ing mono-wavs and streaming mp3s with Andy's
code and the ability to load other audioformats via sox sounds extremly
cool :)

<..>
[real turntables]
> Basically as far I understand they sample (using the soundcard) a static wave
> recorded on the turntable and compute the actual rotational speed.
> Then just feed this value to the tX engine, and your
> mp3 on-turntable scratcher is here.
> :-)

Damn and I just destroyed the motor of my turntable for terminatorX...

> In the next days I will add mlock()/munlock() support to tX let's see it there
> are any benefits during high system load.
> 
> Alex, if you want to mail me privately you can mail me in german too,
> ( I'm from Suedtirol  :-)  )

Yes actually I will do that so we can chat about CVS and moving your
code into the next release...

Bye, Alex
-- 
_______________________________________________________________________
                            Alexander Knig - alex@42.fht-esslingen.de
                                                  http://termX.cjb.net

[From the Homer Quotables:]
 
I don't care if Ned Flanders is the nicest guy 
in the world.  He's a jerk -- end of story.

		-- Homer Simpson
		   When Flanders Failed


From - Tue Oct 26 22:26:59 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA31795
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 17:02:13 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA02719 for linux-audio-dev-list; Tue, 26 Oct 1999 16:03:38 -0400
Received: from rhhx01.fht-esslingen.de (rhhx01.fht-esslingen.de [134.108.56.1]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA02716 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 16:03:32 -0400
Received: from firewall.dc.com (rsra77.fht-esslingen.de [134.108.128.77])
	by rhhx01.fht-esslingen.de (8.9.3/8.9.3) with ESMTP id VAA01191;
	Tue, 26 Oct 1999 21:57:30 +0200 (METDST)
Received: from 42.fht-esslingen.de (machtnix.dc.com [192.168.192.168])
	by firewall.dc.com (8.9.3/8.9.3) with ESMTP id UAA01092;
	Tue, 26 Oct 1999 20:52:39 GMT
Message-ID: <38165AEE.77BF550D@42.fht-esslingen.de>
Date: Tue, 26 Oct 1999 21:52:46 -0400
From: Alexander =?iso-8859-1?Q?K=F6nig?= <alex@rhlx01.fht-esslingen.de>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.12 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Benjamin GOLINVAUX <golinvaux@benjamin.net>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: streaming from disk to terminatorX added (via  
 mmap)
References: <199910252148.RAA16689@renoir.op.net> <38158C18.41C92BEC@42.fht-esslingen.de> <000357c9852525d3_mailit@relay.eunet.be>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by rhhx01.fht-esslingen.de id VAA01191
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id RAA31795
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ef25de9c8ed86520b71f406c0fc192f0

Benjamin GOLINVAUX wrote:
> Aren't there more than forwards/backwards FX *at the contrained speed* when
> scratchin' ?

Well judging from the analouge nature of a turntable this is most
definitely true. You actually explained some possible reasons. The
question is whether you can actually hear these. Now from the response
I've been getting from people that usually scratch with real turntables,
they say tX sounds somewhat authentic. Considering how bad the signal is
the mouse actually provides I'd say this is pretty amazing. And since
V3.2 you can modify the cutoff-frequency of the lowpass filter with the
other axis (with the next release you can select between
scratching/volume/cutoff/echo_feedback). Now if you use your mouse for
scratching let's say the x-way and you just do that but still enable the
other axis to do something you get slight (not random) changes for the
other effect. This is of course nowhere near what a real turntable does
but it turns out to sound pretty organic.

> Wonder how a sine wave looks like when scratched.

Well I could scratch a sine wave with tX for you - but I guess that's
not what you are interested in ;)

I'm really interested in what else a real turntable does aside from
forward/backward-stuff, too. Maybe this could be simulated as well to
make tX sound more realistic.

Bye, Alex
-- 
_______________________________________________________________________
                            Alexander Knig - alex@42.fht-esslingen.de
                                                  http://termX.cjb.net

[From the Homer Quotables:]
 
I don't care if Ned Flanders is the nicest guy 
in the world.  He's a jerk -- end of story.

		-- Homer Simpson
		   When Flanders Failed

From - Tue Oct 26 23:26:25 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA24169
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 23:18:23 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA03328 for linux-audio-dev-list; Tue, 26 Oct 1999 22:19:38 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA03325 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 22:19:35 -0400
Received: from localhost.localdomain (d212-151-62-146.swipnet.se [212.151.62.146]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id EAA29788; 
          Wed, 27 Oct 1999 04:13:36 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: est@hyperreal.org, linux-audio-dev@ginette.musique.umontreal.ca,
        linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: pci128 line-in help
Date: Wed, 27 Oct 1999 04:03:38 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <19991027001930.26463.qmail@hyperreal.org>
In-Reply-To: <19991027001930.26463.qmail@hyperreal.org>
MIME-Version: 1.0
Message-Id: <99102704210400.14491@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id EAA29788
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id XAA24169
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 696941e0d8f3892b831ef8891a5e6f19

On Wed, 27 Oct 1999, est@hyperreal.org wrote:
> I can't seem to get my pci128 line-in to work.  This is using the
> (es1370) OSS driver distributed with the 2.2.7 kernel.  I've tried all
> the obvious mixer settings as well as all the private ioctl()s the
> driver has, checked my hardware, etc.  Can anyone think of anything I
> might be missing?

What version of the card do you have?

There seems to be two versions, as far as the connectors are
concerned; one that looks like in "Getting started" (that you get
with OEM cards, at least), and one with a much smarter design.

The older (?) ones have Aux In and Rear Out in the same jack, and the
"lineout=1" option swithes it from Line In to Rear Out.

On the new (?) one (that I have), the "Speaker Out" has turned into
"Front Out", and can be changed between line/speaker with two jumpers
on the card. There is a Line In where the Speaker Out jack used to
be, and yes, it works in full duplex with the two Line Outs. :-) On
this card, "lineout=1" only enables the output from the jack that is
now ony Rear Out. AFAIK, the new Rear Out jack has no other function.

If your card is of the latter kind, your problem might be that the
Line In is actually where the "manual" says Speaker Out is; that is,
the 4'th (last) jack counting from the one closest to the
joystick/MIDI port. Check the card.

If it's the "old" card, make sure you do *not* use "lineout=1". Also
experiment some with the mixer. Mine seems a bit dodgy with the
kernel driver... (Works great with ALSA, though.)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Oct 26 23:36:24 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA24776
	for <slinkp@ulster.net>; Tue, 26 Oct 1999 23:22:48 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA03333 for linux-audio-dev-list; Tue, 26 Oct 1999 22:20:14 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA03330 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 26 Oct 1999 22:20:12 -0400
Received: from someip.ppp.op.net (d-bm2-04.ppp.op.net [209.152.194.36]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id WAA24928; Tue, 26 Oct 1999 22:14:16 -0400 (EDT)
Message-Id: <199910270214.WAA24928@renoir.op.net>
To: Billy Biggs <vektor@DIV8.NET>
cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: Sync Issues (was Re: External MIDI Sync using OSS/Free) 
In-reply-to: Your message of "Tue, 26 Oct 1999 19:21:12 EDT."
             <Pine.LNX.3.96.991026191131.6810A-100000@vektor.div8.net> 
Date: Tue, 26 Oct 1999 23:09:52 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: bfe4eacfb20968882eee4a2c3125b8dd

>  Here's one algorithm I tried to use for a while, you'll see the problem:
>
>   - There are N fragments "queued" by the hardware buffer in the
>     soundcard
>   - I check to see if i'm at the start of a new beat, if I am then
>     - If there are samples to play, start playing them in this fragment
>     - If there are MIDI notes to play, queue them to be played at
>       time per fragment * N in the future
>
>  The sync problem comes from not getting swapped in enough such that
>you'll send out the MIDI data at the instant that the audio out the
>soundcard actually gets played.

right, and the (or at least, *a*) solution (used in SoftWerk) is easy:
don't do forward queuing of MIDI data in /dev/sequencer. just output
it at the right time yourself, along with the audio data. the swapping
in/out problem is a separate issue - you may need to mlock() some of
the critical data in place. 

[ as an aside: a pet peeve: very few linux systems these days ever
swap. they do paging all the time, but thats different, well, sort
of. ]

your time resolution will be dictated by the fragment size used by the
soundcard driver/soundcard h/w, and it will way better than the kernel
sequencer offers, since its based on the timer interrupt (20ms typically).

SoftWerk's problem is even more acute: because one MIDI track can
control another's output data (e.g. one track controls the volume for
another track's NoteOn messages), and because the tracks run at
different speeds and may not ever be in sync, it is *impossible* to
use any kernel sequencer for any useful work. why ? because until time
T arrives, its impossible to compute what should actually be
sent. this means that you can't queue anything in the kernel
sequencer: you just have to wait for the "tick" to come around, and
compute what MIDI data should be sent (if any) on that tick.

in SoftWerk's case, because it doesn't process audio data in any way,
I use sigitimer(2) to give me a periodic async signal every so often
(typically 20-100ms: its controllable in the UI). i use this to
measure the passage of time, and compute when a beat/tick is
happening.  soon, i will use the RTC with select(2), which will be
more accurate and permit much faster tempos than sigitimer can.

if SoftWerk *did* handle audio data (which i hope it never does!), it
could use the timing from the soundcard DAC (or ADC) to get much more
precise timing. in such a system, external MIDI clock would just be
used as a master sync for tempo - i.e. each interval between 2 MIDI
clocks byte represents 1/24 (is that right ?) of a 1/4 beat.  we can
measure the time interval, and continue on with that tempo for our
calculations until the time between two MIDI clock bytes
changes. meanwhile, all actual scheduling of MIDI output data would be
done from the timebase of the soundcard DAC.

well, that's my approach anyway.

>  These days, I'm using three threads.  One for midi, one for audio, and
>one for the GUI.

sounds about right, although given the low speed of MIDI data, and the
fact that you can really only sensibly check for it between processing
audio fragments, you might be able to get away with just two.

>  Drivers had better be forthcomming.  Yes, I'm talking about cards like
>those, such as the Event Layla and Darla, etc.  Without them, it makes
>Linux pretty useless as a multitrack platform...

the manufacturers of such cards don't have much of an interest in
Linux. i did a little work at AES to try to change that, but its going
to be a long uphill battle.

>  Well, at least pretty annoying.  Personally, I have two AudioPCI cards
>and a dedicated MPU-401 card for MIDI.  Each of the AudioPCI cards have
>two dsps, giving me four /dev/dsp devices.

if you had 2 4D-NX's, you'd have 64 openable (mono) channels for
playback (*)...  is that enough for you ? :))) total cost $78+postage,
plus you'd have two excellent MIDI interfaces as well.

(*) but just 4 mono channels for recording, sigh.

--p

From - Fri Oct 29 11:23:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id FAA16171
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 05:18:00 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id EAA07633 for linux-audio-dev-list; Wed, 27 Oct 1999 04:04:27 -0400
Received: from p-biset.issy.cnet.fr (p-biset.issy.cnet.fr [139.100.0.33]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id EAA07630 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 04:04:17 -0400
Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0)
	id <4Q2TNGSR>; Wed, 27 Oct 1999 09:58:23 +0200
Message-ID: <F09BA6AD2FB2D211BFAC00805F312C89B5868D@p-heron.issy.cnet.fr>
From: MOULET Xavier CNET/DMR/ISS <xavier.moulet@cnet.francetelecom.fr>
To: "'linux-audio-dev@ginette.musique.umontreal.ca'"
	 <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: RE: [linux-audio-dev] Rollin' and scratchin'
Date: Wed, 27 Oct 1999 09:58:15 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id FAA16171
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: bce3b4c1de4c4a26a39aab5117ff3be9

well theoretically ang generally speaking, 
if your Johnny cash song is a(t), (in the case of a sine, a(t) =
A*sin(b*t+phi))

then t is the time played, which is a function of the speed of the turntable
and of the REAL time. If you note r the rate between "normal" speed R (i.e.
45 rpm or 33) and the one you give with your hand R', then r=R'/R is varying
during the time, and can be negative if you reverse, zero if you stop the
table and 1 if you speed up.

Then, you get r(t). The output of your turntable (besides the "violin noise"
as said in a preceding message) b(t) is then

b(t) = A*sin(b*t*r(t)+phi), wich is typically a FM signal IF a(t) is a sine,
and more generally,

b(t) = a(t*r(t))  (which means that the time goes "r(t)" times faster ..)

What do you hear ? a FM synth !!

remember r(t) is a rotationnal SPEED .

Well if your r(t) is a pure sine, r(t) = R*sin(Ht+hh), then the frequency
representation of (letting aside the constant phases)

		b(t) = Asin(br(t)) = Asin(bsin(Ht+hh)))

is a Bessel function, and the spectrum of your signal has sidelobes (i.e :
supplementary frequencies instead of only one freq. at b) roughly speaking
at b+H and b-H. But you have to scratch like HELL (typically ... er ... 1000
times per second ?) if you need to make an FM style sound like this.

Hope all of that is
1) true
2) understandable
3) gives way to expreimentation and calculation

On to the better than real tuentable !!

> -----Message d'origine-----
> De: reactor/CTPmedia [mailto:reactor@sagv5.gyakg.u-szeged.hu]
> Date: mardi 26 octobre 1999 22:18
> : LAD Mail
> Objet: Re: [linux-audio-dev] Re: streaming from disk to terminatorX
> added (via mmap)
> 
> 
>  % Benjamin wrote % 
> 
>  >% Wonder how a sine wave looks like when scratched.
> 
> nice :)
> 
> i have a Johnny Cash record, which has 2 seconds of sinewave in the
> middle of a song, because Johnny said "bad" words :)
> 
> anyway, what do you expect to see?
> it should be just a sinewave with changing frequency.
> i can send you a sample, if you're interested.
> 
> -- 
> 
> (reactor/CTPmedia) 
> (http://linux.gyakg.u-szeged.hu/> ~reactor/index.html)
> (linux 
> audiowarez) 
> (http://www.bright.net/~dlphilp/linuxsound/toc.html)
> 

From - Fri Oct 29 11:23:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id IAA00516
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 08:52:39 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id HAA07872 for linux-audio-dev-list; Wed, 27 Oct 1999 07:45:00 -0400
Received: from hme0.smtp04.sprint.ca (hme0.smtp04.sprint.ca [207.107.250.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA07869 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 07:44:57 -0400
Received: from vektor.div8.net (root@spc-isp-ktc-uas-04-18.sprint.ca [209.103.20.169])
	by hme0.smtp04.sprint.ca (8.8.8/8.8.8) with ESMTP id HAA28880;
	Wed, 27 Oct 1999 07:39:01 -0400 (EDT)
Received: from localhost by div8.net
	via sendmail with smtp
	id <m11gRR7-00092gC@vektor.div8.net> (Debian Smail3.2.0.102)
	for <pbd@Op.Net>; Wed, 27 Oct 1999 07:40:13 -0400 (EDT) 
Date: Wed, 27 Oct 1999 07:40:13 -0400 (EDT)
From: Billy Biggs <vektor@DIV8.NET>
To: Paul Barton-Davis <pbd@Op.Net>
cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] 4D-NXs (was Re: Sync Issues)
In-Reply-To: <199910270214.WAA24928@renoir.op.net>
Message-ID: <Pine.LNX.3.96.991027073739.9680D-100000@vektor.div8.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: f94ce0c5871964117baa22d7c27037de

On Tue, 26 Oct 1999, Paul Barton-Davis wrote:

> >  Drivers had better be forthcomming.  Yes, I'm talking about cards like
> >those, such as the Event Layla and Darla, etc.  Without them, it makes
> >Linux pretty useless as a multitrack platform...
> 
> the manufacturers of such cards don't have much of an interest in
> Linux. i did a little work at AES to try to change that, but its going
> to be a long uphill battle.

  Well, if there were a more powerful audio API, and applications that
took advantage of it, that would all change pretty quick...

> >  Well, at least pretty annoying.  Personally, I have two AudioPCI cards
> >and a dedicated MPU-401 card for MIDI.  Each of the AudioPCI cards have
> >two dsps, giving me four /dev/dsp devices.
> 
> if you had 2 4D-NX's, you'd have 64 openable (mono) channels for
> playback (*)...  is that enough for you ? :))) total cost $78+postage,
> plus you'd have two excellent MIDI interfaces as well.
> (*) but just 4 mono channels for recording, sigh.

  4D-NX seems to be just the chipset.  Which card are you referring to
here?  And, how does it get so many seperate openable channels?

  More importantly, would I be able to sync channels on the same sound
card?

--
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

From - Fri Oct 29 11:23:31 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA02720
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 09:08:59 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id HAA07888 for linux-audio-dev-list; Wed, 27 Oct 1999 07:56:57 -0400
Received: from gate.suse.cz (perex.cb.cesnet.cz [194.212.165.105]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA07885 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 07:56:54 -0400
Received: from localhost (perex@localhost)
	by gate.suse.cz (8.8.8/8.8.8) with ESMTP id NAA21523;
	Wed, 27 Oct 1999 13:54:01 +0200
X-Authentication-Warning: gate.suse.cz: perex owned process doing -bs
Date: Wed, 27 Oct 1999 13:54:01 +0200 (MEST)
From: Jaroslav Kysela <perex@suse.cz>
To: Billy Biggs <vektor@DIV8.NET>
cc: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca,
        linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: 4D-NXs (was Re: Sync Issues)
In-Reply-To: <Pine.LNX.3.96.991027073739.9680D-100000@vektor.div8.net>
Message-ID: <Pine.LNX.4.05.9910271350150.20984-100000@gate.suse.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: f3bc24415c75fd35c14ff8bb12315972

On Wed, 27 Oct 1999, Billy Biggs wrote:

>   4D-NX seems to be just the chipset.  Which card are you referring to
> here?  And, how does it get so many seperate openable channels?

32 stereo channels, mixing is performed by hardware

>   More importantly, would I be able to sync channels on the same sound
> card?

Yes, with the new PCM v2 ALSA API (currently in development - I welcome
testers).

1) load the playback buffers
2) send SYNC GO command to the driver

You may create more syncronized groups, of course.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA project  http://www.alsa-project.org

From - Fri Oct 29 11:23:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA14462
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 10:20:25 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA07993 for linux-audio-dev-list; Wed, 27 Oct 1999 09:03:51 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA07990 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 09:03:49 -0400
Received: from someip.ppp.op.net (d-bm3-1a.ppp.op.net [209.152.194.90]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id IAA28825; Wed, 27 Oct 1999 08:57:51 -0400 (EDT)
Message-Id: <199910271257.IAA28825@renoir.op.net>
To: Billy Biggs <vektor@DIV8.NET>
cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: 4D-NXs (was Re: Sync Issues) 
In-reply-to: Your message of "Wed, 27 Oct 1999 07:40:13 EDT."
             <Pine.LNX.3.96.991027073739.9680D-100000@vektor.div8.net> 
Date: Wed, 27 Oct 1999 09:53:34 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 084d05cd1478b8e8cf86e369886fbd9f

>> >  Drivers had better be forthcomming.  Yes, I'm talking about cards like
>> >those, such as the Event Layla and Darla, etc.  Without them, it makes
>> >Linux pretty useless as a multitrack platform...
>> 
>> the manufacturers of such cards don't have much of an interest in
>> Linux. i did a little work at AES to try to change that, but its going
>> to be a long uphill battle.
>
>  Well, if there were a more powerful audio API, and applications that
>took advantage of it, that would all change pretty quick...

actually, no.

i've had many discussions with different companies. the problem has
*never* been "Oh, Linux's audio API isn't worth us developing
for". Its also never been "Well, what applications are there ?"
(remember, most of these companies simply *assume* the existence of
apps, or alternatively, write their own). 

Instead, its a combination of:

      * "some other people wrote a Linux driver for our board and it sucked"
      * "we don't have enough programmers to do that"
      * "we don't have any written documentation to give you guys -
         we wrote the driver by having the software group sit in with
	 the hardware group"
      * "we think our hardware's proprietary secrets will be revealed
         if there is a source code driver"
      * "Linux ? Is that like Cakewalk ?"

>  4D-NX seems to be just the chipset.  Which card are you referring to
>here? 

go to www.hoontech.com and look at the SoundWave NX.

--p

From - Fri Oct 29 11:23:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA24418
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 11:24:09 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA08114 for linux-audio-dev-list; Wed, 27 Oct 1999 10:08:50 -0400
Received: from alsa.alsa-project.org (alsa.jcu.cz [160.217.1.49]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA08111 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 10:08:46 -0400
Received: from localhost (andy@localhost)
	by alsa.alsa-project.org (8.8.8/8.8.8) with ESMTP id QAA14111;
	Wed, 27 Oct 1999 16:02:22 +0200
Date: Wed, 27 Oct 1999 16:02:22 +0200 (MEST)
From: Andy Lo A Foe <andy@alsa-project.org>
To: est@hyperreal.org
cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: mp3 seeking
In-Reply-To: <19991026172029.20739.qmail@hyperreal.org>
Message-ID: <Pine.LNX.4.05.9910271557590.13879-100000@alsa.alsa-project.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 7d5e0c56c7b0804ffcb03c79577bea07

On Tue, 26 Oct 1999 est@hyperreal.org wrote:

> First, I must thank you for alsaplayer since I'm using an adaptation
> of your adaptation of the mpg123 code in the next major release of
> oolaboola.  I'm encapsulating it in a separate process (called
> mp3serv) to get re-entrancy.  I may move to the xing decoder but the
> process interface will remain the same.

Very interesting. I'm thinking about a similar solution for doing
reentrancy with plugins that don't support it, something like a proxy
plugin interface with IPC and shared memory. Where can I get the latest
version of oolaboola?

> My understanding was that it *may* take more than 3 frames of priming
> to resynchronize.  One of the xing/freemap people got me the logic but
> I haven't implemented it yet.

I'm using 3 right now. You need a bit more for lower bitrates it seems.
I've never really looked into the encoding algorithm so... :)

> Another issue is how to find a given frame in the first place.  Given
> that each frame may have an extra byte of padding, a multiplication is
> (audibly!) unreliable.  I've implemented a table-of-contents mechanism
> to deal with this.

Yes, if you want 100% correct seeking the best thing you can do is to
store the frame start positions while decoding. It is a bit slow though.
Is that what you're doing? (for VBR encoded files I don't see any other
(simple) method to support seeking BTW)...

Regs,

Andy
--
AlsaPlayer, http://www.alsa-project.org/~andy/

From - Fri Oct 29 11:23:40 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA25448
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 11:31:17 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA08121 for linux-audio-dev-list; Wed, 27 Oct 1999 10:12:02 -0400
Received: from alsa.alsa-project.org (alsa.jcu.cz [160.217.1.49]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA08117 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 10:11:40 -0400
Received: from localhost (andy@localhost)
	by alsa.alsa-project.org (8.8.8/8.8.8) with ESMTP id QAA14156;
	Wed, 27 Oct 1999 16:05:16 +0200
Date: Wed, 27 Oct 1999 16:05:16 +0200 (MEST)
From: Andy Lo A Foe <andy@alsa-project.org>
To: Alexander =?iso-8859-1?Q?K=F6nig?= <alex@rhlx01.fht-esslingen.de>
cc: Benno Senoner <sbenno@gardena.net>,
        linux-audio-dev@ginette.musique.umontreal.ca,
        linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: streaming from disk to terminatorX added (via mmap)
In-Reply-To: <381656AF.FFF7C304@42.fht-esslingen.de>
Message-ID: <Pine.LNX.4.05.9910271602360.13879-100000@alsa.alsa-project.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by nerf.ulster.net id LAA25448
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 13c5a70c68987915b8ab0564aa2d696e

On Tue, 26 Oct 1999, Alexander [iso-8859-1] Knig wrote:

> Yes actually I'd like to have that... Hi, Andy ;) But if you take a look

Hi Alex :)

> at the current tX (it should be avialable via anonymous CVS from 
> :pserver:terminatorX@rhlx01.fht-esslingen.de:/cvs/terminatorX
> oh, if you check it out: first step: press "add turntable" ;)
> you'll see: I have a lot of other things to do for tX too :( But having
> a tX that would allow mmap()ing mono-wavs and streaming mp3s with Andy's
> code and the ability to load other audioformats via sox sounds extremly
> cool :)

Here's my idea of a cool plugin. Put a representation of a Vinyl record on
the screen. Add 'artifical' markers to the surface so you can actually see
the record moving at 33RPM, 45RPM or whatever. Now grab the record with
your mouse and start scratching! I know it's not going to be very accurate
but it's gonna be hella cool nonetheless ;-)

Andy
--
AlsaPlayer, http://www.alsa-project.org/~andy/

From - Fri Oct 29 11:23:44 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA27813
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 11:46:41 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA08165 for linux-audio-dev-list; Wed, 27 Oct 1999 10:24:37 -0400
Received: from chekov.Belgium.EU.net (chekov.belgium.eu.net [193.74.208.161]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA08162 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 10:24:34 -0400
Received: from (adial118.liege.eunet.be [195.207.174.118])
	by chekov.Belgium.EU.net  with SMTP id QAA05588 
	for <linux-audio-dev@ginette.musique.umontreal.ca>;
	Wed, 27 Oct 1999 16:18:33 +0200 (MET DST)
Subject: Re: [linux-audio-dev] Re: 4D-NXs (was Re: Sync Issues) 
From: Benjamin GOLINVAUX <golinvaux@benjamin.net>
Reply-To: Benjamin GOLINVAUX <golinvaux@benjamin.net>
In-Reply-To: <199910271257.IAA28825@renoir.op.net>
Message-ID: <000357dd737fc8fe_mailit@relay.eunet.be>
References: <199910271257.IAA28825@renoir.op.net>
Date: Wed, 27 Oct 1999 16:12:47 +0200
X-Mailer: BeatWare Mail-It 2.0.3
X-BeOS-Platform: Intel or clone
X-Priority: 3 (Normal)
To: linux-audio-dev@ginette.musique.umontreal.ca
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5d8dbbaf50dfeac1551ec35d85bbbd75

>      * "Linux ? Is that like Cakewalk ?"


btw, Paul, any news on RME Hammerfall driver ?


Benjamin-







From - Fri Oct 29 11:23:52 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA06660
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 13:01:09 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA08384 for linux-audio-dev-list; Wed, 27 Oct 1999 11:50:56 -0400
Received: from upf.es (newton.upf.es [193.145.54.60]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA08381 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 11:50:48 -0400
Received: from mtg150.upf.es (mtg150.upf.es [193.145.44.150])
	by upf.es (8.9.0/8.9.0) with SMTP id RAA24391;
	Wed, 27 Oct 1999 17:44:34 +0200 (MET DST)
From: Maarten de Boer <maarten.deboer@iua.upf.es>
Reply-To: maarten.deboer@iua.upf.es
To: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: Re: [linux-audio-dev] Re: streaming from disk to terminatorX added (via mmap)
Date: Wed, 27 Oct 1999 16:45:09 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <Pine.LNX.4.05.9910271602360.13879-100000@alsa.alsa-project.org>
MIME-Version: 1.0
Message-Id: <99102716530801.00806@mtg150.upf.es>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 52a0ede804834c261cf9b65497f9d394

Any wrote
> Here's my idea of a cool plugin. Put a representation of a Vinyl record on
> the screen. Add 'artifical' markers to the surface so you can actually see
> the record moving at 33RPM, 45RPM or whatever. Now grab the record with
> your mouse and start scratching! I know it's not going to be very accurate
> but it's gonna be hella cool nonetheless ;-)

I'd say it is fairly easy to take an old turntable and a mouse,
and connect one of the 2 mouse sensors to the turntable. Or,
I guess this should also work: place a turntable-dish on the 
step-motor of a 5 1/4 inch disk drive. I think you can get 
pulses from the motor when you move it.

Maarten

From - Fri Oct 29 11:23:50 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA05165
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 12:51:00 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA08355 for linux-audio-dev-list; Wed, 27 Oct 1999 11:36:42 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id LAA08352 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 11:36:32 -0400
From: est@hyperreal.org
Received: (qmail 742 invoked by uid 162); 27 Oct 1999 15:30:37 -0000
Message-ID: <19991027153037.741.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] Re: mp3 seeking
In-Reply-To: <Pine.LNX.4.05.9910271557590.13879-100000@alsa.alsa-project.org>
 from Andy Lo A Foe at "Oct 27, 1999 04:02:22 pm"
To: Andy Lo A Foe <andy@alsa-project.org>
Date: Wed, 27 Oct 1999 08:30:37 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 73249f36ce308f642fdc976e8b821b7a

Andy Lo A Foe discourseth:
> 
> Very interesting. I'm thinking about a similar solution for doing
> reentrancy with plugins that don't support it, something like a proxy
> plugin interface with IPC and shared memory. Where can I get the latest
> version of oolaboola?

You can't yet..at least not the one with mp3 support.  Making it
deliverable is one of my two big tasks at the moment.

> Yes, if you want 100% correct seeking the best thing you can do is to
> store the frame start positions while decoding. It is a bit slow though.
> Is that what you're doing?

I actually calculate them before decoding unless they're cached (I've
got an on-disk format that stores 16-bit offsets between frames.)

Eric

From - Fri Oct 29 11:23:59 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA15792
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 14:00:24 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA08479 for linux-audio-dev-list; Wed, 27 Oct 1999 12:39:18 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id MAA08475 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 12:39:09 -0400
From: est@hyperreal.org
Received: (qmail 15876 invoked by uid 162); 27 Oct 1999 16:33:14 -0000
Message-ID: <19991027163314.15875.qmail@hyperreal.org>
Subject: [linux-audio-dev] sequencer timing issues
In-Reply-To: <199910270214.WAA24928@renoir.op.net> from Paul Barton-Davis at
 "Oct 26, 1999 11:09:52 pm"
To: Paul Barton-Davis <pbd@Op.Net>
Date: Wed, 27 Oct 1999 09:33:14 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: e864b31a4531e1431405a412849bfa6b

Paul Barton-Davis discourseth:
>
> SoftWerk's problem is even more acute: because one MIDI track can
> control another's output data (e.g. one track controls the volume for
> another track's NoteOn messages), and because the tracks run at
> different speeds and may not ever be in sync, it is *impossible* to
> use any kernel sequencer for any useful work. why ? because until time
> T arrives, its impossible to compute what should actually be
> sent. this means that you can't queue anything in the kernel
> sequencer: you just have to wait for the "tick" to come around, and
> compute what MIDI data should be sent (if any) on that tick.

Hmm..sounds like you're already paying much of the price of the
hyperseq approach..might as well go all the way. :)

> in SoftWerk's case, because it doesn't process audio data in any way,
> I use sigitimer(2) to give me a periodic async signal every so often
> (typically 20-100ms: its controllable in the UI). i use this to
> measure the passage of time, and compute when a beat/tick is
> happening.  soon, i will use the RTC with select(2), which will be
> more accurate and permit much faster tempos than sigitimer can.

Wouldn't you say that an HZ > 100 kernel is the cleanest solution?

Re RTC: I'm about to post (just to linux-audio-dev) an idea about how
*you* can use it without stopping *my* app from using it. :)

Eric

From - Fri Oct 29 11:24:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA17754
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 14:11:50 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA08498 for linux-audio-dev-list; Wed, 27 Oct 1999 12:42:51 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id MAA08495 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 12:42:48 -0400
From: est@hyperreal.org
Received: (qmail 18978 invoked by uid 162); 27 Oct 1999 16:36:49 -0000
Message-ID: <19991027163649.18977.qmail@hyperreal.org>
Subject: [linux-audio-dev] RTC Daemon Design
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Wed, 27 Oct 1999 09:36:49 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 9560614f597211e15a87801bc3f9f394

[ I want to use /dev/rtc, but the idea that my app would block any
  other app from using it bugs me.  Thus, this. -est :]

RTC Daemon Design

MOTIVATION

* Stock linuxes aren't going to set the timer interrupt to above 100
  HZ anytime soon.

* Still, we'd like to be able to sleep for sub-tick intervals with
  reasonable accuracy.

* /dev/rtc is available and can produce interrupts at up to 8192 HZ.

* However, /dev/rtc can be used by only one process at a time.

* This makes /dev/rtc a good candidate for use by a daemon which can
  serve its functionality to multiple processes

* Processes needing this functionality can attempt to connect to the
  rtc daemon and, only if that fails, attempt to seize control of
  /dev/rtc itself.


DESIGN

rtcd [ <rate> [ <unix domain socket> ] ]

rtcd must be started by root.  It sets its scheduler to SCHED_RR with
high static priority (90? command line option?).  It binds <unix
domain socket> (default /dev/rtcd).  It opens /dev/rtc and sets
periodic interrupts to <rate> (which must be a power of 2 between 2
and 8192; default 2048).  Unix domain connections are accepted on
<unix domain socket> and rtcd speaks rtcd protocol to these
connections.


THE PROTOCOL

Clients send the desired absolute wakeup time as a struct timespec.
At or after that time, rtcd writes a uint8 to the client containing
log2(<rate>).  The client can thus wait by blocking on a
read()/select() on the connection.


OTHER DETAILS

rtcd's Main Loop:

 wait on /dev/rtc
  get the current time
  run through the connections and do any processing needed
  select() on connections
  read requests
    and note them as time/connection pairs on time-sorted priority q
  pop elements off front of priority q with time >= now
    and send wakeups to their connections

rtcd needs to operate on client connections in non-blocking mode.  If
writing on a connection would block (which would probably indicate a
serious design problem in the client), it should be shut down..at
least after a few tries..and a syslog entry written.

rtcd shuts down on SIGHUP.

From - Fri Oct 29 11:24:01 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA26268
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 15:05:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA08631 for linux-audio-dev-list; Wed, 27 Oct 1999 13:49:42 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA08628 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 13:49:30 -0400
From: est@hyperreal.org
Received: (qmail 3776 invoked by uid 162); 27 Oct 1999 17:42:57 -0000
Message-ID: <19991027174257.3764.qmail@hyperreal.org>
Subject: [linux-audio-dev] HZ > 100 overhead
In-Reply-To: <199910271733.NAA00675@renoir.op.net> from Paul Barton-Davis at
 "Oct 27, 1999 02:29:02 pm"
To: Paul Barton-Davis <pbd@Op.Net>
Date: Wed, 27 Oct 1999 10:42:56 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: a2bb2ea23b89b511f71f31617416beba

Paul Barton-Davis discourseth:
> >
> >Wouldn't you say that an HZ > 100 kernel is the cleanest solution?
> 
> its the cleanest, but not the best. HZ = 1000 adds about 8% overhead
> to IRQ processing *all the time*.

Are you *sure* about this?  I seem to remember there was some debate
about that figure on linux-kernel.

Eric

From - Fri Oct 29 11:24:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA21310
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 21:27:57 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA09087 for linux-audio-dev-list; Wed, 27 Oct 1999 17:01:00 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA09084 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 17:00:54 -0400
Received: from localhost.localdomain (IDENT:root@[194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id WAA14978;
	Wed, 27 Oct 1999 22:54:33 +0200
Received: from localhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with SMTP id UAA03320;
	Wed, 27 Oct 1999 20:23:42 +0200
From: Benno Senoner <sbenno@gardena.net>
To: est@hyperreal.org
Subject: [linux-audio-dev] Re: mmap()/mlockall()/read()
Date: Wed, 27 Oct 1999 20:03:00 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
References: <19991026171005.14380.qmail@hyperreal.org>
In-Reply-To: <19991026171005.14380.qmail@hyperreal.org>
MIME-Version: 1.0
Message-Id: <99102720234200.03276@localhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: ddb4a4dc540eb936ef3d08eb9b21020f

I agree no all topics,

using mlockall(MCL_CURRENT|MCL_FUTURE) on a low mem box,
and trying to mmap a large file would simply not work.

I would definitively use MAP_UNLOCKED on Linux,
becaue it could give us the best possible performance.
(and maybe provide a fallback solution for other OSes) 

I think the best fallback solution is the following (but not 100% reliable
in the case of syscalls):
mlock(MCL_CURRENT);
mlock() malloec()ed aread
( or is there a better way to do this ?)


but strange,
MAP_UNLOCKED seems to not exist on my 2.2.12 kernel !!
I grepped through the entire kernel source and include files but
nothing !!!!!

in /usr/include/bits/mman.h
there are some flags:
----
/* These are Linux-specific.  */
#ifdef __USE_MISC
# define MAP_GROWSDOWN  0x0100          /* Stack-like segment.  */
# define MAP_DENYWRITE  0x0800          /* ETXTBSY */
# define MAP_EXECUTABLE 0x1000          /* Mark it as an executable.  */
# define MAP_LOCKED     0x2000          /* Lock the mapping.  */
# define MAP_NORESERVE  0x4000          /* Don't check for reservations.  */
#endif
----

no MAP_UNLOCKED present ...
is this a 2.3.x feature ?


> > What I'm trying to say: read() doesn't work better than mmap() in terms of
> > behaviour during swapping, because the kernel could easily swap out
> > your buffer where you read() in the data.
> 
> Actually, the last time I tested this extensively (with a 2.0.x kernel
> I think), mmap() was much better performing than read()..for a while.
> When sequential accessing of a file got to a point around my RAM
> limits, the disk activity became insane.  Maybe things are better now.
> 
> > I will add a feature to the pagefaulter thread which uses mlock()/munlock if
> > root privileges are available, so that even
> > Eric is satisfied.
> > :-)
> 
> Eric is hard to satisfy. :)

You are not the only !
:-)

> 
> > PS: mlockall(MCL_CURRENT|MCL_FUTURE) is a bad idea because when you do the
> > mmap() of the large file the process tries to load all into mem,and my scheme
> > would not work. Better to use mlockall(MCL_CURRENT) and mlock()/munlock()
> > areas on demand.
> 
> This is a useful solution in some circumstances.  However, it means I
> can't use malloc()/new, may have trouble with shared libraries or
> dynamically loaded plugins and have to worry about reserving stack
> space.  It's not the way I want to work.

agreed for shared libs, but if you don't make any strange syscalls ,
I think there are not very much problems.
As for malloc : just mlock() the area after the allocation.

regards,
Benno.

From - Fri Oct 29 11:24:07 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA32348
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 15:44:36 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA08748 for linux-audio-dev-list; Wed, 27 Oct 1999 14:31:39 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id OAA08745 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 14:31:36 -0400
From: est@hyperreal.org
Received: (qmail 21353 invoked by uid 162); 27 Oct 1999 18:24:44 -0000
Message-ID: <19991027182444.21352.qmail@hyperreal.org>
Subject: [linux-audio-dev] C++ philosophy
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Wed, 27 Oct 1999 11:24:44 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 3e0f8fa8cd94540765693223d0676dd7

[ found in a worldforge irc log ]

06:39:54 chuck:   my philosophy is the more the compiler thrashes at compile ti
me, the less your app will thrash at runtime
06:40:02 Mike:   damn right! :)
06:40:13 Mike:   well, not always right. But still a good philosophy :)
06:40:28 chuck:   it's an especially good sign when the compiler just sits ther
e for a while
06:40:39 chuck:   optimization and all
06:40:57 chuck:   so by extension, if the compiler locks up you have a perfect
app ;)

From - Fri Oct 29 11:24:06 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA30845
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 15:35:12 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA08589 for linux-audio-dev-list; Wed, 27 Oct 1999 13:39:23 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA08586 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 13:39:20 -0400
Received: from someip.ppp.op.net (d-bm3-1a.ppp.op.net [209.152.194.90]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id NAA00675; Wed, 27 Oct 1999 13:33:17 -0400 (EDT)
Message-Id: <199910271733.NAA00675@renoir.op.net>
To: est@hyperreal.org
cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: sequencer timing issues 
In-reply-to: Your message of "Wed, 27 Oct 1999 09:33:14 PDT."
             <19991027163314.15875.qmail@hyperreal.org> 
Date: Wed, 27 Oct 1999 14:29:02 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 6f72e3c05abbd1ae23b1bff31853bbeb

  [ why softwerk can't use a kernel sequencer ]

>Hmm..sounds like you're already paying much of the price of the
>hyperseq approach..might as well go all the way. :)

thats the plan, just as soon as i:

      * finish autoconf-izing Quasimodo
      * fix Quasimodo's audio input system
      * finish writing a prototype of my take on the plugin API
      * port the ALSA CS4231 driver to pcm-v2
      * port SoftWerk to Gtk--

etc. etc. :)

>> in SoftWerk's case, because it doesn't process audio data in any way,
>> I use sigitimer(2) to give me a periodic async signal every so often
>> (typically 20-100ms: its controllable in the UI). i use this to
>> measure the passage of time, and compute when a beat/tick is
>> happening.  soon, i will use the RTC with select(2), which will be
>> more accurate and permit much faster tempos than sigitimer can.
>
>Wouldn't you say that an HZ > 100 kernel is the cleanest solution?

its the cleanest, but not the best. HZ = 1000 adds about 8% overhead
to IRQ processing *all the time*. and even then, the system timer is
only accurate to 1ms, which is still not adequate for some envisioned
uses of SoftWerk (though given its use of h/w MIDI ports and the speed
of MIDI communication, its pretty excellent for 99% of them :)

--p

From - Fri Oct 29 11:24:03 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA29318
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 15:25:34 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA08599 for linux-audio-dev-list; Wed, 27 Oct 1999 13:43:56 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA08596 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 13:43:54 -0400
Received: from someip.ppp.op.net (d-bm3-1a.ppp.op.net [209.152.194.90]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id NAA01175; Wed, 27 Oct 1999 13:37:51 -0400 (EDT)
Message-Id: <199910271737.NAA01175@renoir.op.net>
To: Benjamin GOLINVAUX <golinvaux@benjamin.net>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: 4D-NXs (was Re: Sync Issues) 
In-reply-to: Your message of "Wed, 27 Oct 1999 16:12:47 +0200."
             <000357dd737fc8fe_mailit@relay.eunet.be> 
Date: Wed, 27 Oct 1999 14:33:36 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 81883711af48ae3481aeaddb7f7d6397

>btw, Paul, any news on RME Hammerfall driver ?

i'd like some! winfried has posted nothing on any lists i've seen, and
i don't have his address. can someone get in touch with him ? thats
going to be damn impressive addition to Linux once we have a driver!

--p

From - Fri Oct 29 11:24:08 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA04607
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 16:16:43 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA08819 for linux-audio-dev-list; Wed, 27 Oct 1999 15:01:40 -0400
Received: from shell.dhp.com (shell.dhp.com [199.245.105.1]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA08815 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 15:01:35 -0400
Received: by shell.dhp.com (Postfix, from userid 668)
	id 91E551AC76; Wed, 27 Oct 1999 14:55:29 -0400 (EDT)
Date: Wed, 27 Oct 1999 14:55:29 -0400 (EDT)
From: Billy Biggs <vektor@DIV8.NET>
To: est@hyperreal.org
Cc: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca,
        linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: HZ > 100 overhead
In-Reply-To: <19991027174257.3764.qmail@hyperreal.org>
Message-ID: <Pine.LNX.4.04.9910271452290.4689-100000@shell.dhp.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: cc806fd169f9440b0af78cc9e3e0399c

On Wed, 27 Oct 1999 est@hyperreal.org wrote:

> Paul Barton-Davis discourseth:
> > >
> > >Wouldn't you say that an HZ > 100 kernel is the cleanest solution?
> > 
> > its the cleanest, but not the best. HZ = 1000 adds about 8% overhead
> > to IRQ processing *all the time*.
> 
> Are you *sure* about this?  I seem to remember there was some debate
> about that figure on linux-kernel.

  Just to add to the confusion, I remember that this only adds significant
overhead on older machines.  Regardless, a higher HZ value should be
standard, and switching back to a lower one (100) should be simply a
kernel config option.

  This is all pretty controversial though.

  #demoscene on irc.openprojects.net for people who support this idea. :)
  #linux on linuxnet for some people who don't support this idea. :)

--
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

From - Fri Oct 29 11:24:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA29745
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 15:28:34 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA08697 for linux-audio-dev-list; Wed, 27 Oct 1999 14:10:25 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA08694 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 14:10:22 -0400
Received: from someip.ppp.op.net (d-bm3-1a.ppp.op.net [209.152.194.90]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id OAA04563; Wed, 27 Oct 1999 14:04:17 -0400 (EDT)
Message-Id: <199910271804.OAA04563@renoir.op.net>
To: est@hyperreal.org
cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: HZ > 100 overhead 
In-reply-to: Your message of "Wed, 27 Oct 1999 10:42:56 PDT."
             <19991027174257.3764.qmail@hyperreal.org> 
Date: Wed, 27 Oct 1999 15:00:03 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: f1933468332c60df68baa0326d5cf473

>> >Wouldn't you say that an HZ > 100 kernel is the cleanest solution?
>> 
>> its the cleanest, but not the best. HZ = 1000 adds about 8% overhead
>> to IRQ processing *all the time*.
>
>Are you *sure* about this?  I seem to remember there was some debate
>about that figure on linux-kernel.

Ed Hall measured it, and my overall impression of Ed is that I'd trust
him to do this correctly. what did the l-k folks think ?

From - Fri Oct 29 11:24:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA05568
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 16:22:50 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA08781 for linux-audio-dev-list; Wed, 27 Oct 1999 14:45:05 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA08778 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 14:45:01 -0400
Received: from someip.ppp.op.net (d-bm3-1a.ppp.op.net [209.152.194.90]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id OAA08865; Wed, 27 Oct 1999 14:39:00 -0400 (EDT)
Message-Id: <199910271839.OAA08865@renoir.op.net>
To: est@hyperreal.org
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] RTC Daemon Design 
In-reply-to: Your message of "Wed, 27 Oct 1999 09:36:49 PDT."
             <19991027163649.18977.qmail@hyperreal.org> 
Date: Wed, 27 Oct 1999 15:34:46 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: fbb09ba8ac238e71c1d0c0c2c8135942

In message <19991027163649.18977.qmail@hyperreal.org>you write:
>[ I want to use /dev/rtc, but the idea that my app would block any
>  other app from using it bugs me.  Thus, this. -est :]

nice piece of work, except this:

>THE PROTOCOL
>
>Clients send the desired absolute wakeup time as a struct timespec.
>At or after that time, rtcd writes a uint8 to the client containing
>log2(<rate>).  The client can thus wait by blocking on a
>read()/select() on the connection.

we want to be able to use the /dev/rtcd connection semantically just like
/dev/rtc, which means we should be able to get periodic "interrupts"
from the daemon. the way this is written makes it sound as if the
client *has* to always write back its "next wakeup time" every time it
is woken by the daemon. 

thats ok for apps that want to use the rtcd as a non-periodic timing
source, but there needs to be support for a client to say "wake me
every N <unit of time>". this will help us minimize the client-daemon
traffic and work done by the client. 

i would suggest that unit of time be milliseconds, specified as a
uint16. thus, the request "packet" is now:

	#define RTCD_PERIODIC_REQUEST 1
	#define RTCD_ONESHOT_REQUEST  2
	
	struct rtcd_request {
	    unsigned char rtcd_type;
	    union {
	       struct timespec when;
	       uint16 interval_msecs;
	    } rtcd_r;
	};

in addition, i'd suggest that a client cancels a periodic request
with:

	req.rtcd_type = RTCD_PERIODIC_REQUEST;
	req.rtcd_r.interval_msecs = 0;

this will be an exciting addition to our pantheon of "tools to make
cool applications". are you going to volunteer to write it as well ?

--p	


From - Fri Oct 29 11:24:17 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA20956
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 17:58:37 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA08957 for linux-audio-dev-list; Wed, 27 Oct 1999 16:11:57 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id QAA08953 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 16:11:53 -0400
From: est@hyperreal.org
Received: (qmail 9551 invoked by uid 162); 27 Oct 1999 20:04:26 -0000
Message-ID: <19991027200426.9550.qmail@hyperreal.org>
Subject: [linux-audio-dev] rtcd vs hz > 100!
In-Reply-To: <199910271839.OAA08865@renoir.op.net> from Paul Barton-Davis at
 "Oct 27, 1999 03:34:46 pm"
To: Paul Barton-Davis <pbd@Op.Net>
Date: Wed, 27 Oct 1999 13:04:25 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 6f3640fad3e4e78d9adc05d952f9fc4f

Paul Barton-Davis discourseth:
> In message <19991027163649.18977.qmail@hyperreal.org>you write:
> >[ I want to use /dev/rtc, but the idea that my app would block any
> >  other app from using it bugs me.  Thus, this. -est :]
> 
> nice piece of work,

:D

> except this:

doh!

> we want to be able to use the /dev/rtcd connection semantically just like
> /dev/rtc, which means we should be able to get periodic "interrupts"
> from the daemon. the way this is written makes it sound as if the
> client *has* to always write back its "next wakeup time" every time it
> is woken by the daemon. 

Yes.  The design actually started out handling periodic interrupts.
Then I think I got fascinated with how minimalist I could get. :)

> thats ok for apps that want to use the rtcd as a non-periodic timing
> source, but there needs to be support for a client to say "wake me
> every N <unit of time>". this will help us minimize the client-daemon
> traffic and work done by the client. 

OK.

> i would suggest that unit of time be milliseconds, specified as a
> uint16. thus, the request "packet" is now:
> 
> 	#define RTCD_PERIODIC_REQUEST 1
> 	#define RTCD_ONESHOT_REQUEST  2
> 	
> 	struct rtcd_request {
> 	    unsigned char rtcd_type;
> 	    union {
> 	       struct timespec when;
> 	       uint16 interval_msecs;
> 	    } rtcd_r;
> 	};

Hmm!  I'm worried that milliseconds may end up too constraining.
Also, one-shots with absolute times seems more reliable to me since it
factors out the time to get the request to rtcd.

Also, clients should probably be able to query the rtc rate..unless we
do standardize on milliseconds, in which case things stay simpler. :)

> in addition, i'd suggest that a client cancels a periodic request
> with:
> 
> 	req.rtcd_type = RTCD_PERIODIC_REQUEST;
> 	req.rtcd_r.interval_msecs = 0;

Heh..`note-off'.

There's one idea I'm afraid to mention since I think *you'll* probably
want it! :)  rtcd could (optionally) signal pthread condition variables
in shared memory.

> this will be an exciting addition to our pantheon of "tools to make
> cool applications". are you going to volunteer to write it as well ?

I actually wrote the design a couple of months ago.  I've been holding
off on it because I was hoping HZ > 100 would take the day.  Now, I'm
of the feeling that even if a music distro does that, redhat/suse/etc
won't..not for a while anyway.  So, yeah, I volunteer..unless this
thread talks me out of it. :)

Eric

From - Fri Oct 29 11:24:14 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA15280
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 17:22:41 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA08964 for linux-audio-dev-list; Wed, 27 Oct 1999 16:12:41 -0400
Received: from anime.net (anime.net [205.139.105.150]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA08961 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 16:12:38 -0400
Received: from localhost (goemon@localhost)
	by anime.net (8.9.3/8.9.3) with ESMTP id NAA17324;
	Wed, 27 Oct 1999 13:06:31 -0700
Date: Wed, 27 Oct 1999 13:06:30 -0700 (PDT)
From: Dan Hollis <goemon@sasami.anime.net>
X-Sender: goemon@anime.net
To: Paul Barton-Davis <pbd@Op.Net>
cc: Billy Biggs <vektor@DIV8.NET>,
        linux-audio-dev@ginette.musique.umontreal.ca,
        linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: 4D-NXs (was Re: Sync Issues) 
In-Reply-To: <199910271257.IAA28825@renoir.op.net>
Message-ID: <Pine.LNX.4.10.9910271303020.17269-100000@anime.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 41c3bec402f8caf1c36add39d62cc557

On Wed, 27 Oct 1999, Paul Barton-Davis wrote:
>       * "we don't have enough programmers to do that"

If the drivers are being written for them by volunteers, I dont see how
this is relevant.

>       * "we don't have any written documentation to give you guys -
>          we wrote the driver by having the software group sit in with
> 	 the hardware group"

This should be a warning sign to anyone thinking of purchasing their
hardware. If a company cant be bothered to internally document the
hardware, what happens if key engineers leave the company? Oh dear, their
project is *permanently screwed*, which means zero support for end users.
This is no way to run a company.

>       * "we think our hardware's proprietary secrets will be revealed
>          if there is a source code driver"

Uh, isnt this what patents are for? If someone reverse engineers their
card, they are *completely screwed* unless they have patent protection.

-Dan

From - Fri Oct 29 11:24:15 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA15643
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 17:24:43 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA08973 for linux-audio-dev-list; Wed, 27 Oct 1999 16:16:00 -0400
Received: from bologna.nettuno.it (bologna.nettuno.it [193.43.2.1]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA08970 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 16:15:44 -0400
Received: from mar095k1 (ppp09-nas0.marano.nettuno.it [193.207.118.203])
	by bologna.nettuno.it (8.9.3/8.9.3/NETTuno 3.3) with SMTP id WAA09365;
	Wed, 27 Oct 1999 22:09:24 +0200 (MDT)
Message-ID: <001401bf20b7$0a735da0$cb76cfc1@mar095k1>
From: "Alessandro Fogar" <mar095k1@ud.nettuno.it>
To: "Jaroslav Kysela" <perex@suse.cz>
Cc: "Guenter Geiger" <geiger@epy.co.at>,
        "linux-audio-dev" <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Re: 4D-NXs and Hammerfall
Date: Wed, 27 Oct 1999 22:07:42 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 58cf616b279a446a281326c47c2e7b01

I'd like to know if in the future will be possible under Alsa to use the
'rear' output of the Hoontech card as an additional pair of stereo outputs,
I'll receive it tomorrow and I'd like to use it with a 4 ch. output.

Will the rear outputs be syncronized with the other stereo pair ?

About the drivers for RME Hammerfall, I think that they are available
(OSSFree), please ask to Guenter Geiger, Guenter are you reading this ?

I think that the RME card is very good but too upsized for me...

Notice that I asked to Echo about Linux driver for their very interesting
new card 'Mona', they said there are no plans at this time to develop Linux
drivers or release their code to the open source community (You know, I
tried...) ();-)

Bye

Alessandro Fogar

From: Jaroslav Kysela <perex@suse.cz>
To: Billy Biggs <vektor@DIV8.NET>
Cc: Paul Barton-Davis <pbd@Op.Net>;
linux-audio-dev@ginette.musique.umontreal.ca
<linux-audio-dev@ginette.musique.umontreal.ca>; linux-sound@vger.rutgers.edu
<linux-sound@vger.rutgers.edu>
Date: Wednesday, October 27, 1999 3:11 PM
Subject: [linux-audio-dev] Re: 4D-NXs (was Re: Sync Issues)


>>   4D-NX seems to be just the chipset.  Which card are you referring to
>> here?  And, how does it get so many seperate openable channels?
>
>32 stereo channels, mixing is performed by hardware
>
>>   More importantly, would I be able to sync channels on the same sound
>> card?
>
>Yes, with the new PCM v2 ALSA API (currently in development - I welcome
>testers).
>
>1) load the playback buffers
>2) send SYNC GO command to the driver
>
>You may create more syncronized groups, of course.
>
> Jaroslav


From - Fri Oct 29 11:24:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA17496
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 21:02:55 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA09082 for linux-audio-dev-list; Wed, 27 Oct 1999 17:00:51 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA09079 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 17:00:47 -0400
Received: from localhost.localdomain (IDENT:root@[194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id WAA14974;
	Wed, 27 Oct 1999 22:54:21 +0200
Received: from localhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with SMTP id WAA00626;
	Wed, 27 Oct 1999 22:19:45 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Andy Lo A Foe <andy@alsa-project.org>
Subject: [linux-audio-dev] Re: streaming from disk to terminatorX added (via mmap)
Date: Wed, 27 Oct 1999 22:10:34 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: Alexander Knig <alex@rhlx01.fht-esslingen.de>,
        linux-audio-dev@ginette.musique.umontreal.ca,
        linux-sound@vger.rutgers.edu
References: <Pine.LNX.4.05.9910260908140.24753-100000@alsa.alsa-project.org>
In-Reply-To: <Pine.LNX.4.05.9910260908140.24753-100000@alsa.alsa-project.org>
MIME-Version: 1.0
Message-Id: <99102722194400.00611@localhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 4dee2437a06c29c652b928356f083bb9

On Tue, 26 Oct 1999, Andy Lo A Foe wrote:

> A segment holds a number of decoded frames (usually 2 or 3) and also
> remembers the number of the first frame. So lets say we want to play 
> a mp3 backwards starting at frame 1000. The tricky part is to keep the
> ringbuffer full with the right frames all the time. As soon as one segment
> is used up by the audio reader thread it releases a semaphore on which the
> audio decoder thread is blocking on. The audio decoder thread wakes up and
> check if there are any segments that needs to be filled. But wait you say,
> what if you need to fill a segment with frames 1000 to 998? Decoding frame
> 1000, then 999 and then 998 won't work because of the way mp3s are
> encoded. What do you do then? You seek to frame 995 and start decoding
> from there. You throw all data away up to and including frame 997. By this
> time your mp3 decoding engine is recovered from the 'seek' operation. Now
> you store the next 3 frames in your ringbuffer. The audio reader thread,
> when detecting negative speed, simply reads a segment backwards so in
> this case it starts at frame 1000. The segment before the current one
> must contain frame 995 to 997 (first jump to frame 992, decode 3
> frames and discard them, decode the needed data), and so on...
> The decoder thread is also a couple of segments ahead of the reader
> thread. So when you do rapid positive and negative speed switching
> (scratching) the decoder thread is actually idling since none of the
> segments get discarded. 
> 
> Comments? :)

Ok, but what are then the general rule for decoding mp3 backwards: 
assume that you are at frame n:

point1:
decode frames: n-5 , n-4 n-3 , n-2 , n-1 , n  ( 6 frames)
throw away frames n-5,n-4,n-3
fill buffers with frames n-2 , n-1 , n  (this is thwe usable data)
n=n-3
return to point 1

right ?
(correct me pleasse if I'm wrong)

of course playing backward requires 2x the CPU horsepower, but with today's CPUs
combined with optimized x86 assembly code like the mpg123's one , this is not a
major problem except if you want to decode lots of tracks backwards.

regards,
Benno.

From - Fri Oct 29 11:24:31 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA31619
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 19:06:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA09076 for linux-audio-dev-list; Wed, 27 Oct 1999 17:00:43 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA09073 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 17:00:32 -0400
Received: from localhost.localdomain (IDENT:root@[194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id WAA14968;
	Wed, 27 Oct 1999 22:54:11 +0200
Received: from localhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with SMTP id WAA00643;
	Wed, 27 Oct 1999 22:30:21 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Benjamin GOLINVAUX <golinvaux@benjamin.net>,
        Benjamin GOLINVAUX <golinvaux@benjamin.net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: streaming from disk to terminatorX added (via mmap)
Date: Wed, 27 Oct 1999 22:20:17 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910252148.RAA16689@renoir.op.net> <38158C18.41C92BEC@42.fht-esslingen.de> <000357c9852525d3_mailit@relay.eunet.be>
In-Reply-To: <000357c9852525d3_mailit@relay.eunet.be>
Cc: Alexander Knig <alex@rhlx01.fht-esslingen.de>
MIME-Version: 1.0
Message-Id: <99102722302101.00611@localhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 42c00dbab1c87ec5dc328fb5a28d4601

On Tue, 26 Oct 1999, Benjamin GOLINVAUX wrote:

> 
> Wonder how a sine wave looks like when scratched.
> 
> Any comments ?
> 
> 
> Benjamin-

actually the interpolation algorithm of terminatorX fails when 
I load a 15kHz sine wave ( 0dB) into tX, and play it at a mere 103% speed 
( 1.03) , there is nice aliasing noise, even if we are not violating Nyquist's
theorem in this case.
(15kHz*1.03 < 22kHz)
Scratching this wave at fast speeds produces quite funny sounds,
IMHO for best quality we should oversample at least 2x - 4x and lowpass the
result:
( BTW: I will try to develop a fast AND high quality interpolator suitable
for these things)

(the real turntable would be bandlimited in frequency too due to the
limitations of the needle and the frequency limitations of the analog circuits
(amplifier etc)).
  
Alexander: what kind of interpolation are you using ?
Are you lowpass filtering the results (I guess no).
( different from your resonant lowpass filter, which fails too (= cracklings)
when I feed my nasty high freq sine wave to it.

regards,
Benno.

From - Fri Oct 29 11:24:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA29136
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 18:50:54 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA09062 for linux-audio-dev-list; Wed, 27 Oct 1999 16:53:20 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA09059 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 16:53:15 -0400
Received: from localhost.localdomain (IDENT:root@[194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id WAA14900;
	Wed, 27 Oct 1999 22:46:55 +0200
Received: from localhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with SMTP id WAA00884;
	Wed, 27 Oct 1999 22:47:50 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Paul Barton-Davis <pbd@Op.Net>, est@hyperreal.org
Subject: [linux-audio-dev] Re: HZ > 100 overhead
Date: Wed, 27 Oct 1999 22:39:18 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
References: <199910271804.OAA04563@renoir.op.net>
In-Reply-To: <199910271804.OAA04563@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99102722475002.00611@localhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 5cf5894dc663244fdcdf60b344adaf7f

On Wed, 27 Oct 1999, Paul Barton-Davis wrote:
> >> >Wouldn't you say that an HZ > 100 kernel is the cleanest solution?
> >> 
> >> its the cleanest, but not the best. HZ = 1000 adds about 8% overhead
> >> to IRQ processing *all the time*.
> >
> >Are you *sure* about this?  I seem to remember there was some debate
> >about that figure on linux-kernel.
> 
> Ed Hall measured it, and my overall impression of Ed is that I'd trust
> him to do this correctly. what did the l-k folks think ?

It depends on your box, a P133 might suffer much more than a PII400.
On a PII400 the performance his is very little IMHO (no actual numbers)

But we can't assume that HZ=1000 for our multimedia apps.
Therefore my proposal is the following:
(similar to Eric's proposed rtcd)
In our upcoming multimedia API we will run the audio daemon
not only for providing PCM/MIDI services but precise timers too.
This could be implemented by choosing the most efficient method
at the moment:
that means: if you are runnnig with 1ms audio buffer sizes,
instead of firing up the RTC device, use the soundcard's timer
(combined with RDTSC) , to wakeup your clients.

comments ?

Benno.
 

From - Fri Oct 29 11:24:24 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA26890
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 18:38:10 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA09094 for linux-audio-dev-list; Wed, 27 Oct 1999 17:02:21 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA09091 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 17:02:17 -0400
Received: from localhost.localdomain (IDENT:root@[194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id WAA15037;
	Wed, 27 Oct 1999 22:56:02 +0200
Received: from localhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with SMTP id WAA00961;
	Wed, 27 Oct 1999 22:57:01 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Alexander Knig <alex@rhlx01.fht-esslingen.de>
Date: Wed, 27 Oct 1999 22:50:49 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
MIME-Version: 1.0
Message-Id: <99102722570103.00611@localhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 49c7dec1ea054bd58360d95895b1c88f

Hi folks,
I added the my mlock()/munlock() scheme to terminatorX
it is activated when you compile with the option
USE_SCHEDULER  ( #ifdef'd ) and requires root privileges,
it works actually very good,  ( scratching speed set to 9.9 )
execpt the mentioned Linux low-latency problems while doing
disk I/O (and low-mem boxes do some I/O (using mmap()) when you scratch at 10x
speed  :-) )

the link is here:

http://www.gardena.net/benno/linux/terminatorX-3.2-mmap2.patch

Alexander: could you try this by using  a kernel with the low-latency patch
applied and  booting with mem=16m  ?
(do not forget to tune your EIDE disks , see my page)

regards,
Benno.

From - Fri Oct 29 11:24:20 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA24765
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 18:24:13 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA09156 for linux-audio-dev-list; Wed, 27 Oct 1999 17:15:08 -0400
Received: from gate.suse.cz (perex.cb.cesnet.cz [194.212.165.105]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA09150 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 17:15:04 -0400
Received: from localhost (perex@localhost)
	by gate.suse.cz (8.8.8/8.8.8) with ESMTP id XAA23921;
	Wed, 27 Oct 1999 23:12:07 +0200
X-Authentication-Warning: gate.suse.cz: perex owned process doing -bs
Date: Wed, 27 Oct 1999 23:12:07 +0200 (MEST)
From: Jaroslav Kysela <perex@suse.cz>
To: Alessandro Fogar <mar095k1@ud.nettuno.it>
cc: Guenter Geiger <geiger@epy.co.at>,
        linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Re: 4D-NXs and Hammerfall
In-Reply-To: <001401bf20b7$0a735da0$cb76cfc1@mar095k1>
Message-ID: <Pine.LNX.4.05.9910272307030.23857-100000@gate.suse.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: a7f9803fa401a20107827f2ae89e7a3f

On Wed, 27 Oct 1999, Alessandro Fogar wrote:

> I'd like to know if in the future will be possible under Alsa to use the
> 'rear' output of the Hoontech card as an additional pair of stereo outputs,
> I'll receive it tomorrow and I'd like to use it with a 4 ch. output.
> 
> Will the rear outputs be syncronized with the other stereo pair ?

I haven't any experience with rear output (looks that difference is only
in mixer part), but every PCM stream processed with Trident chipset can be
syncronized in this way.

> About the drivers for RME Hammerfall, I think that they are available
> (OSSFree), please ask to Guenter Geiger, Guenter are you reading this ?

It would be perfect, because the ALSA midlevel routines offers automatic
conversions (I need to do some parts, but the skeleton is ready) for
OSS/Lite and alsa-lib offers this functionality for native applications.
Also mmap is fully supported and API covers also IEC-958/AES/EBU.
API is now ready for this card.

> I think that the RME card is very good but too upsized for me...

I'd like to see the support for this professional card in ALSA.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA project  http://www.alsa-project.org



From - Fri Oct 29 11:24:21 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA26850
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 18:37:54 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA09209 for linux-audio-dev-list; Wed, 27 Oct 1999 17:28:15 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id RAA09206 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 17:28:12 -0400
From: est@hyperreal.org
Received: (qmail 28082 invoked by uid 162); 27 Oct 1999 21:15:22 -0000
Message-ID: <19991027211521.28081.qmail@hyperreal.org>
Subject: [linux-audio-dev] Re: mmap()/mlockall()/read()
In-Reply-To: <99102720234200.03276@localhost.localdomain> from Benno Senoner
 at "Oct 27, 1999 08:03:00 pm"
To: Benno Senoner <sbenno@gardena.net>
Date: Wed, 27 Oct 1999 14:15:21 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 797dc04eb7fee8dfc29c54043125f147

Benno Senoner discourseth:
> 
> I think the best fallback solution is the following (but not 100% reliable
> in the case of syscalls):
> mlock(MCL_CURRENT);
> mlock() malloec()ed aread

Hmm, I remain sceptical that I'll see large apps using this.  Using
other-people's-libraries is common after all.  It would mean a lot of
work that doesn't seem worth the benefit to me.  However, it would be
pleasant if people proved me wrong. :)

> but strange,
> MAP_UNLOCKED seems to not exist on my 2.2.12 kernel !!

It doesn't exist..I made it up! :)

I think it would be A Good Idea, and it looks easy to add.

> > Eric is hard to satisfy. :)
> 
> You are not the only !
> :-)

Thence comes progress.

Eric

From - Fri Oct 29 11:24:37 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA17084
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 21:00:35 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA09304 for linux-audio-dev-list; Wed, 27 Oct 1999 18:13:10 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA09301 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 18:13:05 -0400
Received: from localhost.localdomain (IDENT:root@[194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id AAA16197;
	Thu, 28 Oct 1999 00:06:51 +0200
Received: from localhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with SMTP id AAA01403;
	Thu, 28 Oct 1999 00:07:49 +0200
From: Benno Senoner <sbenno@gardena.net>
To: est@hyperreal.org, Paul Barton-Davis <pbd@Op.Net>
Subject: Re: [linux-audio-dev] rtcd vs hz > 100!
Date: Thu, 28 Oct 1999 00:03:49 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <19991027200426.9550.qmail@hyperreal.org>
In-Reply-To: <19991027200426.9550.qmail@hyperreal.org>
MIME-Version: 1.0
Message-Id: <99102800074906.00611@localhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3f476129952da0c4aecb6317c8014a16

On Wed, 27 Oct 1999, est@hyperreal.org wrote:
> Paul Barton-Davis discourseth:

> 
> Hmm!  I'm worried that milliseconds may end up too constraining.
> Also, one-shots with absolute times seems more reliable to me since it
> factors out the time to get the request to rtcd.
> 
> Also, clients should probably be able to query the rtc rate..unless we
> do standardize on milliseconds, in which case things stay simpler. :)
> 
> > in addition, i'd suggest that a client cancels a periodic request
> > with:
> > 
> > 	req.rtcd_type = RTCD_PERIODIC_REQUEST;
> > 	req.rtcd_r.interval_msecs = 0;
> 
> Heh..`note-off'.
> 
> There's one idea I'm afraid to mention since I think *you'll* probably
> want it! :)  rtcd could (optionally) signal pthread condition variables
> in shared memory.
> 
> > this will be an exciting addition to our pantheon of "tools to make
> > cool applications". are you going to volunteer to write it as well ?
> 
> I actually wrote the design a couple of months ago.  I've been holding
> off on it because I was hoping HZ > 100 would take the day.  Now, I'm
> of the feeling that even if a music distro does that, redhat/suse/etc
> won't..not for a while anyway.  So, yeah, I volunteer..unless this
> thread talks me out of it. :)
> 
> Eric

My suggestion is to use  "struct timeval" to deal with time related isssues,
just as usleep() does:
In the meantime we will not provide the microsecond resolution,
but we let the user query the timer granularity, that means
if one uses 8192 RTC = 125usec granularity, or the UTIME patches will
get into the mainstream kernel, we are ready for the high precision timing !

Do we all agree no this ?

Benno.

From - Fri Oct 29 11:24:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA14144
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 20:41:49 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA09320 for linux-audio-dev-list; Wed, 27 Oct 1999 18:29:48 -0400
Received: from bashir.belgium.eu.net (bashir.Belgium.EU.net [193.74.208.147]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA09317 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 18:29:45 -0400
Received: from (adial148.liege.eunet.be [195.207.174.148])
	by bashir.belgium.eu.net  with SMTP id AAA24913 
	for <linux-audio-dev@ginette.musique.umontreal.ca>;
	Thu, 28 Oct 1999 00:23:34 +0200 (MET DST)
Subject: Re: [linux-audio-dev] Re: 4D-NXs and Hammerfall
From: Benjamin GOLINVAUX <golinvaux@benjamin.net>
Reply-To: Benjamin GOLINVAUX <golinvaux@benjamin.net>
In-Reply-To: <Pine.LNX.4.05.9910272307030.23857-100000@gate.suse.cz>
Message-ID: <000357e439a74d4f_mailit@relay.eunet.be>
References: <Pine.LNX.4.05.9910272307030.23857-100000@gate.suse.cz>
Date: Thu, 28 Oct 1999 00:17:41 +0200
X-Mailer: BeatWare Mail-It 2.0.3
X-BeOS-Platform: Intel or clone
X-Priority: 3 (Normal)
To: linux-audio-dev@ginette.musique.umontreal.ca
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 8c7e61129f01944cead00588058b22af

>> About the drivers for RME Hammerfall, I think that they are available
>> (OSSFree), please ask to Guenter Geiger, Guenter are you reading this ?

Quick search on the net... Digi 32 and the like seem to be supported, but
not Hammerfall... am I missing something ?






Benjamin-

From - Fri Oct 29 11:24:34 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA14252
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 20:42:40 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA01217 for linux-audio-dev-list; Wed, 27 Oct 1999 19:35:53 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA09400 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 19:13:34 -0400
Received: from localhost.localdomain (d212-151-58-204.swipnet.se [212.151.58.204]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA09207; 
          Thu, 28 Oct 1999 01:07:30 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>, Billy Biggs <vektor@DIV8.NET>
Subject: [linux-audio-dev] Re: 4D-NXs (was Re: Sync Issues)
Date: Thu, 28 Oct 1999 00:53:59 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
References: <199910271257.IAA28825@renoir.op.net>
In-Reply-To: <199910271257.IAA28825@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99102801094001.00465@localhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by mb04.swip.net id BAA09207
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA14252
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: bc381747d97342f0c217a5ac045836d3

On Wed, 27 Oct 1999, Paul Barton-Davis wrote:
> Instead, its a combination of:
> 
>       * "some other people wrote a Linux driver for our board and it sucked"
>       * "we don't have enough programmers to do that"
>       * "we don't have any written documentation to give you guys -
>          we wrote the driver by having the software group sit in with
> 	 the hardware group"
>       * "we think our hardware's proprietary secrets will be revealed
>          if there is a source code driver"
>       * "Linux ? Is that like Cakewalk ?"

Another one:

	* "Can you give an estimate of how many Linux users would
	   be interested in buying our card, if there was a driver?"

That's a tough one... How many users do you get without real cards?
And how many real cards and applications do you get without lots of
users...?

Well, it's our own "fault"; this is a Free/Open Source world, and
*we* have to get things moving if anything is to happen. Therefore,
an API that makes it easier for us to reuse code, and for users to
integrate existing applications into working solutions, will probably
help a lot.

Would IBM, Corel, SyBase and co have cared about Linux if it wasn't
already a big player in the server field? Probably not... They've
been hurt by MS and other concurents too many times to jump into
something like Linux, before they see that it actually works in real
life.

I'm afraid we have to get Linux boxes into studios. Before that 
happens, performance superior by orders of magnitude to that of
Windows and MacOS, is little but exciting news for the techies.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Oct 29 11:24:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA15080
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 20:48:07 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA01317 for linux-audio-dev-list; Wed, 27 Oct 1999 19:36:03 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA01291 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 19:35:57 -0400
Received: from localhost.localdomain (IDENT:root@[194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id BAA17111;
	Thu, 28 Oct 1999 01:29:41 +0200
Received: from localhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with SMTP id BAA01775;
	Thu, 28 Oct 1999 01:30:42 +0200
From: Benno Senoner <sbenno@gardena.net>
To: reactor <reactor@sagv5.gyakg.u-szeged.hu>,
        reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>
Subject: Re: [linux-audio-dev] Re: streaming from disk to terminatorX added (via mmap)
Date: Thu, 28 Oct 1999 01:29:24 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <19991028011455.A396@boksi>
In-Reply-To: <19991028011455.A396@boksi>
Cc: linux-audio-dev@ginette.musique.umontreal.ca,
        Alexander Knig <alex@rhlx01.fht-esslingen.de>
MIME-Version: 1.0
Message-Id: <99102801304109.00611@localhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 597aa6903e141a2998209059daaa41c6

On Thu, 28 Oct 1999, reactor/CTPmedia wrote:
> % Benno Senoner wrote %
> 
>  >% actually the interpolation algorithm of terminatorX fails when 
>  >% I load a 15kHz sine wave ( 0dB) into tX, and play it at a mere 103% speed 
>  >% ( 1.03) , there is nice aliasing noise, even if we are not violating Nyquist's
>  >% theorem in this case.
>  >% (15kHz*1.03 < 22kHz)
>  >% Scratching this wave at fast speeds produces quite funny sounds,
>  >% IMHO for best quality we should oversample at least 2x - 4x and lowpass the
>  >% result:
> 
> hmm, i'm surely wrong, but i think that the turntable doesn't have aliasing noises,
> because of it's ANALOG nature. remember, we try to scratch DIGITALLY now.
> 

yes, we try to emulate the analog thing as close as possible,
therefore we must filter out aliasing noise and do a good interpolation when
"spinning" very slowly.

Benno.

From - Fri Oct 29 11:24:49 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA25413
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 21:57:36 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA01434 for linux-audio-dev-list; Wed, 27 Oct 1999 20:44:35 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA01431 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 20:44:31 -0400
Received: from localhost.localdomain (IDENT:root@[194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id CAA17844;
	Thu, 28 Oct 1999 02:38:40 +0200
Received: from localhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with SMTP id CAA02071;
	Thu, 28 Oct 1999 02:39:41 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Paul Barton-Davis <pbd@Op.Net>, audiality@swipnet.se
Subject: [linux-audio-dev] Re: HZ > 100 overhead
Date: Thu, 28 Oct 1999 02:16:29 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: est@hyperreal.org, linux-audio-dev@ginette.musique.umontreal.ca,
        linux-sound@vger.rutgers.edu
References: <199910272353.TAA12086@renoir.op.net>
In-Reply-To: <199910272353.TAA12086@renoir.op.net>
MIME-Version: 1.0
Message-Id: <9910280239410C.00611@localhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 3c45dea13e3134bd9289c8fed365def9

On Thu, 28 Oct 1999, Paul Barton-Davis wrote:
> >In our upcoming multimedia API we will run the audio daemon
> >not only for providing PCM/MIDI services but precise timers too.
> 
> i hate to go on about this, but MIDI only programs shouldn't need to
> depend on audio services to work. i might even want to run a MIDI
> interface on a machine with no audio card at all - its hard to find an
> argument to be using an audio daemon under such circumstances.
> 
> thats why i like eric's suggestion for an rtcd that can be used by
> programs that want precise-ish timing *but have no option to do
> audio-based timing* because they don't deal with audio. any program
> that does its own audio output or input in small fragments has its own
> built-in source of precise timing, but not every interesting program
> works that way.
> 
> --p

Of course I agree,  that you are not forced to run the audio server
all the time.
Do you remember the discussion some time ago ?
"the client can access the device directly or use the audio server"
"the client can do his own plugin hosting, or delegate the hosting to the audio
server"

In the case of the timer I'd opt for a similar solution.

( note that in my case the rtcd is a subsystem of the audio (or better
multimedia) engine )

I'm not sure if it is convenient to run the audioserver and rtcd in 2 separate
threads or if it's better to do all stuff in a single process (less scheduling
overhead ?)

The API should provide calls that let you allocate timers similar to the RTC
device, but where you can specify if the system is forced to use the RTC device
(in this case rtcd is used), or if you need only a generic timer with better
than x ms granularity.
In that case the engine could optimize and if it sees that PCM is runnnig (with
small fragments) , it could just use this timing source and wake up your app
when needed (via FIFO, socket etc.)

>From an API point of view it should make no difference,
the client simply allocates a timer ressource , (with the possibility to
force some specific timer "ie I want to use RTC because I need 8192HZ
precision").


IMHO the advantage to integrate the rtcd into the multimedia engine
(which of course works on machines without soundcards) , is that 
the system can optimize things when multiple timer sources are available.

We could even provide a way where the client "hosts" the timer in his own
thread, (like by your SIGIO notification), or by simply providing an RTC
wrapper, but with an uniform API.
That means if you run your Softwerk sequencer standalone (using the MIDI
device / timers  directly  (in this case the timer is managed though the
wrapper) ) ,
will work as well as when running it as a client to the multimedia engine:
MIDI events are feed to the engine via MIDI "pipe" to the server,
and timers are managed by the server.
= server wakes you up using the optimal method (or your preferred if you
forced this during the timer allocation) ).

efficient and flexible.

comments ?

Benno.

From - Fri Oct 29 11:24:45 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA24102
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 21:48:22 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA01410 for linux-audio-dev-list; Wed, 27 Oct 1999 20:28:49 -0400
Received: from anime.net (anime.net [205.139.105.150]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA01407 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 20:28:46 -0400
Received: from localhost (goemon@localhost)
	by anime.net (8.9.3/8.9.3) with ESMTP id RAA20895;
	Wed, 27 Oct 1999 17:23:13 -0700
Date: Wed, 27 Oct 1999 17:23:13 -0700 (PDT)
From: Dan Hollis <goemon@sasami.anime.net>
X-Sender: goemon@anime.net
To: Paul Barton-Davis <pbd@Op.Net>
cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: 4D-NXs (was Re: Sync Issues) 
In-Reply-To: <199910272359.TAA12551@renoir.op.net>
Message-ID: <Pine.LNX.4.10.9910271712030.20764-100000@anime.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 81d35fec6d2bdf465d2b22d2d87ccaf6

On Wed, 27 Oct 1999, Paul Barton-Davis wrote:
> >>       * "we don't have enough programmers to do that"
> >If the drivers are being written for them by volunteers, I dont see how
> >this is relevant.
> if they had a driver written for them by 4Front, and it had problems,
> their desire to have volunteers do another one is low. i won't name
> the company that had this problem, but they are a real soundcard company.

Still irrelevant to the *statement being made*, which is "*we* dont have
enough programmers to do that". Why has the number of programmers *they*
have, have anything to do with us volunteers writing a driver for them for
free? *boggle*.

> >>       * "we don't have any written documentation to give you guys -
> >>          we wrote the driver by having the software group sit in with
> >> 	 the hardware group"
> >This should be a warning sign to anyone thinking of purchasing their
> >hardware. If a company cant be bothered to internally document the
> >hardware, what happens if key engineers leave the company? Oh dear, their
> >project is *permanently screwed*, which means zero support for end users.
> >This is no way to run a company.
> Yamaha (the company that this quote comes from) seems to be doing
> quite well :)

No, Yamaha *does* have documentation on the native PCI stuff. They just
wont release it.

> >Uh, isnt this what patents are for? If someone reverse engineers their
> >card, they are *completely screwed* unless they have patent protection.
> and the cost of a patent is ? look, there's very little truly clever
> stuff in these cards, and what is patented is often stupid (est told
> me last week about someone who has patented putting an LFO in hardware
> on a soundcard with a wavetable synth). most soundcard technologies
> don't last more than a few years, and investing the X-thousand dollars
> in seeking patent protection for a nifty hack that will be irrelevant
> in that time is pretty unjustifiable for most things. security for
> obscurity really does work when you only want it for a little while ;)

I guess what we need are some PCI snooper hardware so we can start putting
the shits up (various unnamed companies). Start posting reverse engineered
specs and stuff will surely get their attention ;)

Didnt RMS say that the FSF was going to start doing some reverse
engineering with PCI snoopers?

> i think david's point is an important one that i didn't mention, and
> he's right that the only thing, in the end, that most of the companies
> are going to respond to is more than a couple of studios saying "we
> run linux - we want to buy your cards/devices and there are no drivers".

Im more concerned about chip vendors than card manufacturers. If we
convince the chip vendor to release docs then theres really nothing a card
manufacturer can do to stop us.

We really only have three problematic chip vendors here - Yamaha, Aureal,
and Creative Labs. Although Creative Labs may be coming around finally
with the emu10k stuff.

The trend toward FPGA makes things interesting, of course.

-Dan

From - Fri Oct 29 11:24:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA19234
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 21:14:19 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA01349 for linux-audio-dev-list; Wed, 27 Oct 1999 19:59:22 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA01346 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 19:59:19 -0400
Received: from someip.ppp.op.net (d-bm3-00.ppp.op.net [209.152.194.64]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id TAA12086; Wed, 27 Oct 1999 19:53:42 -0400 (EDT)
Message-Id: <199910272353.TAA12086@renoir.op.net>
To: Benno Senoner <sbenno@gardena.net>
cc: est@hyperreal.org, linux-audio-dev@ginette.musique.umontreal.ca,
        linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: HZ > 100 overhead 
In-reply-to: Your message of "Wed, 27 Oct 1999 22:39:18 +0200."
             <99102722475002.00611@localhost.localdomain> 
Date: Wed, 27 Oct 1999 20:49:32 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: d763a0926bdd58cac5209c3fa85a18cf

>In our upcoming multimedia API we will run the audio daemon
>not only for providing PCM/MIDI services but precise timers too.

i hate to go on about this, but MIDI only programs shouldn't need to
depend on audio services to work. i might even want to run a MIDI
interface on a machine with no audio card at all - its hard to find an
argument to be using an audio daemon under such circumstances.

thats why i like eric's suggestion for an rtcd that can be used by
programs that want precise-ish timing *but have no option to do
audio-based timing* because they don't deal with audio. any program
that does its own audio output or input in small fragments has its own
built-in source of precise timing, but not every interesting program
works that way.

--p

From - Fri Oct 29 11:24:52 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA28139
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 22:16:43 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA01456 for linux-audio-dev-list; Wed, 27 Oct 1999 20:55:44 -0400
Received: from anime.net (anime.net [205.139.105.150]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA01452 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 20:55:41 -0400
Received: from localhost (goemon@localhost)
	by anime.net (8.9.3/8.9.3) with ESMTP id RAA21132;
	Wed, 27 Oct 1999 17:50:08 -0700
Date: Wed, 27 Oct 1999 17:50:08 -0700 (PDT)
From: Dan Hollis <goemon@sasami.anime.net>
X-Sender: goemon@anime.net
To: Paul Barton-Davis <pbd@Op.Net>
cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: 4D-NXs (was Re: Sync Issues) 
In-Reply-To: <199910280036.UAA15379@renoir.op.net>
Message-ID: <Pine.LNX.4.10.9910271738270.21037-100000@anime.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 881fd5259ce242242022496903c90211

On Wed, 27 Oct 1999, Paul Barton-Davis wrote:
> >Still irrelevant to the *statement being made*, which is "*we* dont have
> >enough programmers to do that". Why has the number of programmers *they*
> >have, have anything to do with us volunteers writing a driver for them for
> >free? *boggle*.
> they don't *want* volunteers writing drivers for them. period. end of story.

If thats what they wanted, why didnt they just say it. Stating it that way
is purposely deceitful.

> >No, Yamaha *does* have documentation on the native PCI stuff. They just
> >wont release it.
> i have been told by one senior level management guy at yamaha and one
> senior programming guy from their main japanese plant that there is
> *NO* documentation for the DSP Factory.

I received a statement from one of their japanese engineers that they *do*
have documentation for their native PCI audio block for the YMF724 and
YMF744, but that it was only released to OEMs and hardware integrators.

So we have conflicting statements from the same company. Not too suprising
really.

> >Im more concerned about chip vendors than card manufacturers. If we
> >convince the chip vendor to release docs then theres really nothing a card
> >manufacturer can do to stop us.
> i have the "full specs" to the (ancient) YSS225 FX processor from
> yamaha. its installed on the Tropez+. the specs are useless because it
> has downloaded microcode to set it up, and they only document 5
> microcode programs. Yamaha wrote a special one for Turtle Beach, and
> neither they nor Yamaha appear have any record of what it used the dsp
> memory locations for.
> i've used dosemu to decode part of it, and reverse engineered the
> windows FX driver too, but the end result is a GUI with 512 buttons
> that inc/dec values in a DSP location to let me try to understand what
> it does. since many memory locations' function is tightly coupled with
> several others, its a pretty hopeless case. i did manage to find where
> the global stereo echo delay time was set, but that was all.
> you could argue that this means that we don't have the specs, but
> Yamaha certainly doesn't see it that way.

Well one would have to weigh the effort of reverse engineering it against
the gains. Is there any point reverse engineering such ancient hardware?
Compared to eg reverse engineering the emu10k or aureal chips.

FWIW the SAM9407 documentation was pretty inadequate but gerd rausch
managed to come up with a pretty decent driver anyway.

-Dan

From - Fri Oct 29 11:24:43 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA22038
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 21:33:27 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA01363 for linux-audio-dev-list; Wed, 27 Oct 1999 20:04:40 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA01360 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 20:04:38 -0400
Received: from someip.ppp.op.net (d-bm3-00.ppp.op.net [209.152.194.64]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id TAA12551; Wed, 27 Oct 1999 19:59:07 -0400 (EDT)
Message-Id: <199910272359.TAA12551@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: 4D-NXs (was Re: Sync Issues) 
In-reply-to: Your message of "Wed, 27 Oct 1999 13:06:30 PDT."
             <Pine.LNX.4.10.9910271303020.17269-100000@anime.net> 
Date: Wed, 27 Oct 1999 20:54:57 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: debe860061b9a022eee5c55887a10a24

>>       * "we don't have enough programmers to do that"
>
>If the drivers are being written for them by volunteers, I dont see how
>this is relevant.

if they had a driver written for them by 4Front, and it had problems,
their desire to have volunteers do another one is low. i won't name
the company that had this problem, but they are a real soundcard company.

>>       * "we don't have any written documentation to give you guys -
>>          we wrote the driver by having the software group sit in with
>> 	 the hardware group"
>
>This should be a warning sign to anyone thinking of purchasing their
>hardware. If a company cant be bothered to internally document the
>hardware, what happens if key engineers leave the company? Oh dear, their
>project is *permanently screwed*, which means zero support for end users.
>This is no way to run a company.

Yamaha (the company that this quote comes from) seems to be doing
quite well :)

>Uh, isnt this what patents are for? If someone reverse engineers their
>card, they are *completely screwed* unless they have patent protection.

and the cost of a patent is ? look, there's very little truly clever
stuff in these cards, and what is patented is often stupid (est told
me last week about someone who has patented putting an LFO in hardware
on a soundcard with a wavetable synth). most soundcard technologies
don't last more than a few years, and investing the X-thousand dollars
in seeking patent protection for a nifty hack that will be irrelevant
in that time is pretty unjustifiable for most things. security for
obscurity really does work when you only want it for a little while ;)

i think david's point is an important one that i didn't mention, and
he's right that the only thing, in the end, that most of the companies
are going to respond to is more than a couple of studios saying "we
run linux - we want to buy your cards/devices and there are no drivers".

From - Fri Oct 29 11:24:44 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA22235
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 21:35:21 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA01390 for linux-audio-dev-list; Wed, 27 Oct 1999 20:12:57 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA01387 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 20:12:55 -0400
Received: from someip.ppp.op.net (d-bm3-00.ppp.op.net [209.152.194.64]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id UAA13182; Wed, 27 Oct 1999 20:07:22 -0400 (EDT)
Message-Id: <199910280007.UAA13182@renoir.op.net>
To: est@hyperreal.org
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: rtcd vs hz > 100! 
In-reply-to: Your message of "Wed, 27 Oct 1999 13:04:25 PDT."
             <19991027200426.9550.qmail@hyperreal.org> 
Date: Wed, 27 Oct 1999 21:03:12 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: e4136f94b2959a820de2107f895c6a9e

>Hmm!  I'm worried that milliseconds may end up too constraining.
>Also, one-shots with absolute times seems more reliable to me since it
>factors out the time to get the request to rtcd.

but for periodic clients, that is almost completely irrelevant: they
will set themselves up for rtc notifications just before they "hunker
down for the long haul" - any delay in sending the request happens
only once. if the interval is large, there will be no effect at
all. if the interval is small, they might take a hit for the the first
notification.

as for milliseconds, i'm not stuck on them. reasonably long durations
happen to fit into a 32 bit integer. we could use timespec for the
interval too - thats fine. gets rid of the union too - oh, how i miss
anonymous unions in C, just another reason to love C++ :)

>There's one idea I'm afraid to mention since I think *you'll* probably
>want it! :)  rtcd could (optionally) signal pthread condition variables
>in shared memory.

not me! the overhead for handling a condition variable is quite a bit
higher, since it involves sending a signal, and a (pthread-internal)
signal handler on the other end deciding what to do. 


From - Fri Oct 29 11:24:47 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA25381
	for <slinkp@ulster.net>; Wed, 27 Oct 1999 21:57:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA01429 for linux-audio-dev-list; Wed, 27 Oct 1999 20:42:31 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA01426 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 20:42:28 -0400
Received: from someip.ppp.op.net (d-bm3-00.ppp.op.net [209.152.194.64]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id UAA15379; Wed, 27 Oct 1999 20:36:54 -0400 (EDT)
Message-Id: <199910280036.UAA15379@renoir.op.net>
To: Dan Hollis <goemon@sasami.anime.net>
cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: 4D-NXs (was Re: Sync Issues) 
In-reply-to: Your message of "Wed, 27 Oct 1999 17:23:13 PDT."
             <Pine.LNX.4.10.9910271712030.20764-100000@anime.net> 
Date: Wed, 27 Oct 1999 21:32:44 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: e1c4992ff9175343afbef1f09d30df1c

>Still irrelevant to the *statement being made*, which is "*we* dont have
>enough programmers to do that". Why has the number of programmers *they*
>have, have anything to do with us volunteers writing a driver for them for
>free? *boggle*.

they don't *want* volunteers writing drivers for them. period. end of story.

>No, Yamaha *does* have documentation on the native PCI stuff. They just
>wont release it.

i have been told by one senior level management guy at yamaha and one
senior programming guy from their main japanese plant that there is
*NO* documentation for the DSP Factory.

>Im more concerned about chip vendors than card manufacturers. If we
>convince the chip vendor to release docs then theres really nothing a card
>manufacturer can do to stop us.

i have the "full specs" to the (ancient) YSS225 FX processor from
yamaha. its installed on the Tropez+. the specs are useless because it
has downloaded microcode to set it up, and they only document 5
microcode programs. Yamaha wrote a special one for Turtle Beach, and
neither they nor Yamaha appear have any record of what it used the dsp
memory locations for.

i've used dosemu to decode part of it, and reverse engineered the
windows FX driver too, but the end result is a GUI with 512 buttons
that inc/dec values in a DSP location to let me try to understand what
it does. since many memory locations' function is tightly coupled with
several others, its a pretty hopeless case. i did manage to find where
the global stereo echo delay time was set, but that was all.

you could argue that this means that we don't have the specs, but
Yamaha certainly doesn't see it that way.

--p

From - Fri Oct 29 11:26:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA11358
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 00:29:13 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA01634 for linux-audio-dev-list; Wed, 27 Oct 1999 22:53:37 -0400
Received: from zhora.replicant.apana.org.au (replicant.apana.org.au [203.12.238.34]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA01631 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 27 Oct 1999 22:53:09 -0400
Received: (from smap@localhost)
	by zhora.replicant.apana.org.au (8.8.5/8.8.5) id MAA02681;
	Thu, 28 Oct 1999 12:40:14 +1000
Received: from hexdance.replicant.apana.org.au(192.168.200.126) by zhora.replicant.apana.org.au via smap (V1.3)
	id xma002674; Thu, 28 Oct 99 12:39:45 +1000
Received: (from jlittler@localhost)
	by localhost.localdomain (8.9.3/8.9.3) id MAA01024;
	Thu, 28 Oct 1999 12:46:36 +1000
Date: Thu, 28 Oct 1999 12:46:35 +1000
From: John Littler <linuxmusic@crosswinds.net>
To: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: 4D-NXs (was Re: Sync Issues)
Message-ID: <19991028124635.A982@localhost.localdomain>
Mail-Followup-To: linux-audio-dev@ginette.musique.umontreal.ca,
	linux-sound@vger.rutgers.edu
References: <Pine.LNX.4.10.9910271303020.17269-100000@anime.net> <199910272359.TAA12551@renoir.op.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
In-Reply-To: <199910272359.TAA12551@renoir.op.net>; from Paul Barton-Davis on Wed, Oct 27, 1999 at 08:54:57PM -0400
X-Mailer: Mutt http://www.mutt.org/
X-URL: http://linuxmusic.cjb.net/
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: cc43a97907213d6c2c4adbb10b6d1e75

 Paul Barton-Davis spake thusly<pbd@Op.Net>:
[x] 
> i think david's point is an important one that i didn't mention, and
> he's right that the only thing, in the end, that most of the companies
> are going to respond to is more than a couple of studios saying "we
> run linux - we want to buy your cards/devices and there are no drivers".

That's one thing altho they're more likely to be saying "we want to run
linux because ..." - anyone running linux right now in a professional
studio in other than an experimental way would be thought to be out of
their minds given that travelling engineers/producers expect to see
the familiar software "faces".

IMHO the greatest hope we have for the near term for software
anyway is Fear! If Cubase thinks Logic is doing a port or visa versa,
they'll be off and running. I suspect that some high-end sound card drivers
would follow on this. 

New killer apps in Linux audio software could drive this too but I
think the process would take longer - the software has to get out
there, be recognised for what it is, be talked about etc.

I think a survey is in order! - software and drivers...
asking what stage they're at with linux. Something like ...

-eh? what's Linux?
-we're keeping a close eye on Linux developments
-we're doing a feasability study
-we're working on a port right now
-it's out next week!

Anyone who has particular people they'd like to see surveyed
please email me... Likewise anyone with relevant email addresses that get
to real people. I'll put the results up on Linux MusicStation
including those who didn't answer. 
tt
John

-- 
http://linuxmusic.cjb.net

From - Fri Oct 29 11:26:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA08173
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 11:56:02 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA01343 for linux-audio-dev-list; Thu, 28 Oct 1999 10:29:22 -0400
Received: from localhost.localdomain ([212.11.71.81]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA06768 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 09:33:52 -0400
Received: from localhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with SMTP id LAA00575;
	Thu, 28 Oct 1999 11:49:51 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Billy Biggs <vektor@DIV8.NET>, Paul Barton-Davis <pbd@Op.Net>
Subject: [linux-audio-dev] Re: Sync Issues (was Re: External MIDI Sync using OSS/Free)
Date: Thu, 28 Oct 1999 11:22:50 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
References: <Pine.LNX.3.96.991026165644.6242A-100000@vektor.div8.net>
In-Reply-To: <Pine.LNX.3.96.991026165644.6242A-100000@vektor.div8.net>
MIME-Version: 1.0
Message-Id: <99102811495100.00556@localhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 3080b905714af39e9e5f26210746d81a

On Tue, 26 Oct 1999, Billy Biggs wrote:
> On Tue, 26 Oct 1999, Paul Barton-Davis wrote:
>   I was using O_RDWR | O_NONBLOCK, under a 2.2 kernel.  I was trying to do
> drumrolls, 16th notes, at 140bpm or 150bpm.  It was no good.

hmmm, really strange:
I wrote a little util called mididelay, which writes a note-on MIDI message on
the midi-out port reads back the message and measures the delay.
Paul got about 1.1ms delay ( = MIDI wire speed = 3 bytes x 350usecs )
on his box:  soundcard 4DNx + ALSA drivers)
I got a bad 11ms on my SB AWE64, and that is because the AWE64 doesn't
have a TX irq and ad FIFO of only 2byte = driver wroks in polling mode
 bad response times + high CPU usage, that means
forget this card for outputting dense MIDI streams.

BTW: which card are you using ?

>   One requirement for ttrk was that it be able to trigger samples on beat,
> in sync with incomming MIDI.  This is a pain in the ass, since I have to
> know exactly where in the audio output I am in order to do the prediction
> correctly.  The clock on (at least the OSS) /dev/dsp is no good, since it
> gives you no indication of when underruns occur.

I'd suggest to use the raw /dev/dsp and the raw /dev/midi interface:
use 2 threads: higher pri for audio, lower pri for midi
use a small fragmentsize x fragmentnum ,
( for example 3 x 256bytes = 4.3ms audio buffer)
then use the PCM playing thread as timer source ( 1.45ms accuracy in this case)
and simply wakeup the MIDI thread (via fifos/semaphore/msgqueues etc) from
the audio theread when you want to send data to MIDI out.
When data comes from MIDI in, put this in a queue ( msgsnd() , or use shmem )
and let the audio thread react on this on the next fragment,
(if you need sample accurate MIDI/audio sync, that is another story .. ).

Do not forget to apply the lowlatency patches, or your timing will simply suck !
even an untuned IDE disk, when it reads/writes a small amount of data from/to
the disk, could cause 20-50ms delay in your app and this is very bad
for MIDI.
( see my tests , especially the non DMA ones = horrible  :-)   ) 

> 
>   Damn annoying.

I think our collective timing/latency annoyance will go away with kernel 2.4,
mainly thanks to Ingo for his excellent work !
:-)

> 
>   I currently have ttrk setup to just 'turn on' the sample as soon as it
> sees the corresponding MIDI sync tick.  It's no good for drum samples or
> loops or anything, but I can trigger cheezy sci-fi samples and they don't
> sound _too_ out of place.  Ugh.

That is the precise reason why we are trying to put toghether the
realtime multimedia API (provided that the kernel delivers good timing
out of the box = kernel 2.4).
No worries anymore, and the system will always choose the optimal
way to transfer data/provide timing information and minimize scheduling
overhead.

> 
> > >  What about syncing multiple soundcards?  I've found this to be next to
> > >impossible under thud using OSS.
> > 
> > as has been discussed here a number of times, this is far from
> > trivial. clock rates from card to card, even the same brand, and even
> > from (warm) day to (cold) day vary, so its not just a matter of
> > finding a way to get them to all start at the same time. 

yes, this is far from trivial, but we will try to provide some usable solution:
mainly activating the cards by using DSP_SET_TRIGGER (if supported,
otherwise it's a real pain),  to minimize starting delays,
and then use one of the soundcards as source (or alternatively other
timer sources), and put the remaining cards into a "slave" mode,
where you measure the sample differences in audio buffers, and
insert additional or drop samples to keep things in sync.

> 
>   Yes, it is a pain, but there should be a better hacked job at least of
> doing it.  When I still had Windows around, Sonic Foundry ACID had no
> trouble at least faking some sync between my two AudioPCI cards.  I can't
> get it as good as they did. :/

You will
> 
>   There should also be API support for it.  I hope to soon (within the
> next year) get a soundcard that has multiple dsps inside it, for
> outputting multi-track stuff.  I'm really worried about how much I'm going
> to have to code myself though.....

Agreed,
I hope that an usable API/engine shows up during the next 6-9months.

I tested the peroformace of most subsystems of linux (involved in realtime
multimedia), and it seems that it is ready for our highend requirements.

Benno.


> 
> --
> Billy Biggs                         vektor@div8.net
> http://www.div8.net/billy       wbiggs@uwaterloo.ca

From - Fri Oct 29 11:26:27 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA05360
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 11:37:17 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA01183 for linux-audio-dev-list; Thu, 28 Oct 1999 10:14:37 -0400
Received: from chekov.Belgium.EU.net (chekov.belgium.eu.net [193.74.208.161]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA06773 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 09:34:55 -0400
Received: from (adial175.liege.eunet.be [195.207.174.175])
	by chekov.Belgium.EU.net  with SMTP id PAA10702 
	for <linux-audio-dev@ginette.musique.umontreal.ca>;
	Thu, 28 Oct 1999 15:29:18 +0200 (MET DST)
Subject: Re: [linux-audio-dev] Re: 4D-NXs (was Re: Sync Issues) 
From: Benjamin GOLINVAUX <golinvaux@benjamin.net>
Reply-To: Benjamin GOLINVAUX <golinvaux@benjamin.net>
In-Reply-To: <199910272359.TAA12551@renoir.op.net>
Message-ID: <000357f093c40938_mailit@relay.eunet.be>
References: <199910272359.TAA12551@renoir.op.net>
Date: Thu, 28 Oct 1999 15:01:52 +0200
X-Mailer: BeatWare Mail-It 2.0.3
X-BeOS-Platform: Intel or clone
X-Priority: 3 (Normal)
To: linux-audio-dev@ginette.musique.umontreal.ca
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 38b26feb0930afe765560a127193b011

>>This should be a warning sign to anyone thinking of purchasing their
>>hardware. If a company cant be bothered to internally document the
>>hardware, what happens if key engineers leave the company? Oh dear, their
>>project is *permanently screwed*, which means zero support for end users.
>>This is no way to run a company.
>
>Yamaha (the company that this quote comes from) seems to be doing
>quite well :)

If I recall correctly, they said they didn't have written docs IN ENGLISH but
in japanese well (that was in the Big Letter Campaign for DSP factory driver, 
isn't it ?).

>in that time is pretty unjustifiable for most things. security for
>obscurity really does work when you only want it for a little while ;)

It sometimes lasts longer... Coca Cola has not patented recipe. They simply
keep the secret well hidden.

BTW, Did pepsi successfully reverse-engineer a Coke can  ? I don't think 
so...
I still prefer Coke (Well in the US Pepsi's number one, is that right ?).



Benj-a


From - Fri Oct 29 11:26:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA08508
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 11:58:03 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA06658 for linux-audio-dev-list; Thu, 28 Oct 1999 08:31:17 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA06655 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 08:31:15 -0400
Received: from someip.ppp.op.net (d-bm3-00.ppp.op.net [209.152.194.64]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id IAA23191; Thu, 28 Oct 1999 08:25:34 -0400 (EDT)
Message-Id: <199910281225.IAA23191@renoir.op.net>
To: alsa-devel@alsa-project.org
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: [alsa-devel] Timestamping 
In-reply-to: Your message of "Thu, 28 Oct 1999 06:35:56 +0200."
             <3817D2AC.2BE97335@netway.at> 
Date: Thu, 28 Oct 1999 09:21:31 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 2df7f97003f0683f41364e08568ba66a

>I'm one of the guys working on the V4L2 project
>http://millennium.diads.com/bdirks/v4l2.htm. Kernel timestamping is
>a core feature of V4L2 and referencing a global system clock turned
>out most flexible. But it has been argued system time as returned by
>the gettimeofday function is not guaranteed to increase monotonically.
>
>Since we want to do the right thing(TM) we consider an implementation
>similar to SGI's Unadjusted System Time clock, see
>http://millennium.diads.com/mschimek/ust for a brief discussion.
>
>What do you think about UST support for ALSA?

what do *i* think ? from reading the IRIX documentation, it makes me
want to go out, dump my Linux kernel, and run IRIX forever more.

the sooner we have the kind of support that is described in the SGI
documentation, the better. anyone with any experience working with
audio and/or video knows that this stuff is critical for professional
results, and i suspect that its the kind of thing that continues to
make SGI a darling of the video editing world.

everyone on linux-audio-dev should read the SGI docs referenced at

	 http://millennium.diads.com/mschimek/ust

i am a little sceptical of SGI's implementation, however - its not
clear whether they are doing kernel/driver timestamping or
inferencing. also, the fact that you cannot use read(2)/write(2)
anymore is always a negative from my perspective, but hey, alsa-lib
challenges that model already. i will just be sad to have to abandon
read/write for MIDI in order to get timestamps, but i see no other way
of doing it. 

i am very intrigued by their description of when the timestamp is done
for audio. they claim to timestamp analog data at "the instant the
voltage is sampled or produced" and digital data at the "edge of the
recovered sample clock from the input signal or the driving sample
clock for the output signal".

do we have any hope of doing this ? does SGI ? :)

--p

From - Fri Oct 29 11:26:28 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA06651
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 11:46:10 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA06667 for linux-audio-dev-list; Thu, 28 Oct 1999 08:36:36 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA06664 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 08:36:34 -0400
Received: from someip.ppp.op.net (d-bm3-00.ppp.op.net [209.152.194.64]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id IAA23589; Thu, 28 Oct 1999 08:30:59 -0400 (EDT)
Message-Id: <199910281230.IAA23589@renoir.op.net>
To: Dan Hollis <goemon@sasami.anime.net>
cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: 4D-NXs (was Re: Sync Issues) 
In-reply-to: Your message of "Wed, 27 Oct 1999 17:50:08 PDT."
             <Pine.LNX.4.10.9910271738270.21037-100000@anime.net> 
Date: Thu, 28 Oct 1999 09:26:56 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: c4e1740014861ca5efad82153f98dd80

>> >Still irrelevant to the *statement being made*, which is "*we* dont have
>> >enough programmers to do that". Why has the number of programmers *they*
>> >have, have anything to do with us volunteers writing a driver for them for
>> >free? *boggle*.
>> they don't *want* volunteers writing drivers for them. period. end of story.
>
>If thats what they wanted, why didnt they just say it. Stating it that way
>is purposely deceitful.

the fault is more likely in my wording of it. i wasn't trying to quote
directly. the company concerned has just been burned by having a 3rd
party write drivers for it. i don't think they were deceitful with me,
i just didn't present a very accurate picture of what they said.

>Well one would have to weigh the effort of reverse engineering it against
>the gains. Is there any point reverse engineering such ancient hardware?
>Compared to eg reverse engineering the emu10k or aureal chips.

what do you think the expected lifetime of any of the current
generation of chips is, given how long every previous equivalent has
lasted ? if we're reverse engineering a chip more than 18mths after
its first use in a PC soundcard, i'd say we might well be wasting our
time, in the long haul.

>FWIW the SAM9407 documentation was pretty inadequate but gerd rausch
>managed to come up with a pretty decent driver anyway.

well, mine works just fine. its just that the non-linear relationships
between the memory locations on the DSP make it more or less useless
to try to use the driver to alter the operation of the downloaded
microprogram unless you're interested in random FX :) instead, you get
the DSP in something close to passthru mode.

--p

From - Fri Oct 29 11:26:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA14244
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 12:33:15 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA01387 for linux-audio-dev-list; Thu, 28 Oct 1999 10:49:23 -0400
Received: from shell.dhp.com (shell.dhp.com [199.245.105.1]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA01384 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 10:49:20 -0400
Received: by shell.dhp.com (Postfix, from userid 668)
	id 6D3761ABD2; Thu, 28 Oct 1999 09:47:52 -0400 (EDT)
Date: Thu, 28 Oct 1999 09:47:52 -0400 (EDT)
From: Billy Biggs <vektor@DIV8.NET>
To: Benno Senoner <sbenno@gardena.net>
Cc: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca,
        linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: Sync Issues (was Re: External MIDI Sync using OSS/Free)
In-Reply-To: <99102811495100.00556@localhost.localdomain>
Message-ID: <Pine.LNX.4.04.9910280938390.31398-100000@shell.dhp.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: c17e600cffb6a3dafecda466c749dff5

Benno, you kick ass,

> >   I was using O_RDWR | O_NONBLOCK, under a 2.2 kernel.  I was trying to do
> > drumrolls, 16th notes, at 140bpm or 150bpm.  It was no good.
> 
> hmmm, really strange:
> I wrote a little util called mididelay, which writes a note-on MIDI message on
> the midi-out port reads back the message and measures the delay.

  Can I get a copy of this program?  Are you just using gettimeofday()
before and after, or are you using ptrace or some other hackery?

> BTW: which card are you using ?

  For MIDI I'm using a Roland MPU-IPC-T card.  MPU-401.

> >   One requirement for ttrk was that it be able to trigger samples on beat,
> 
> I'd suggest to use the raw /dev/dsp and the raw /dev/midi interface:
> [...]

  Thanks for your suggestions.  I'm hacking at it now...

> Do not forget to apply the lowlatency patches, or your timing will
> simply suck ! even an untuned IDE disk, when it reads/writes a small
> amount of data from/to the disk, could cause 20-50ms delay in your app
> and this is very bad for MIDI. ( see my tests , especially the non DMA
> ones = horrible :-)  )

  What lowlatency patches??  kernel patches??  That's just ugly.  Where
can I get them?

> > > >  What about syncing multiple soundcards?
> 
> yes, this is far from trivial, but we will try to provide some usable
> solution: mainly activating the cards by using DSP_SET_TRIGGER (if
> supported, otherwise it's a real pain), to minimize starting delays,
> and then use one of the soundcards as source (or alternatively other
> timer sources), and put the remaining cards into a "slave" mode, where
> you measure the sample differences in audio buffers, and insert
> additional or drop samples to keep things in sync.

  How can you tell if you've underrun under OSS?  Using ALSA, I guess you
can use it's time stuff to calculate if you've missed a frame, but even
that seems hacky.

  Do you just always use gettimeofday() math to keep track of how much
stuff you've written, and when skips have occured?

  I don't like using one dsp as the sync master since I always want to be
able to sync to something external, like MIDI.

  So, the problem becomes, how do you sync many soundcards and have it all
synced off external MIDI. :)

--
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

From - Fri Oct 29 11:26:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA13704
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 12:29:39 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA01403 for linux-audio-dev-list; Thu, 28 Oct 1999 11:04:43 -0400
Received: from shell.dhp.com (shell.dhp.com [199.245.105.1]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA01400 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 11:04:41 -0400
Received: by shell.dhp.com (Postfix, from userid 668)
	id 6FBB11AB93; Thu, 28 Oct 1999 10:59:07 -0400 (EDT)
Date: Thu, 28 Oct 1999 10:59:07 -0400 (EDT)
From: Billy Biggs <vektor@DIV8.NET>
To: Paul Barton-Davis <pbd@Op.Net>
Cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: Sync Issues (was Re: External MIDI Sync using OSS/Free) 
In-Reply-To: <199910281443.KAA08288@renoir.op.net>
Message-ID: <Pine.LNX.4.04.9910281054160.1115-100000@shell.dhp.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 543f385a8360998ec0bea04ca3e4479d

On Thu, 28 Oct 1999, Paul Barton-Davis wrote:

> no, ALSA has an ioctl to tell you if had underruns or overruns. its
> The Right Way (TM). OTOH, i haven't written any audio programs that
> ever use it, because I write them so that if I did have an
> {over,under}run, it would mean that some totally catastrophic has
> happened. maybe i don't write the right kinds of applications :)

  How can you get close to that?  Do you always set realtime priority?  I
get underruns happening when I move the mouse, depending on system load,
even when the app is setuid root.

  Am I unique in that my apps never seem to be able to keep up?

> >  I don't like using one dsp as the sync master since I always want to be
> >able to sync to something external, like MIDI.
> 
> if you mean MTC, this simply isn't accurate enough for syncing
> soundcards. [...]
> 
> so, i don't think you can "sync soundcards" from MIDI. You can use MTC
> to help inform your own sense of the forward passage of time and to
> dictate MIDI-related tempo, but thats not the same thing that Benno
> was talking about.

  Right, I was being confusing.

  I'm not actually talking about MTC, I'm talking about counting 24ppq
sync pulses and predicting pulses, keeping in sync with them as much as
possible.  Pretty bad.

  So, it is still ncessary to keep the soundcards in sync with each other,
then have some objective sense of where in time the audio buffer is such
that I can tell the card the right thing to play at the time.

--
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

From - Fri Oct 29 11:26:34 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA13236
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 12:26:40 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA01379 for linux-audio-dev-list; Thu, 28 Oct 1999 10:48:52 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA01376 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 10:48:50 -0400
Received: from someip.ppp.op.net (d-bm3-12.ppp.op.net [209.152.194.82]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id KAA08288; Thu, 28 Oct 1999 10:43:16 -0400 (EDT)
Message-Id: <199910281443.KAA08288@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: Sync Issues (was Re: External MIDI Sync using OSS/Free) 
In-reply-to: Your message of "Thu, 28 Oct 1999 09:47:52 EDT."
             <Pine.LNX.4.04.9910280938390.31398-100000@shell.dhp.com> 
Date: Thu, 28 Oct 1999 11:39:14 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 204a4fc3b0eaf5b0e78dc0beb1fcf450

>  What lowlatency patches??  kernel patches??  That's just ugly.  Where
>can I get them?

not ugly! the kernel folks, well Ingo Molnar in particular, recognized
that the kernel wasn't well tuned for low latency requirements. Ingo
believes that his patches will be in kernel 2.4.

look at http://www.gardena.net/benno/linux/audio for more details.

>  How can you tell if you've underrun under OSS?  Using ALSA, I guess you
>can use it's time stuff to calculate if you've missed a frame, but even
>that seems hacky.

no, ALSA has an ioctl to tell you if had underruns or overruns. its
The Right Way (TM). OTOH, i haven't written any audio programs that
ever use it, because I write them so that if I did have an
{over,under}run, it would mean that some totally catastrophic has
happened. maybe i don't write the right kinds of applications :)

>  I don't like using one dsp as the sync master since I always want to be
>able to sync to something external, like MIDI.

if you mean MTC, this simply isn't accurate enough for syncing
soundcards. you can use MTC as a master clock for tempo, but between
MIDI clock messages you will still have to be prepared to do the
actual syncing of soundcards. Given that a MTC messages take on the
order of 1ms to arrive (!), its not a high-quality sync source.

so, i don't think you can "sync soundcards" from MIDI. You can use MTC
to help inform your own sense of the forward passage of time and to
dictate MIDI-related tempo, but thats not the same thing that Benno
was talking about.

--p

From - Fri Oct 29 11:26:44 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA27206
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 14:03:51 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA01532 for linux-audio-dev-list; Thu, 28 Oct 1999 11:59:24 -0400
Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA01529 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 11:59:21 -0400
Received: from parabola.demon.co.uk ([212.228.182.246] helo=ariel.sr.home)
	by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1)
	id 11grrx-000OHy-0A
	for linux-audio-dev@ginette.musique.umontreal.ca; Thu, 28 Oct 1999 15:53:42 +0000
Received: (from steve@localhost)
	by ariel.sr.home (8.8.7/8.8.7) id QAA11833
	for linux-audio-dev@ginette.musique.umontreal.ca; Thu, 28 Oct 1999 16:55:36 +0100
Date: Thu, 28 Oct 1999 16:55:36 +0100
From: Steve Ratcliffe <steve@parabola.demon.co.uk>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: rtcd vs hz > 100!
Message-ID: <19991028165536.B11787@parabola.demon.co.uk>
Mail-Followup-To: linux-audio-dev@ginette.musique.umontreal.ca
References: <19991027200426.9550.qmail@hyperreal.org> <199910280007.UAA13182@renoir.op.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <199910280007.UAA13182@renoir.op.net>; from pbd@Op.Net on Wed, Oct 27, 1999 at 09:03:12PM -0400
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d5dd31be8881f1be27a1790777eb7b3e


For those using ALSA, you can already do this without a user daemon.
The timer interface allows more than one process to access the same timer,
there is a user interface via open/read of /dev/snd/timer and a kernel
interface so that the sequencer can be driven from a better clock than
the 10ms system timer.  I have a demo timer module that uses the RTC as
a loadable ALSA timer.

As I write this I have two processes reading from the timer being
woken up each 1ms, printing out when they are woken up late because of
bad latencies.  At the same time the clock is being used to drive the
sequencer at 1ms resolution.  The timers can be run at different rates
(although this may not work with my demo code).

..Steve

From - Fri Oct 29 11:26:37 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA13971
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 12:31:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA01444 for linux-audio-dev-list; Thu, 28 Oct 1999 11:09:23 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA01441 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 11:09:21 -0400
Received: from someip.ppp.op.net (d-bm3-12.ppp.op.net [209.152.194.82]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id LAA10749; Thu, 28 Oct 1999 11:03:46 -0400 (EDT)
Message-Id: <199910281503.LAA10749@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: Re: [linux-audio-dev] Re: HZ > 100 overhead 
In-reply-to: Your message of "Thu, 28 Oct 1999 02:16:29 +0200."
             <9910280239410C.00611@localhost.localdomain> 
Date: Thu, 28 Oct 1999 11:59:44 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 59e8474054fbe16671f74ef37921b2bf


>Of course I agree, that you are not forced to run the audio server
>all the time.  Do you remember the discussion some time ago ?  "the
>client can access the device directly or use the audio server" "the
>client can do his own plugin hosting, or delegate the hosting to the
>audio server"
>
>In the case of the timer I'd opt for a similar solution.
>
>( note that in my case the rtcd is a subsystem of the audio (or better
>multimedia) engine )

thats my problem. the services offered by Eric's proposed rtcd are at
a level *below* those offered by the system we've talked about. that
is, the functionality derived from using the RTC is something that
might be used by a multimedia server (which, BTW, is very importantly
NOT the same thing as an engine) *and* an application which doesn't
use the server at all. simultaneously.

take a system in which, say, Quasimodo was running through the server
or was the server and SoftWerk ran along side it. SoftWerk doesn't
talk to the audio h/w at all, but it wants timing from the RTC. the
server might want timing from the RTC. a 3rd program runs and wants to
to use the RTC for something completely non-audio related.

in these kinds of situations, you don't want to have merged RTC
service into an "multimedia server" - someone who wants to use the RTC
for something completely different is going to be unhappy at being
forced to connect to the multimedia server if the server is running
(and thus owns the RTC).

that's why I think that the RTC *must* be considered a standalone
system utilized either by a single (greedy) application, or by a
server *that does nothing else* but distribute timing info to clients.

>IMHO the advantage to integrate the rtcd into the multimedia engine
>(which of course works on machines without soundcards) , is that 
>the system can optimize things when multiple timer sources are available.

you can still do this: rtcd is, in your words, just another timer source.

>We could even provide a way where the client "hosts" the timer in his own
>thread, (like by your SIGIO notification), or by simply providing an RTC
>wrapper, but with an uniform API.
>That means if you run your Softwerk sequencer standalone (using the MIDI
>device / timers  directly  (in this case the timer is managed though the
>wrapper) ) ,

yuck. just have everyone use the daemon or the device itself if there
is no daemon, and we have an even more flexible situation. surely ?

--p

From - Fri Oct 29 11:26:42 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA22480
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 13:32:56 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA01575 for linux-audio-dev-list; Thu, 28 Oct 1999 12:12:30 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id MAA01572 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 12:12:28 -0400
From: est@hyperreal.org
Received: (qmail 24234 invoked by uid 162); 28 Oct 1999 16:06:55 -0000
Message-ID: <19991028160655.24233.qmail@hyperreal.org>
Subject: [linux-audio-dev] oolaboola extensibility to the rescue
To: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Date: Thu, 28 Oct 1999 09:06:55 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: c1053b018f4c1432a70676297e8eb8ee

It's nice when, occasionally, something just works easily. :)

I've been transcribing an interview and finding my microcasette
recorder quite cumbersome to use.  I realized that a traditional
dictaphone setup would be much more productive.  This involves (a)
playing the `tape' while a pedal is depressed and (b) pausing and
backing up a little when it's released.  A MIDI sustain pedal and the
following code in my .oola/rc file created this for me.

dicta_backup = 5

def dicta_control(pn, gop = 0):
  if (gop):
    players[pn].unpause()
  else:
    players[pn].pause()
    players[pn].newpos(players[pn].posf - dicta_backup)

mi.cb['control-change'][1][64] = lambda v: dicta_control(0, v >= 64)

Eric

From - Fri Oct 29 11:26:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA17140
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 12:55:36 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA01465 for linux-audio-dev-list; Thu, 28 Oct 1999 11:22:46 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA01462 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 11:22:44 -0400
Received: from someip.ppp.op.net (d-bm3-12.ppp.op.net [209.152.194.82]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id LAA12294; Thu, 28 Oct 1999 11:17:09 -0400 (EDT)
Message-Id: <199910281517.LAA12294@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: Sync Issues (was Re: External MIDI Sync using OSS/Free) 
In-reply-to: Your message of "Thu, 28 Oct 1999 10:59:07 EDT."
             <Pine.LNX.4.04.9910281054160.1115-100000@shell.dhp.com> 
Date: Thu, 28 Oct 1999 12:13:08 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 158cc86942f0ca8c5d45b47ff6a3163e

In message <Pine.LNX.4.04.9910281054160.1115-100000@shell.dhp.com>you write:
>On Thu, 28 Oct 1999, Paul Barton-Davis wrote:
>
>> no, ALSA has an ioctl to tell you if had underruns or overruns. its
>> The Right Way (TM). OTOH, i haven't written any audio programs that
>> ever use it, because I write them so that if I did have an
>> {over,under}run, it would mean that some totally catastrophic has
>> happened. maybe i don't write the right kinds of applications :)
>
>  How can you get close to that?  Do you always set realtime priority?  I
>get underruns happening when I move the mouse, depending on system load,
>even when the app is setuid root.

*smile* you've got a hardware problem. i know this because i have too :)

when i had to switch (temporarily) from my Matrix G200 AGP video card
to an old ISA-based Diamond Speedstar, the performance of my audio
stuff has gone down the tubes. i can't do *anything* with X and hope
to not get dropouts. this never happened with the Matrox card, and i
am very confident that as soon as Matrox ships me a new one, the
problem will go away.

right now, my system is essentially useless for audio work unless you
avoid using X. totally useless. i can't even play WAV files without
*huge* dropouts, and thats on a *dual* PII-450 !

if i use a text console, things are peachy.

>  I'm not actually talking about MTC, I'm talking about counting 24ppq
>sync pulses and predicting pulses, keeping in sync with them as much as
>possible.  Pretty bad.
>
>  So, it is still ncessary to keep the soundcards in sync with each other,
>then have some objective sense of where in time the audio buffer is such
>that I can tell the card the right thing to play at the time.

either i'm just confused, or you are, or both :)

barring underruns, which (trust me) are a totally separate issue, you
*always* know where you are since you're the one generating the
fragments for the audio buffer. if you asked for 3 fragments, then
other than for the first audio-buffer's worth of stuff (and you
typically fill it with silence when you start to avoid this problem),
you know that when you are working on a particular fragment, there are
2 more ahead of you that have yet to be played.

if you want more precise timing than is implied the fragment size
(which might be in the range of 0.5-2ms), you will need to timestamp
the MIDI messages you receive using, gettimeofday() or a cycle
counter, and do a little math based on the sample rate you configured
the soundcard to use. this way, you can calculate the "exact" sample
that was playing (i.e. emerging on the audio side of a DAC someplace)
when the MIDI message was "received", and then, by knowing how many
fragments are still pending (a fixed number, barring underruns), you
can infer exactly when any output that arises from (or should be
synced to) the MIDI data should emerge.

its pretty simple, really :)

--p

From - Fri Oct 29 11:26:49 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA04510
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 15:09:13 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA01626 for linux-audio-dev-list; Thu, 28 Oct 1999 12:56:14 -0400
Received: from tony.growzone.com.au (south4.lnk.telstra.net [139.130.74.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA01622 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 12:56:00 -0400
Received: (from tony@localhost)
	by tony.growzone.com.au (8.9.3/8.9.3) id CAA16032;
	Fri, 29 Oct 1999 02:14:22 +1000
Message-Id: <199910281614.CAA16032@tony.growzone.com.au>
To: est@hyperreal.org
Cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
X-Face: ]IrGs{LrofDtGfsrG!As5=G'2HRr2zt:H>djXb5@v|Dr!jOelxzAZ`!}("]}]
	Q!)1w#X;)nLlb'XhSu,QL>;)L/l06wsI?rv-xy6%Y1e"BUiV%)mU;]f-5<#U6
	UthZ0QrF7\_p#q}*Cn}jd|XT~7P7ik]Q!2u%aTtvc;)zfH\:3f<[a:)M
Organization: GrowZone OnLine
X-Mailer: nmh-0.27 exmh-2.0.2
X-OS: Linux-2.2.12
X-URL: http://www.growzone.com.au/tony
X-Mailer: nmh-0.27 exmh-2.0.2
X-Linux-Version: 2.0.36
Subject: [linux-audio-dev] Re: pci128 line-in help 
In-Reply-To: message-id <19991027001930.26463.qmail@hyperreal.org> 
	 of Tue, Oct 26 17:19:30 1999
Date: Fri, 29 Oct 1999 02:14:22 +1000
From: Tony Nugent <tony@growzone.com.au>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 3b288f666cfc20800af710fae0f12d26

[why all of a sudden are so many of the messages here also going to a
linux audio list in canada?]

On Tue Oct 26 1999 at 17:19, est@hyperreal.org wrote:

> I can't seem to get my pci128 line-in to work.  This is using the
> (es1370) OSS driver distributed with the 2.2.7 kernel.  I've tried all
> the obvious mixer settings as well as all the private ioctl()s the
> driver has, checked my hardware, etc.  Can anyone think of anything I
> might be missing?

You need to configure the sound driver module when you load it.

%   /sbin/modinfo -p es1370
joystick int array (min = 1, max = 5), description "if 1 enables joystick interface (still need separate driver)"
lineout int array (min = 1, max = 5), description "if 1 the LINE input is converted to LINE out"
micbias int array (min = 1, max = 5), description "sets the +5V bias for an electret microphone"

(btw, default 2.2.12-20 kernel/modules from redhat6.1)

Either pass the relevant parameters on the insmod/modprobe command
line if you (re)load it manually, or put them into /etc/conf.modules

Check the /usr/src/linux/Documentation/sound/ directory for more
information about the parameters... there is a file there specifically
for the es1370 chip.

Cheers
Tony

From - Fri Oct 29 11:26:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA22227
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 13:31:24 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA01570 for linux-audio-dev-list; Thu, 28 Oct 1999 12:12:18 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA01567 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 12:12:14 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m11gsbH-000dxuC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Thu, 28 Oct 1999 18:40:31 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Thu, 28 Oct 1999 18:40:31 +0200 (CEST)
To: "Alessandro Fogar" <mar095k1@ud.nettuno.it>
Cc: "Jaroslav Kysela" <perex@suse.cz>, "Guenter Geiger" <geiger@epy.co.at>,
        "linux-audio-dev" <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Re: 4D-NXs and Hammerfall
In-Reply-To: <001401bf20b7$0a735da0$cb76cfc1@mar095k1>
References: <001401bf20b7$0a735da0$cb76cfc1@mar095k1>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14360.31041.16973.934778@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id NAA22227
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 5614173a19e218579451c80873a8e775

Alessandro Fogar writes:
 > About the drivers for RME Hammerfall, I think that they are available
 > (OSSFree), please ask to Guenter Geiger, Guenter are you reading this ?
 > 

Yes, Im reading ,..

The drivers for the RME Hammerfall are currently neither OSS nor Alsa.
(Well, that was when I saw (heard) them last two weeks ago)
Winfried is trying to put them out in an acceptable format as time
permits.

I will receive such a card (hopefully in a week or so) and can tell
you more about it then.

The problem with Multichannel and trational sound API's is the
enourmous copy overhead when translating from 
interleaved to blocked data. So for reason of speed his driver
currently implements 24 memory mapped like devices. 

Guenter






From - Fri Oct 29 11:26:48 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA02955
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 14:58:32 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA01634 for linux-audio-dev-list; Thu, 28 Oct 1999 12:59:47 -0400
Received: from tango.birch.net (birch.net [209.251.184.60]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA01631 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 12:59:40 -0400
Received: from dustin (host1-175.birch.net [216.212.1.175])
	by tango.birch.net  with SMTP id LAA29270
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 11:54:06 -0500 (CDT)
From: "Dustin Barlow" <dbarlow@omnids.com>
To: <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Low latency patch for 2.2.12-13 ?
Date: Thu, 28 Oct 1999 11:51:47 -0500
Message-ID: <NBBBLDPIAKJHFKEBAIAFAEDDIIAA.dbarlow@omnids.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <199910281443.KAA08288@renoir.op.net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 4c933a585f0714fcc1c6bb5d5b0e6267

Has anyone been able to get the latency patch to work with kernels about
2.2.10?

I get about 80% applied, the rest has errors...

Dustin

From - Fri Oct 29 11:27:01 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA26141
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 17:25:24 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA01798 for linux-audio-dev-list; Thu, 28 Oct 1999 14:14:13 -0400
Received: from gehenna1.rutgers.edu (gehenna1.rutgers.edu [165.230.116.154]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id OAA01795 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 14:14:10 -0400
Received: (qmail 22932 invoked by alias); 28 Oct 1999 18:08:36 -0000
Received: (qmail 22899 invoked from network); 28 Oct 1999 18:08:35 -0000
Received: from truth.rutgers.edu (HELO nbcs.rutgers.edu) (128.6.134.2)
  by gehenna1.rutgers.edu with SMTP; 28 Oct 1999 18:08:35 -0000
Message-ID: <38189123.AA4C7A6A@nbcs.rutgers.edu>
Date: Thu, 28 Oct 1999 14:08:35 -0400
From: Joe Miklojcik <jmik@nbcs.rutgers.edu>
Organization: RUCS/NBCS/SOS/OSS
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Dan Hollis <goemon@sasami.anime.net>
CC: Paul Barton-Davis <pbd@Op.Net>, Billy Biggs <vektor@DIV8.NET>,
        linux-audio-dev@ginette.musique.umontreal.ca,
        linux-sound@vger.rutgers.edu
Subject: Re: [linux-audio-dev] Re: 4D-NXs (was Re: Sync Issues)
References: <Pine.LNX.4.10.9910271303020.17269-100000@anime.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c9d207ecb0b897416ff4bdd12ab11731

Dan Hollis wrote:

> On Wed, 27 Oct 1999, Paul Barton-Davis wrote:
> >       * "we don't have enough programmers to do that"
>
> If the drivers are being written for them by volunteers, I dont see how
> this is relevant.

They just can't imagine anybody who isn't in their shop writing a driver.
It's a really crappy job.

> >       * "we don't have any written documentation to give you guys -
> >          we wrote the driver by having the software group sit in with
> >        the hardware group"
>
> This should be a warning sign to anyone thinking of purchasing their
> hardware. If a company cant be bothered to internally document the
> hardware, what happens if key engineers leave the company? Oh dear, their
> project is *permanently screwed*, which means zero support for end users.
> This is no way to run a company.

I agree.  A couple of years ago, I badgered Opcode into giving me specs for
their 8Port/SE under NDA so I could write a Linux driver for myself.  It
took three passes just to convince them that I could do it if I had the
specs, even if I didn't work in their shop.  It took two more passes to
convince them that I would honor the NDA as I would any other legal
obligation, and that I would furnish any results I gained working with
NDA protected material back to them.  Never mind Open Source, these guys
didn't want me to know their deep dark "how to use a parallel
port" secrets.  Turns out the real reason it was pulling teeth to get their
spec is that the spec revealed how shoddy of an engineering job the 8Port/SE
was.  I wound up destroying the spec and giving the unit to a Windows
sufferer.

>
> >       * "we think our hardware's proprietary secrets will be revealed
> >          if there is a source code driver"
>
> Uh, isnt this what patents are for? If someone reverse engineers their
> card, they are *completely screwed* unless they have patent protection.

Shhh :)  They haven't figured that out yet.  It's the only thing saving us
on a lot of the hardware Linux supports.  I'm not a lawyer, but I think that
they can deny the right to reverse engineer in a user license, which would
make some drivers illegal.  This leads to the silly phrase

"If drivers are outlawed, only outlaws will have drivers."

--
Joe Miklojcik - NBCS System Programmer - http://oss.rutgers.edu
The purpose of computing is insight, not numbers. --Richard W. Hamming, 1962



From - Fri Oct 29 11:26:57 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA18692
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 16:37:00 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA01852 for linux-audio-dev-list; Thu, 28 Oct 1999 14:31:02 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id OAA01849 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 14:31:00 -0400
From: est@hyperreal.org
Received: (qmail 25211 invoked by uid 162); 28 Oct 1999 18:08:46 -0000
Message-ID: <19991028180846.25208.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] Re: rtcd vs hz > 100!
In-Reply-To: <19991028165536.B11787@parabola.demon.co.uk> from Steve Ratcliffe
 at "Oct 28, 1999 04:55:36 pm"
To: Steve Ratcliffe <steve@parabola.demon.co.uk>
Date: Thu, 28 Oct 1999 11:08:46 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: fef7f2bc87b921e120493363e6760826

Steve Ratcliffe discourseth:
> 
> For those using ALSA, you can already do this without a user daemon.
> The timer interface allows more than one process to access the same timer,
> there is a user interface via open/read of /dev/snd/timer and a kernel
> interface so that the sequencer can be driven from a better clock than
> the 10ms system timer.  I have a demo timer module that uses the RTC as
> a loadable ALSA timer.

This sounds better than the rtcd concept.  I'm curious what others
think..and happy I posted a design before coding. :)

Is your module available?

Thanks!

Eric

From - Fri Oct 29 11:27:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA23953
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 17:10:53 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA01831 for linux-audio-dev-list; Thu, 28 Oct 1999 14:20:41 -0400
Received: from anime.net (anime.net [205.139.105.150]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA01828 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 14:20:38 -0400
Received: from localhost (goemon@localhost)
	by anime.net (8.9.3/8.9.3) with ESMTP id LAA31414;
	Thu, 28 Oct 1999 11:14:41 -0700
Date: Thu, 28 Oct 1999 11:14:41 -0700 (PDT)
From: Dan Hollis <goemon@sasami.anime.net>
X-Sender: goemon@anime.net
To: Joe Miklojcik <jmik@nbcs.rutgers.edu>
cc: Paul Barton-Davis <pbd@Op.Net>, Billy Biggs <vektor@DIV8.NET>,
        linux-audio-dev@ginette.musique.umontreal.ca,
        linux-sound@vger.rutgers.edu
Subject: Re: [linux-audio-dev] Re: 4D-NXs (was Re: Sync Issues)
In-Reply-To: <38189123.AA4C7A6A@nbcs.rutgers.edu>
Message-ID: <Pine.LNX.4.10.9910281112270.31385-100000@anime.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 85e01a8d7b33c260bba6d412d504bd3d

On Thu, 28 Oct 1999, Joe Miklojcik wrote:
> > >       * "we think our hardware's proprietary secrets will be revealed
> > >          if there is a source code driver"
> > Uh, isnt this what patents are for? If someone reverse engineers their
> > card, they are *completely screwed* unless they have patent protection.
> Shhh :)  They haven't figured that out yet.  It's the only thing saving us
> on a lot of the hardware Linux supports.  I'm not a lawyer, but I think that
> they can deny the right to reverse engineer in a user license, which would
> make some drivers illegal.

So you reverse engineer them in a country where such shrinkwrap licenses
themselves are illegal. Isnt this most of europe? :)

Isnt there some precedent law in the US which basically says such licenses
are unenforceable?

-Dan

From - Fri Oct 29 11:26:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA17976
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 16:33:07 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA01837 for linux-audio-dev-list; Thu, 28 Oct 1999 14:23:21 -0400
Received: from anime.net (anime.net [205.139.105.150]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA01834 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 14:23:18 -0400
Received: from localhost (goemon@localhost)
	by anime.net (8.9.3/8.9.3) with ESMTP id LAA31457;
	Thu, 28 Oct 1999 11:17:36 -0700
Date: Thu, 28 Oct 1999 11:17:36 -0700 (PDT)
From: Dan Hollis <goemon@sasami.anime.net>
X-Sender: goemon@anime.net
To: Benjamin GOLINVAUX <golinvaux@benjamin.net>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: 4D-NXs (was Re: Sync Issues) 
In-Reply-To: <000357f093c40938_mailit@relay.eunet.be>
Message-ID: <Pine.LNX.4.10.9910281115420.31385-100000@anime.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c0447e76884a019f7861c223ac91a8bb

On Thu, 28 Oct 1999, Benjamin GOLINVAUX wrote:
> >Yamaha (the company that this quote comes from) seems to be doing
> >quite well :)
> If I recall correctly, they said they didn't have written docs IN ENGLISH but
> in japanese well (that was in the Big Letter Campaign for DSP factory driver, 
> isn't it ?).

I have a friend who does computer and technical japanese translations for
a living. Oh dear yamaha's excuse just flew out the window didnt it. :)

-Dan

From - Fri Oct 29 11:26:51 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA11541
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 15:54:46 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA01863 for linux-audio-dev-list; Thu, 28 Oct 1999 14:39:16 -0400
Received: from tango.birch.net (birch.net [209.251.184.60]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA01860 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 14:39:14 -0400
Received: from dustin (host1-175.birch.net [216.212.1.175])
	by tango.birch.net  with SMTP id NAA17466
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 13:33:40 -0500 (CDT)
From: "Dustin Barlow" <dbarlow@omnids.com>
To: <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Latency patch for kernels about 2.2.10?
Date: Thu, 28 Oct 1999 13:31:21 -0500
Message-ID: <NBBBLDPIAKJHFKEBAIAFCEDEIIAA.dbarlow@omnids.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 0da34e7fc223e2c0f58205d480760dfe

Has anyone successfully applied the 2.2.10 latency patch to a kernel higher
than 2.2.10?

Dustin

From - Fri Oct 29 11:26:53 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA12402
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 16:00:30 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA01858 for linux-audio-dev-list; Thu, 28 Oct 1999 14:38:52 -0400
Received: from anime.net (anime.net [205.139.105.150]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA01855 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 14:38:49 -0400
Received: from localhost (goemon@localhost)
	by anime.net (8.9.3/8.9.3) with ESMTP id LAA31617;
	Thu, 28 Oct 1999 11:33:09 -0700
Date: Thu, 28 Oct 1999 11:33:08 -0700 (PDT)
From: Dan Hollis <goemon@sasami.anime.net>
X-Sender: goemon@anime.net
To: Paul Barton-Davis <pbd@Op.Net>
cc: linux-audio-dev@ginette.musique.umontreal.ca, linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: 4D-NXs (was Re: Sync Issues) 
In-Reply-To: <199910281230.IAA23589@renoir.op.net>
Message-ID: <Pine.LNX.4.10.9910281117450.31385-100000@anime.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: c729ccb2ad3a8f724a076e1bd738b755

On Thu, 28 Oct 1999, Paul Barton-Davis wrote:
> >Well one would have to weigh the effort of reverse engineering it against
> >the gains. Is there any point reverse engineering such ancient hardware?
> >Compared to eg reverse engineering the emu10k or aureal chips.
> what do you think the expected lifetime of any of the current
> generation of chips is, given how long every previous equivalent has
> lasted ? if we're reverse engineering a chip more than 18mths after
> its first use in a PC soundcard, i'd say we might well be wasting our
> time, in the long haul.

The Cirrus Logic chips have been around a long time. The ESS chips
have been around a long time too. The Creative Labs stuff has been around
for more than 10 years. If these chipsets would have had to be reverse
engineered, it would definitely not have been a waste of time since the
data would still be useful today.

Many chipsets go through incremental improvements (eg CS42xx, ESS1xxx) so
reverse engineering one may prove to be useful later since future chips
may be (mostly) backwards-compatible, with a few changes. I suspect this
is the case with the YMF7xx chips and maybe even the AU8xxx ones.

Definitely the YMF7xx chips and the DS-1x architecture look like theyre
going to be around for some time.

-Dan

From - Fri Oct 29 11:26:58 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA19097
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 16:39:21 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA01968 for linux-audio-dev-list; Thu, 28 Oct 1999 15:23:09 -0400
Received: from anime.net (anime.net [205.139.105.150]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA01965 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 15:23:06 -0400
Received: from localhost (goemon@localhost)
	by anime.net (8.9.3/8.9.3) with ESMTP id MAA32162;
	Thu, 28 Oct 1999 12:17:52 -0700
Date: Thu, 28 Oct 1999 12:17:52 -0700 (PDT)
From: Dan Hollis <goemon@sasami.anime.net>
X-Sender: goemon@anime.net
To: Alessandro Fogar <mar095k1@ud.nettuno.it>
cc: Jaroslav Kysela <perex@suse.cz>, Guenter Geiger <geiger@epy.co.at>,
        linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Re: 4D-NXs and Hammerfall
In-Reply-To: <001401bf20b7$0a735da0$cb76cfc1@mar095k1>
Message-ID: <Pine.LNX.4.10.9910281217100.32119-100000@anime.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 6db10c5439f62edaf1afc642b94b8566

On Wed, 27 Oct 1999, Alessandro Fogar wrote:
> Notice that I asked to Echo about Linux driver for their very interesting
> new card 'Mona', they said there are no plans at this time to develop Linux
> drivers or release their code to the open source community (You know, I
> tried...) ();-)

They dont need to develop linux drivers and they dont need to release
their code. So their excuse for not releasing hardware specs is.... ?

-Dan

From - Fri Oct 29 11:27:10 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA06882
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 18:50:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA02124 for linux-audio-dev-list; Thu, 28 Oct 1999 16:29:52 -0400
Received: from pop06.iname.net (pop06.iname.net [165.251.8.76]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA02121 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 16:29:50 -0400
From: jiva@mindless.com
Received: from mindless.com (pdx10-2-72.transport.com [209.222.174.72])
	by pop06.iname.net (8.9.3/8.9.3) with ESMTP id QAA18580
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 16:24:47 -0400 (EDT)
Message-ID: <3818B104.92DAEDFB@mindless.com>
Date: Thu, 28 Oct 1999 13:24:36 -0700
X-Mailer: Mozilla 4.08 [en] (Win95; I)
MIME-Version: 1.0
To: "linux-audio-dev@ginette.musique.umontreal.ca" <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Linux audio questions...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 85c89925766d6dce2fee5d8eb4d7c20c

Hello, everyone... First let me say I'm incredibly new to Linux, so much
so I have yet to install a distribution though I plan on doing so
sometime in the next couple of weeks. I realize my questions are not
very specific and it may be a while until I can relate entirely to the
answers as I currently have no practical experience with Linux as of
yet. If these questions are best addressed elsewhere or there are other
resources I'm not aware of, please let me know. I have been researcing
these questions on the web somewhat, though with the constant state of
development regarding drivers and audio support within Linux, it seems a
mailing list is a resonable outlet for these questions.

Bascially, what I'm trying to do is use Linux box with the primary
intention generating a complete CD of electronic ambient music using no
MIDI devices other than a controller - most music will probably be coded
in csound. What I am particularly curious about is the use of csound in
realtime when driven by a sequencer, I'm hoping to use KeyKit. Is this
possible or has it been known to work? I'm also wondering how csound
functions as a virtual sampler. By the way, I've also posed this
question to the Linux csound list.

Eventually I'm hoping to digitally transfer field material recorded with
a DAT recorder, it seems like the only possible sound card available
that might do this supported under OSS is the Sonorus Studi/o - does
anyone have some experience with this card?

I'm very curious also if anyone has completed any commercially released
CDs using Linux as the sole platform for composing and recording.

Thanks,

Ian

From - Fri Oct 29 11:27:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA01508
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 18:14:37 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA02180 for linux-audio-dev-list; Thu, 28 Oct 1999 16:54:30 -0400
Received: from chekov.Belgium.EU.net (chekov.belgium.eu.net [193.74.208.161]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA02177 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 16:54:28 -0400
Received: from (adial091.liege.eunet.be [195.207.174.91])
	by chekov.Belgium.EU.net  with SMTP id WAA24962 
	for <linux-audio-dev@ginette.musique.umontreal.ca>;
	Thu, 28 Oct 1999 22:49:25 +0200 (MET DST)
Subject: Re: [linux-audio-dev] Re: 4D-NXs and Hammerfall
From: Benjamin GOLINVAUX <golinvaux@benjamin.net>
Reply-To: Benjamin GOLINVAUX <golinvaux@benjamin.net>
In-Reply-To: <Pine.LNX.4.10.9910281217100.32119-100000@anime.net>
Message-ID: <000357f7082c8939_mailit@relay.eunet.be>
References: <Pine.LNX.4.10.9910281217100.32119-100000@anime.net>
Date: Thu, 28 Oct 1999 22:43:55 +0200
X-Mailer: BeatWare Mail-It 2.0.3
X-BeOS-Platform: Intel or clone
X-Priority: 3 (Normal)
To: linux-audio-dev@ginette.musique.umontreal.ca
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0e71d28df62847650f3c5888b4dde6b1

>On Wed, 27 Oct 1999, Alessandro Fogar wrote:
>> Notice that I asked to Echo about Linux driver for their very interesting
>> new card 'Mona', they said there are no plans at this time to develop 
Linux
>> drivers or release their code to the open source community (You know, I
>> tried...) ();-)

Well.. Matt Gonzalez from Echo is an open minded guy who responded 
quite positively to me a few months ago about a BeOS driver request,
so positively that, at the moment, I'm torn between the RME Hammerfall
for Linux and the Layla for BeOS... 

He's been shown his hardware could shine on BeOS (it does) and, 
well, now, Steinberg will be showing Nuendo with a Layla on BeOS
(actually they've been demonstrating it only under STUDI/O, but the
peformance of the two vards are **roughly** the same under BeOS)

I wonder what Matt Gonzalez would feel like after a "latency chat" with Benno 
and Paul.



Benjamin-

From - Fri Oct 29 11:27:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA05242
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 18:39:18 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA02169 for linux-audio-dev-list; Thu, 28 Oct 1999 16:53:18 -0400
Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net [194.217.242.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA02166 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 16:53:16 -0400
Received: from parabola.demon.co.uk ([212.228.182.246] helo=ariel.sr.home)
	by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1)
	id 11gwT4-00032Z-0C; Thu, 28 Oct 1999 20:48:19 +0000
Received: (from steve@localhost)
	by ariel.sr.home (8.8.7/8.8.7) id VAA13466;
	Thu, 28 Oct 1999 21:50:51 +0100
Date: Thu, 28 Oct 1999 21:50:51 +0100
From: Steve Ratcliffe <steve@parabola.demon.co.uk>
To: est@hyperreal.org
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: rtcd vs hz > 100!
Message-ID: <19991028215051.A13281@parabola.demon.co.uk>
Mail-Followup-To: est@hyperreal.org,
	linux-audio-dev@ginette.musique.umontreal.ca
References: <19991028165536.B11787@parabola.demon.co.uk> <19991028180846.25208.qmail@hyperreal.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <19991028180846.25208.qmail@hyperreal.org>; from est@hyperreal.org on Thu, Oct 28, 1999 at 11:08:46AM -0700
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0137541f0692f363a0894f98371c60f3


On Thu, Oct 28, 1999 at 11:08:46AM -0700, est@hyperreal.org wrote:
> This sounds better than the rtcd concept.  I'm curious what others
> think..and happy I posted a design before coding. :)
> 
> Is your module available?

Sure: http://www.parabola.demon.co.uk/alsa/hires.html

..Steve

From - Fri Oct 29 11:26:46 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA31177
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 14:29:39 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA01651 for linux-audio-dev-list; Thu, 28 Oct 1999 13:01:32 -0400
Received: from rhhx01.fht-esslingen.de (rhhx01.fht-esslingen.de [134.108.56.1]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA01645 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 13:01:28 -0400
Received: from firewall.dc.com (rsra81.fht-esslingen.de [134.108.128.81])
	by rhhx01.fht-esslingen.de (8.9.3/8.9.3) with ESMTP id SAA06328;
	Thu, 28 Oct 1999 18:55:46 +0200 (METDST)
Received: from 42.fht-esslingen.de (machtnix.dc.com [192.168.192.168])
	by firewall.dc.com (8.9.3/8.9.3) with ESMTP id RAA00639;
	Thu, 28 Oct 1999 17:50:51 GMT
Message-ID: <3818C969.B01E511D@42.fht-esslingen.de>
Date: Thu, 28 Oct 1999 18:08:41 -0400
From: Alexander =?iso-8859-1?Q?K=F6nig?= <alex@rhlx01.fht-esslingen.de>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.12 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Benno Senoner <sbenno@gardena.net>
CC: Benjamin GOLINVAUX <golinvaux@benjamin.net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: streaming from disk to terminatorX added (via 
 mmap)
References: <199910252148.RAA16689@renoir.op.net> <38158C18.41C92BEC@42.fht-esslingen.de> <000357c9852525d3_mailit@relay.eunet.be> <99102722302101.00611@localhost.localdomain>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by rhhx01.fht-esslingen.de id SAA06328
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id OAA31177
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0f98533aa41088e47f7896873015f856

Benno Senoner wrote:
<..>
> Alexander: what kind of interpolation are you using ?

Uhm. I'm not going into details ;). It was just a very naive approach
(without even the slightest DSP knowlegde) and it seemed to work. Well I
guess not. Go ahead and make it work better :) 

> Are you lowpass filtering the results (I guess no).

>From the aliasing? No.

> ( different from your resonant lowpass filter, which fails too (= cracklings)
> when I feed my nasty high freq sine wave to it.

It's not my filter by the way (it's based on some demo-code by Paul
Kellett - see AUTHORS for eMail) and I guess it's optimized for speed.
But with the CVS stuff (unlike V3.2) you can adjust it's input gain and
make it stop crackling - although it would be nice if you wouldn't have
to adjust this....

Bye, Alex 
-- 
_______________________________________________________________________
                            Alexander Knig - alex@42.fht-esslingen.de
                                                  http://termX.cjb.net

[From the Homer Quotables:]
 
Hello?  Yes?  Oh!  Heh, heh, uh ... if you're looking for that
big donut of yours ... um, Flanders has it.  Just smash open
his house.  (Closing the door.)  He came to life.  Good for him.

		-- Homer Simpson
		   Treehouse Of Horor VI


From - Fri Oct 29 11:26:45 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA29335
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 14:17:02 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA01648 for linux-audio-dev-list; Thu, 28 Oct 1999 13:01:29 -0400
Received: from rhhx01.fht-esslingen.de (rhhx01.fht-esslingen.de [134.108.56.1]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA01644 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 13:01:26 -0400
Received: from firewall.dc.com (rsra81.fht-esslingen.de [134.108.128.81])
	by rhhx01.fht-esslingen.de (8.9.3/8.9.3) with ESMTP id SAA06332;
	Thu, 28 Oct 1999 18:55:47 +0200 (METDST)
Received: from 42.fht-esslingen.de (machtnix.dc.com [192.168.192.168])
	by firewall.dc.com (8.9.3/8.9.3) with ESMTP id RAA00643;
	Thu, 28 Oct 1999 17:50:52 GMT
Message-ID: <3818CB77.5E92A138@42.fht-esslingen.de>
Date: Thu, 28 Oct 1999 18:17:27 -0400
From: Alexander =?iso-8859-1?Q?K=F6nig?= <alex@rhlx01.fht-esslingen.de>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.12 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Benno Senoner <sbenno@gardena.net>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: 
References: <99102722570103.00611@localhost.localdomain>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by rhhx01.fht-esslingen.de id SAA06332
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id OAA29335
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 3c77006f98ea3698dca8355fe620fe39

Benno Senoner wrote:
<..>
> http://www.gardena.net/benno/linux/terminatorX-3.2-mmap2.patch

Cool. I will try to "port" your new patch to the CVS stuff today... I'll
see how far I get... 

> Alexander: could you try this by using  a kernel with the low-latency patch
> applied and  booting with mem=16m  ?

Today? No :( I just tried to apply your low-latency patch against 2.2.12
and it failed (yes I knew it would ;) and it seems I don't have a proper
2.2.10 tarball lying around (and i don't want to download it with my
modem - you know german telcom-costs ;) But I'll grab it when I'm at the
uni tomorrow...

Bye, Alex
-- 
_______________________________________________________________________
                            Alexander Knig - alex@42.fht-esslingen.de
                                                  http://termX.cjb.net

[From the Homer Quotables:]
 
Hello?  Yes?  Oh!  Heh, heh, uh ... if you're looking for that
big donut of yours ... um, Flanders has it.  Just smash open
his house.  (Closing the door.)  He came to life.  Good for him.

		-- Homer Simpson
		   Treehouse Of Horor VI


From - Fri Oct 29 11:27:14 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA21865
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 20:35:09 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA02360 for linux-audio-dev-list; Thu, 28 Oct 1999 18:41:15 -0400
Received: from gauss.deltav.hu (gauss.deltav.hu [194.9.64.225]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA02357 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 18:41:12 -0400
Received: from boksi (106.dial02.deltav.hu [194.9.64.106])
          by gauss.deltav.hu (Netscape Messaging Server 3.6)  with ESMTP
          id AAA23BF for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Fri, 29 Oct 1999 00:40:50 +0200
Received: from reactor by boksi with local (Exim 1.92 #1 (Debian))
	id 11gyHA-00007j-00; Fri, 29 Oct 1999 00:44:08 +0200
Message-ID: <19991029004408.A472@boksi>
Date: Fri, 29 Oct 1999 00:44:08 +0200
From: reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Reverse eng.
Reply-To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91.2
Organization: CTP media laboratories
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 98c46ba760bcb6fd8b896d2058e90c1d

 >% > >Well one would have to weigh the effort of reverse engineering it against
 >% > >the gains. Is there any point reverse engineering such ancient hardware?
 >% > >Compared to eg reverse engineering the emu10k or aureal chips.

anyway, what could creativelabs do if emu was reverse engineered?
sue Linus Torvalds?
or sue an email address?
or a webpage?

it has no chance to prevent the Community from developing a driver...


bye!

-- 

(reactor/CTPmedia) (http://linux.gyakg.u-szeged.hu/~reactor/index.html)
(linux audiowarez) (http://www.bright.net/~dlphilp/linuxsound/toc.html)

From - Fri Oct 29 11:27:21 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA29246
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 21:21:23 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA02306 for linux-audio-dev-list; Thu, 28 Oct 1999 18:02:21 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA02303 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 18:02:17 -0400
Received: from linuxhost.localdomain (IDENT:root@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id XAA03316;
	Thu, 28 Oct 1999 23:57:50 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id BAA00853;
	Fri, 29 Oct 1999 01:58:22 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Billy Biggs <vektor@DIV8.NET>
Subject: [linux-audio-dev] Re: Sync Issues (was Re: External MIDI Sync using OSS/Free)
Date: Fri, 29 Oct 1999 01:46:13 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca,
        linux-sound@vger.rutgers.edu
References: <Pine.LNX.4.04.9910280938390.31398-100000@shell.dhp.com>
MIME-Version: 1.0
Message-Id: <99102901582200.00774@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 98e6e75404e98770b5090d8883336e78

On Thu, 28 Oct 1999, Billy Biggs wrote:
> Benno, you kick ass,

HEHE, thank you !
:-)

> 
> > >   I was using O_RDWR | O_NONBLOCK, under a 2.2 kernel.  I was trying to do
> > > drumrolls, 16th notes, at 140bpm or 150bpm.  It was no good.
> > 
> > hmmm, really strange:
> > I wrote a little util called mididelay, which writes a note-on MIDI message on
> > the midi-out port reads back the message and measures the delay.
> 
>   Can I get a copy of this program?  Are you just using gettimeofday()
> before and after, or are you using ptrace or some other hackery?

the mididelay-0.1 is here:  ( read the README)

http://www.gardena.net/benno/linux/mididelay-0.1.tgz

> 
> > BTW: which card are you using ?
> 
>   For MIDI I'm using a Roland MPU-IPC-T card.  MPU-401.

Jaroslav do you know if there are similar problems on this card with too little
MIDI TX/RX FIFO size  , and/or lack of an IRQ connected to it ?

> 
> > Do not forget to apply the lowlatency patches, or your timing will
> > simply suck ! even an untuned IDE disk, when it reads/writes a small
> > amount of data from/to the disk, could cause 20-50ms delay in your app
> > and this is very bad for MIDI. ( see my tests , especially the non DMA
> > ones = horrible :-)  )
> 
>   What lowlatency patches??  kernel patches??  That's just ugly.  Where
> can I get them?

http://www.gardena.net/benno/linux/audio

read the entire page carefully and look at the old tests too,
then you will realize why I'm so confident that Linux will be
one of the best performing multimedia OSes around.

kernel patch ugly ?
If somethinfg is broken, we have to fix it:
Actually Ingo made the 2.2.10-lowlatency patch as a "demo" what can be done
with Linux.  :-)  
He told me he will integrate the changes into 2.3.x which will become 2.4
that means , ultra-low latency (down to 2.1ms on a P133) for regular
processes running with SCHED_FIFO policy, without messing around with
modules running in kernel space which could crash your entire system in case
if there is a bug. ( = see DirectX = blue screen in case of driver crashes  :-)
 )


> 
> > > > >  What about syncing multiple soundcards?
> > 
> > yes, this is far from trivial, but we will try to provide some usable
> > solution: mainly activating the cards by using DSP_SET_TRIGGER (if
> > supported, otherwise it's a real pain), to minimize starting delays,
> > and then use one of the soundcards as source (or alternatively other
> > timer sources), and put the remaining cards into a "slave" mode, where
> > you measure the sample differences in audio buffers, and insert
> > additional or drop samples to keep things in sync.
> 
>   How can you tell if you've underrun under OSS?  Using ALSA, I guess you
> can use it's time stuff to calculate if you've missed a frame, but even
> that seems hacky.

DSP_GETOSPACE tells you the bytes left in the audio buffer,
but if you want only detect overrruns, just use the RDTSC pentium cyclecounter
and measure if the time between two subsequent write()s to /dev/dsp is
bigger than the time it takes to play the entire audio buffer.
(I used this method in my latencytest and it works fairly well)


> 
>   Do you just always use gettimeofday() math to keep track of how much
> stuff you've written, and when skips have occured?

you can use gettimeofday() too,
I made the code portable so that on x86 you can use RDTSC, on other
architectures you can use gettimeofday(), which is more than adquate
for these purposes (but I saved a few machine cycles (and avoided a syscall) by
using RDTSC. 
(I was testing pure scheduling performance, therefore I had to avoid any
syscalls, except the audio ones)

> 
>   I don't like using one dsp as the sync master since I always want to be
> able to sync to something external, like MIDI.
> 
>   So, the problem becomes, how do you sync many soundcards and have it all
> synced off external MIDI. :)

That is no problem too: just use the MIDI clock as source, and drop/insert
samples on all dsp devices if you detect any drift.


Benno.

From - Fri Oct 29 11:27:16 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA24690
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 20:53:08 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA02330 for linux-audio-dev-list; Thu, 28 Oct 1999 18:09:08 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA02327 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 18:09:04 -0400
Received: from linuxhost.localdomain (IDENT:root@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id AAA03432;
	Fri, 29 Oct 1999 00:04:40 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id CAA00864;
	Fri, 29 Oct 1999 02:05:12 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca,
        linux-sound@vger.rutgers.edu
Subject: Re: [linux-audio-dev] Re: HZ > 100 overhead
Date: Fri, 29 Oct 1999 02:02:09 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199910281503.LAA10749@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99102902051201.00774@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1e45ca62f401262c57e3a29fefab0934

On Thu, 28 Oct 1999, Paul Barton-Davis wrote:
> 
> take a system in which, say, Quasimodo was running through the server
> or was the server and SoftWerk ran along side it. SoftWerk doesn't
> talk to the audio h/w at all, but it wants timing from the RTC. the
> server might want timing from the RTC. a 3rd program runs and wants to
> to use the RTC for something completely non-audio related.
> 
> in these kinds of situations, you don't want to have merged RTC
> service into an "multimedia server" - someone who wants to use the RTC
> for something completely different is going to be unhappy at being
> forced to connect to the multimedia server if the server is running
> (and thus owns the RTC).


> 
> that's why I think that the RTC *must* be considered a standalone
> system utilized either by a single (greedy) application, or by a
> server *that does nothing else* but distribute timing info to clients.

You convinced me  :-) 
Agreed, rtcd will run as standalone app and 
the multimedia API will provide a timerwrapper which connects
to rtcd if requested , ok ?

Benno.

From - Fri Oct 29 11:27:17 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA25650
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 20:59:24 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA02341 for linux-audio-dev-list; Thu, 28 Oct 1999 18:15:16 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA02338 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 18:15:12 -0400
Received: from linuxhost.localdomain (IDENT:root@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id AAA03543;
	Fri, 29 Oct 1999 00:10:48 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id CAA00873;
	Fri, 29 Oct 1999 02:11:21 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca,
        linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: Sync Issues (was Re: External MIDI Sync using OSS/Free)
Date: Fri, 29 Oct 1999 02:06:37 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199910281517.LAA12294@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99102902112102.00774@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 0852084b6df9bb1e1b04967509019dba

On Thu, 28 Oct 1999, Paul Barton-Davis wrote:
> 
> *smile* you've got a hardware problem. i know this because i have too :)
> 
> when i had to switch (temporarily) from my Matrix G200 AGP video card
                                                              ^^^^^^^^^^^
I didn't know that "The Matrix" was developed by Matrox.
:-)

> to an old ISA-based Diamond Speedstar, the performance of my audio
> stuff has gone down the tubes. i can't do *anything* with X and hope
> to not get dropouts. this never happened with the Matrox card, and i
> am very confident that as soon as Matrox ships me a new one, the
> problem will go away.
> 
> right now, my system is essentially useless for audio work unless you
> avoid using X. totally useless. i can't even play WAV files without
> *huge* dropouts, and thats on a *dual* PII-450 !

Yes,

the idiotproof test is the following:
install 2.2.10 + lowlatency patch  ( not SMP !), 
tune the IDE diskas as described in the README
and run a testsession
if the GFX stress graph is the only bad graph,
then I'm sorry but you have to throw away your videocard if you want
to do reliable low latency stuff.
:-)

Benno.

From - Fri Oct 29 11:27:18 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA26109
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 21:02:37 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA02446 for linux-audio-dev-list; Thu, 28 Oct 1999 19:50:43 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA02443 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 19:50:40 -0400
Received: from linuxhost.localdomain (IDENT:root@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id BAA04626;
	Fri, 29 Oct 1999 01:46:17 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id DAA00944;
	Fri, 29 Oct 1999 03:46:51 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Benjamin GOLINVAUX <golinvaux@benjamin.net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: 4D-NXs and Hammerfall
Date: Fri, 29 Oct 1999 03:37:36 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <000357f7082c8939_mailit@relay.eunet.be>
MIME-Version: 1.0
Message-Id: <99102903465104.00774@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 6d647027b1cdc853d50d67aeca12bbe7

On Thu, 28 Oct 1999, Benjamin GOLINVAUX wrote:

> Well.. Matt Gonzalez from Echo is an open minded guy who responded 
> quite positively to me a few months ago about a BeOS driver request,
> so positively that, at the moment, I'm torn between the RME Hammerfall
> for Linux and the Layla for BeOS... 
> 
> He's been shown his hardware could shine on BeOS (it does) and, 
> well, now, Steinberg will be showing Nuendo with a Layla on BeOS
> (actually they've been demonstrating it only under STUDI/O, but the
> peformance of the two vards are **roughly** the same under BeOS)
> 
> I wonder what Matt Gonzalez would feel like after a "latency chat" with Benno 
> and Paul.
> 

Benjamin,
what was the 7ms io-latency on BeOS using Layla / STUD/O ?
pure audio buffers , or external measured REAL latency,
which includes DAC/ADC/filters delays ?

But anyway: send him the the link to the lowlatency page, and say him
that he should write us  his opinionus on this topic.
I asked an optinion about the Linux realtime performance to
one of Seersystems Reality engineers on music-dsp ,
let's see what he answers.
:-)
PS: he said tuning the low latency on Windows (with special kernel drivers and
other hacks) took an additional 50-100% of amount of work.
(which could be invested in doing real DSP stuff, but yes, Seer achieves 
the best performance compared to other softsynths)

Benno.


From - Fri Oct 29 11:27:27 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA15387
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 23:35:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA02604 for linux-audio-dev-list; Thu, 28 Oct 1999 21:39:45 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA02601 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 21:39:43 -0400
Received: from someip.ppp.op.net (d-bm2-01.ppp.op.net [209.152.194.33]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id VAA13675; Thu, 28 Oct 1999 21:35:32 -0400 (EDT)
Message-Id: <199910290135.VAA13675@renoir.op.net>
To: jiva@mindless.com
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Linux audio questions... 
In-reply-to: Your message of "Thu, 28 Oct 1999 13:24:36 PDT."
             <3818B104.92DAEDFB@mindless.com> 
Date: Thu, 28 Oct 1999 22:31:32 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 56e96baee84a7892dd918af25815d72d

>Bascially, what I'm trying to do is use Linux box with the primary
>intention generating a complete CD of electronic ambient music using no
>MIDI devices other than a controller 

fairly reasonable.
				      
>				      - most music will probably be coded
>in csound. 

fairly restrictive :)
	    
>	    What I am particularly curious about is the use of csound in
>realtime when driven by a sequencer, I'm hoping to use KeyKit. Is this
>possible or has it been known to work? 

it can be done (i've done it), but i would not call it particularly
nice. csound isn't really all that fast, and its handling of real-time
MIDI is not its greatest asset. But it can be made to work, either
using a special kind of file called a FIFO to act as the MIDI output
for KeyKit and the input for csound, or using the default sound driver
set's "virtual MIDI port".

if you want csound to do complex stuff, you'd better plan on doing
quite a bit of non-real-time synthesis.
					
>					I'm also wondering how csound
>functions as a virtual sampler. 

not particularly interesting because its so low level, though its
definitely possible to make it do anything you might want. it just can
take a lot of effort to get it all right. also, fancier things like
pitch shifting, although they exist, use not particularly good,
somewhat dated algorithms. 

>Eventually I'm hoping to digitally transfer field material recorded with
>a DAT recorder, it seems like the only possible sound card available
>that might do this supported under OSS is the Sonorus Studi/o - does
>anyone have some experience with this card?

no experience, except for reports that the OSS "beta" driver is "buggy".

but you're wrong about it being the only possible card. if the DAT
recorder has an S/PDIF port, you can spend $39 on a Hoontech SoundWave
NX, use the patches just posted to the ALSA development mailing list,
and do digital I/O with that card's S/PDIF port. Otherwise, spend a
little bit on a S/PDIF-to-T/DIF converter (i think T/DIF is a pretty
common standard for DAT recorders) and still use a cheap card. If the
recorder just has an ADAT port then ... I'm not sure.

it seems fairly unlikely that the STUDI/O will ever have (1) open
source drivers, which will likely be a problem from time to time as
the kernel driver interface changes and (2) may never have
particularly good drivers. Why ? (a) 4Front Technologies (the driver
writers) focus on consumer cards (b) the switch to ALSA as the
standard Linux kernel sound drivers (c) the possible emergence of
the RME Hammerfall as the serious option for people who want to do pro
audio under Linux.

>I'm very curious also if anyone has completed any commercially released
>CDs using Linux as the sole platform for composing and recording.

No, but I am about to set up a digital corner in pro-studio that will
(soon or immediately) only run Linux. We'll have an RME Hammerfall as
the main I/O point (fed by 2 Apogee D8000 A-D converters).

--p

From - Fri Oct 29 11:27:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA11726
	for <slinkp@ulster.net>; Thu, 28 Oct 1999 23:04:14 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA02619 for linux-audio-dev-list; Thu, 28 Oct 1999 21:49:51 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA02616 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 28 Oct 1999 21:49:49 -0400
Received: from someip.ppp.op.net (d-bm2-01.ppp.op.net [209.152.194.33]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id VAA14406; Thu, 28 Oct 1999 21:45:33 -0400 (EDT)
Message-Id: <199910290145.VAA14406@renoir.op.net>
To: est@hyperreal.org
cc: Steve Ratcliffe <steve@parabola.demon.co.uk>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: rtcd vs hz > 100! 
In-reply-to: Your message of "Thu, 28 Oct 1999 11:08:46 PDT."
             <19991028180846.25208.qmail@hyperreal.org> 
Date: Thu, 28 Oct 1999 22:41:38 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: faccca1653c236081262c34fab9a7ec1

In message <19991028180846.25208.qmail@hyperreal.org>you write:
>Steve Ratcliffe discourseth:
>> 
>> For those using ALSA, you can already do this without a user daemon.
>> The timer interface allows more than one process to access the same timer,
>> there is a user interface via open/read of /dev/snd/timer and a kernel
>> interface so that the sequencer can be driven from a better clock than
>> the 10ms system timer.  I have a demo timer module that uses the RTC as
>> a loadable ALSA timer.
>
>This sounds better than the rtcd concept.  I'm curious what others
>think..and happy I posted a design before coding. :)

i agree. much cleaner. the naming of /dev/snd/timer is the only hint
of audio-relatedness, and i think that *we* can certainly live with
that. 

though let me check: after the module opens the RTC, the RTC
is no longer usable directly by any other module or application, right?
does the module have its own RTC driver, or does it use the existing
one via the cross-driver "open/close/read/write" call interface ?

--p

From - Fri Oct 29 11:27:31 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id EAA01258
	for <slinkp@ulster.net>; Fri, 29 Oct 1999 04:07:08 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id CAA06680 for linux-audio-dev-list; Fri, 29 Oct 1999 02:13:30 -0400
Received: from pop02.iname.net (pop02.iname.net [165.251.20.34]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA06677 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 29 Oct 1999 02:13:27 -0400
From: jiva@mindless.com
Received: from mindless.com (pdx10-3-54.transport.com [209.222.174.182])
	by pop02.iname.net (8.9.3/8.9.3) with ESMTP id CAA17696;
	Fri, 29 Oct 1999 02:07:22 -0400 (EDT)
Message-ID: <38193984.3F7622D4@mindless.com>
Date: Thu, 28 Oct 1999 23:07:00 -0700
X-Mailer: Mozilla 4.08 [en] (Win95; I)
MIME-Version: 1.0
To: Paul Barton-Davis <pbd@Op.Net>,
        "linux-audio-dev@ginette.musique.umontreal.ca" <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Linux audio questions...
References: <199910290135.VAA13675@renoir.op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 96ad4257d53269c0ec5f68b63451d644

> >                                     - most music will probably be coded
> >in csound.
> 
> fairly restrictive :)

Yes, that's true. Actually, I understand there are other languages such
as cmix and common music, I just haven't found as extensive reference
for creation of music using these languages. Also, Arts, SLab, AUBE,
gAlan and so on look extremely promising and being as they run under
Linux I'm sure I'll work with them. Originally I was thinking of working
with csound exclusively this seems a bit restrictive as you've observed.
Also, I'm wondering perhaps if Stomper, Orangator and other freeware
soft synths I have experience with run under WINE. 

> >           What I am particularly curious about is the use of csound in
> >realtime when driven by a sequencer, I'm hoping to use KeyKit. Is this
> >possible or has it been known to work?
> 
> it can be done (i've done it), but i would not call it particularly
> nice. csound isn't really all that fast, and its handling of real-time
> MIDI is not its greatest asset. But it can be made to work, either
> using a special kind of file called a FIFO to act as the MIDI output
> for KeyKit and the input for csound, or using the default sound driver
> set's "virtual MIDI port".
> 
> if you want csound to do complex stuff, you'd better plan on doing
> quite a bit of non-real-time synthesis.
> 

What I'm planning on doing is completing long passages of fairly simple
ambience - say two and a half minutes of arpeggios in 7/8 with a couple
of very slow lfos and envelopes creating modulation sweeps - printing
the audio files, adding fx later and then ultimately merging them in a
program such as SLab. I don't want to send it so much information it
patches out. That's the idea right now I suppose...

> >                                       I'm also wondering how csound
> >functions as a virtual sampler.
> 
> not particularly interesting because its so low level, though its
> definitely possible to make it do anything you might want. it just can
> take a lot of effort to get it all right. also, fancier things like
> pitch shifting, although they exist, use not particularly good,
> somewhat dated algorithms.

I'm just trying to find out how to trigger samples from a sequencer in
realtime or at least edit in realtime - particularly breakbeats ala
squarepusher, plug, afx. I'd like to be able to find an editing
environment that can read MIDI generated from KeyKit even if not in
realtime. It seems perhaps dropping MIDI files to a tracker would work
for this, but SoundTracker and VoodooTracker don't seem to support MIDI
input at this time. I'm not sure about KegTracker.

> but you're wrong about it being the only possible card. if the DAT
> recorder has an S/PDIF port, you can spend $39 on a Hoontech SoundWave
> NX, use the patches just posted to the ALSA development mailing list,
> and do digital I/O with that card's S/PDIF port. Otherwise, spend a
> little bit on a S/PDIF-to-T/DIF converter (i think T/DIF is a pretty
> common standard for DAT recorders) and still use a cheap card. If the
> recorder just has an ADAT port then ... I'm not sure.

how's the conversion on these cards? is there a significant difference
between the quality of conversion when compared to a more expensive
card?

> 
> it seems fairly unlikely that the STUDI/O will ever have (1) open
> source drivers, which will likely be a problem from time to time as
> the kernel driver interface changes and (2) may never have
> particularly good drivers. Why ? (a) 4Front Technologies (the driver
> writers) focus on consumer cards (b) the switch to ALSA as the
> standard Linux kernel sound drivers (c) the possible emergence of
> the RME Hammerfall as the serious option for people who want to do pro
> audio under Linux.
> 

Thanks for the advice.

> >I'm very curious also if anyone has completed any commercially released
> >CDs using Linux as the sole platform for composing and recording.
> 
> No, but I am about to set up a digital corner in pro-studio that will
> (soon or immediately) only run Linux. We'll have an RME Hammerfall as
> the main I/O point (fed by 2 Apogee D8000 A-D converters).
> 
> --p

I'll be sure to look into the Hammerfall, I'm not in need of a sound
card immediately and want to be sure to support companies that have the
proper priorities when relating to the open source community.

I very much appreciate the manner in which you've addressed my questions
- I think this is precisely why I'm drawn to Linux. Basically I started
sequencing around 1989 when I was still using a C64. Now I have friends
asking me for tech support with MIDI on Macs and PCs... coupled with the
realization that I've been using the same method of outboard synths,
samplers + cakewalk for over six years I've realized its time for a
change. Also, I've been wanting to work entirely digital and soft synths
accomplish that. I've always worked non-realtime to a certain degree,
and the idea of using soft synths, trackers and algorhythms to create
contemporary electronica on Linux is very appealing. Of course I know
technically I'm not quite up to the task yet, but I feel confident it
will be a positive experience and I can share with the community as I
think electronic music should be open source in much the way Linux is.

Next stop... local Linux users group.

Thanks again, I'm planning on keeping a diary of my experiences with
Linux and Linux sound apps during the course of this project. I may end
up with two Linux boxes - one for sequencing and the other for soft
synths and digital audio.

Ian
www.mp3.com/iread

From - Fri Oct 29 11:27:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id IAA17091
	for <slinkp@ulster.net>; Fri, 29 Oct 1999 08:19:02 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA07329 for linux-audio-dev-list; Fri, 29 Oct 1999 06:46:00 -0400
Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA07326 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 29 Oct 1999 06:45:56 -0400
Received: from parabola.demon.co.uk ([212.228.182.246] helo=ariel.sr.home)
	by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1)
	id 11h9Te-0005Dw-0B; Fri, 29 Oct 1999 10:41:47 +0000
Received: (from steve@localhost)
	by ariel.sr.home (8.8.7/8.8.7) id LAA13930;
	Fri, 29 Oct 1999 11:43:03 +0100
Date: Fri, 29 Oct 1999 11:43:03 +0100
From: Steve Ratcliffe <steve@parabola.demon.co.uk>
To: Paul Barton-Davis <pbd@Op.Net>
Cc: est@hyperreal.org, linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: rtcd vs hz > 100!
Message-ID: <19991029114303.A13768@parabola.demon.co.uk>
Mail-Followup-To: Paul Barton-Davis <pbd@op.net>, est@hyperreal.org,
	linux-audio-dev@ginette.musique.umontreal.ca
References: <19991028180846.25208.qmail@hyperreal.org> <199910290145.VAA14406@renoir.op.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <199910290145.VAA14406@renoir.op.net>; from pbd@op.net on Thu, Oct 28, 1999 at 10:41:38PM -0400
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 99504019364c7ba9f8c7544a2d04e5bb

On Thu, Oct 28, 1999 at 10:41:38PM -0400, Paul Barton-Davis wrote:
> i agree. much cleaner. the naming of /dev/snd/timer is the only hint
> of audio-relatedness, and i think that *we* can certainly live with
> that. 

Well yes, in the grand scheme of things it might be nice if the kernel
RTC /dev/rtc driver was capable of being opened multiple times and that
it was possible for ALSA and other projects that may want to use it to
be able to access it via some interface from within the kernel.

> though let me check: after the module opens the RTC, the RTC
> is no longer usable directly by any other module or application, right?

Yes.

> does the module have its own RTC driver, or does it use the existing
> one via the cross-driver "open/close/read/write" call interface ?

Oh its just a hack.  It takes bits of the existing /dev/rtc driver and
gives it a dynamically loadable ALSA timer interface.  So you can't
even have the kernel RTC driver compiled in (and unfortunately it is
not dynamically loadable).

..Steve

From - Fri Oct 29 11:27:37 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA26487
	for <slinkp@ulster.net>; Fri, 29 Oct 1999 09:28:26 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA07550 for linux-audio-dev-list; Fri, 29 Oct 1999 08:49:14 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA07547 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 29 Oct 1999 08:49:11 -0400
Received: from someip.ppp.op.net (d-bm2-00.ppp.op.net [209.152.194.32]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id IAA04849; Fri, 29 Oct 1999 08:44:59 -0400 (EDT)
Message-Id: <199910291244.IAA04849@renoir.op.net>
To: jiva@mindless.com
cc: "linux-audio-dev@ginette.musique.umontreal.ca" <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Linux audio questions... 
In-reply-to: Your message of "Thu, 28 Oct 1999 23:07:00 PDT."
             <38193984.3F7622D4@mindless.com> 
Date: Fri, 29 Oct 1999 09:41:11 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: a09b3b55cd09e64ed63a73f4ee80dc53

>I'm just trying to find out how to trigger samples from a sequencer in
>realtime or at least edit in realtime - particularly breakbeats ala
>squarepusher, plug, afx. I'd like to be able to find an editing
>environment that can read MIDI generated from KeyKit even if not in
>realtime. 

well, as i said, Csound can definitely do this, but its work.

>> ... recorder has an S/PDIF port, you can spend $39 on a Hoontech SoundWave
>> NX ...

>how's the conversion on these cards? is there a significant difference
>between the quality of conversion when compared to a more expensive
>card?

i don't know the precise details on the A-D/D-A converters in the
trident chipset used by this board. it probably isn't as good as the
STUDI/O, especially the A-D. for me, i'd rather wait for a card that
will have the right kind of support under Linux, and the STUDI/O seems
unlikely to be it.  also, note that if sound quality really concerns
you, and the A-D direction is important (sounds like it is), you'd be
much better off with an outboard A-D converter. Doing this conversion
anywhere in the vicinity of the computer motherboard is asking for
noise.

>Thanks again, I'm planning on keeping a diary of my experiences with
>Linux and Linux sound apps during the course of this project. I may end
>up with two Linux boxes - one for sequencing and the other for soft
>synths and digital audio.

if by sequencing, you just mean MIDI sequencing: be sure to use a
cheap, old, 2nd hand box for the sequencing one. i have a 100MHz
486-DX that sits (mostly idle) next to my main rack (which holds a
dual PII-450 as my "main" computer). the 486 is *more than adequate*
for any Linux MIDI sequencing task you can imagine. It has 32MB of
RAM. you could pick up such a machine for, oh, $100? (i paid more
because i wanted SCSI). you could compile the kernel to use a 1000HZ
timer to make things even more precise than they would be otherwise.
Linux will run just fine (better than that, even) on such a box.

--p

From - Fri Oct 29 14:47:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA17364
	for <slinkp@ulster.net>; Fri, 29 Oct 1999 12:05:31 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA07795 for linux-audio-dev-list; Fri, 29 Oct 1999 10:39:50 -0400
Received: from shell.dhp.com (shell.dhp.com [199.245.105.1]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA07792 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 29 Oct 1999 10:39:47 -0400
Received: by shell.dhp.com (Postfix, from userid 668)
	id 52ED41ACE4; Fri, 29 Oct 1999 10:35:27 -0400 (EDT)
Date: Fri, 29 Oct 1999 10:35:20 -0400 (EDT)
From: Billy Biggs <vektor@DIV8.NET>
To: Paul Barton-Davis <pbd@Op.Net>
Cc: Linux Audio Dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Linux audio questions... 
In-Reply-To: <199910291244.IAA04849@renoir.op.net>
Message-ID: <Pine.LNX.4.04.9910291033050.6709-100000@shell.dhp.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 30c17d239782fd85b92da96019b0e949

On Fri, 29 Oct 1999, Paul Barton-Davis wrote:

> if by sequencing, you just mean MIDI sequencing: be sure to use a
> cheap, old, 2nd hand box for the sequencing one. i have a 100MHz
> 486-DX that sits (mostly idle) next to my main rack (which holds a
> dual PII-450 as my "main" computer). the 486 is *more than adequate*
> for any Linux MIDI sequencing task you can imagine.

  What sequencer do you run on that box, and what soundcard are you using?

--
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

From - Sat Oct 30 15:06:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA06300
	for <slinkp@ulster.net>; Fri, 29 Oct 1999 18:25:21 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA08525 for linux-audio-dev-list; Fri, 29 Oct 1999 17:43:58 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA08522 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 29 Oct 1999 17:43:53 -0400
Received: from linuxhost.localdomain (IDENT:root@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id XAA05617
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 29 Oct 1999 23:39:37 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id QAA00953
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 29 Oct 1999 16:52:16 +0200
From: Benno Senoner <sbenno@gardena.net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Timestamped MIDI interfaces ....
Date: Fri, 29 Oct 1999 16:48:56 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <99102916521601.00738@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 4427c1067ce0955593caba6cdb4355ef

Hi folks,
what do you think about this timestamping MIDI interface ?

http://www.harmony-central.com/Newp/107AES/MOTU/MTS.html

seems that our upcoming timestamped event system could easily drive this
beast. :-)

regards,
Benno.

From - Fri Oct 29 14:47:40 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA27855
	for <slinkp@ulster.net>; Fri, 29 Oct 1999 13:23:26 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA07974 for linux-audio-dev-list; Fri, 29 Oct 1999 12:39:26 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id MAA07971 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 29 Oct 1999 12:39:23 -0400
From: est@hyperreal.org
Received: (qmail 27150 invoked by uid 162); 29 Oct 1999 15:30:52 -0000
Message-ID: <19991029153052.27149.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] Linux audio questions...
In-Reply-To: <38193984.3F7622D4@mindless.com> from "jiva@mindless.com" at "Oct
 28, 1999 11:07:00 pm"
To: jiva@mindless.com
Date: Fri, 29 Oct 1999 08:30:52 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 3ba574a3b4b07fbb6ac3216f3b3b56f9

jiva@mindless.com discourseth:
> 
> I'm just trying to find out how to trigger samples from a sequencer in
> realtime or at least edit in realtime - particularly breakbeats ala
> squarepusher, plug, afx.

OK, jiva, you should check out www.hyperreal.org/~est/csound/s1 for a
simple example of using csound as a sampler and driving it with midi
(generated by a python script in this case).  Given your tastes, you
may enjoy the sample beat included too. :)

Eric

From - Fri Oct 29 14:47:37 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA17182
	for <slinkp@ulster.net>; Fri, 29 Oct 1999 12:03:47 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA07813 for linux-audio-dev-list; Fri, 29 Oct 1999 10:48:57 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA07810 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 29 Oct 1999 10:48:55 -0400
Received: from someip.ppp.op.net (d-bm2-00.ppp.op.net [209.152.194.32]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id KAA16508; Fri, 29 Oct 1999 10:44:38 -0400 (EDT)
Message-Id: <199910291444.KAA16508@renoir.op.net>
To: Billy Biggs <vektor@DIV8.NET>
cc: Linux Audio Dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Linux audio questions... 
In-reply-to: Your message of "Fri, 29 Oct 1999 10:35:20 EDT."
             <Pine.LNX.4.04.9910291033050.6709-100000@shell.dhp.com> 
Date: Fri, 29 Oct 1999 11:40:51 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: a326da23a7c4476a81d6bf95f85447f8

>  What sequencer do you run on that box, and what soundcard are you using?

i don't run a "sequencer" in the contemporary sense of that term. i
use SoftWerk or KeyKit. most of my music is highly pattern and/or
process oriented, so i tend to have much less use for a "sequencer"
ala Cakewalk, Cubase etc. Note that i also restricted "sequencing" to
MIDI only: no audio output.

it has a Turtle Beach Tropez+ installed, which is pretty silly, since
i never/rarely use the audio part of the card. but it was cheap :)

--p


From - Fri Oct 29 14:47:42 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA32217
	for <slinkp@ulster.net>; Fri, 29 Oct 1999 13:52:26 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA08033 for linux-audio-dev-list; Fri, 29 Oct 1999 13:12:17 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA08030 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 29 Oct 1999 13:12:15 -0400
From: est@hyperreal.org
Received: (qmail 15398 invoked by uid 162); 29 Oct 1999 15:58:45 -0000
Message-ID: <19991029155845.15397.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] Linux audio questions...
In-Reply-To: <199910291244.IAA04849@renoir.op.net> from Paul Barton-Davis at
 "Oct 29, 1999 09:41:11 am"
To: Paul Barton-Davis <pbd@Op.Net>
Date: Fri, 29 Oct 1999 08:58:44 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c532c699324c8ee2aba9c3741efa27f2

Paul Barton-Davis discourseth:
> 
> >I may end
> >up with two Linux boxes - one for sequencing and the other for soft
> >synths and digital audio.
> 
> if by sequencing, you just mean MIDI sequencing: be sure to use a
> cheap, old, 2nd hand box for the sequencing one. i have a 100MHz
> 486-DX that sits (mostly idle) next to my main rack (which holds a
> dual PII-450 as my "main" computer). the 486 is *more than adequate*
> for any Linux MIDI sequencing task you can imagine.

Hmm..doesn't it depend on the sequencer(s)?  How much of that
processor does softwerk use.  I expect the next-generation of softwerk
will use more.  What if a sequencer were written in Python?  "Software
is a gas." :)

> It has 32MB of
> RAM. you could pick up such a machine for, oh, $100? (i paid more
> because i wanted SCSI).

SCSI may be important in this case.  Those old ide chipsets/drives can
cause latency problems.

I'd actually like some cheapo machines myself.  I always worry about
how I'll find replacement parts for them.  It can be pretty difficult
to find new cpus below a certain clock-rate, for example.  Does one
just use used replacement parts?  I've got a nice second hand computer
shop near me, but do you know of any good ones online?

Eric

From - Fri Oct 29 17:16:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA16323
	for <slinkp@ulster.net>; Fri, 29 Oct 1999 15:48:57 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA08211 for linux-audio-dev-list; Fri, 29 Oct 1999 15:03:36 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA08208 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 29 Oct 1999 15:03:33 -0400
Received: from ulster.net (port145.ts2.ulster.net [208.242.164.145])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id PAA09518;
	Fri, 29 Oct 1999 15:03:03 -0400
Message-ID: <3819CDFE.8933DEAD@ulster.net>
Date: Fri, 29 Oct 1999 12:40:30 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: jiva@mindless.com
CC: "linux-audio-dev@ginette.musique.umontreal.ca" 
 <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Linux audio questions...
References: <199910291244.IAA04849@renoir.op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 9ca5809e36cae1e10d6bffb397c658c5

Paul Barton-Davis wrote:
> jiva wrote:
> >I'm just trying to find out how to trigger samples from a sequencer in
> >realtime or at least edit in realtime - particularly breakbeats ala
> >squarepusher, plug, afx. I'd like to be able to find an editing
> >environment that can read MIDI generated from KeyKit even if not in
> >realtime.
> 
> well, as i said, Csound can definitely do this, but its work.

I'm not sure exactly what you mean by "edit in realtime", but here's
a csound orc & sco for a pretty stupid sample player with pitch lfo:
(Disclaimer: this worked last time I used it :))

;;; here's the orc

  sr    =       44100
  kr    =       2205
  ksmps =       20
  nchnls        =       1

instr 1

  kmod  pchbend 2          ;  pitch wheel controls lfo speed
  kmod = 1/kmod 
  inum  notnum                  ; get note number
  ifreq cpsmidi              ; get current note & convert to cps.
  iamp  =       1000           ; 
  xtratim 3                    ;  extend duration after key release 
  klfo  init    1
  krel  init    0
  krel  release                 ; is key off yet?
  if (krel > .5 ) kgoto rel ;  yes, it's off. otherwise fall through
to...
  ;;; ENVELOPES
        ;  attack/sustain section
    kenv1 expseg 0.001, 2, 1, 50, 1
    kamp  =       kenv1 * iamp
        ; make the LFO
    klfo oscil 1, kmod, 2              ; oscillate pitch by 10 %
                                       ; use f2 for lfo
    kgoto   done
      ; release section
  rel:
    kenv2  linseg  1, 2.6, 1, .4, 0
    kamp  =       kenv2*kenv1*iamp
    klfo expseg  1, 2.8, .7, .2, .2
  done:
    aout  oscili  kamp, ifreq * klfo, 1  ;  use f1 for audio table
  out     aout
endin 

;;;; here's the score

f0 400 ; run for 400 seconds

f1 0 131072 1 "siren4.aiff" 0 0 0   ; this is your audio file    
f2 0 1024 -7 1 212 1 300 .8 212 1 300 1 ; non-normalized lfo

e 

> >Thanks again, I'm planning on keeping a diary of my experiences with
> >Linux and Linux sound apps during the course of this project. I may end
> >up with two Linux boxes - one for sequencing and the other for soft
> >synths and digital audio.

People tell me this is a good idea. I haven't yet got around to
doing this.
 
> if by sequencing, you just mean MIDI sequencing: be sure to use a
> cheap, old, 2nd hand box for the sequencing one. i have a 100MHz
> 486-DX that sits (mostly idle) next to my main rack (which holds a
> dual PII-450 as my "main" computer). the 486 is *more than adequate*
> for any Linux MIDI sequencing task you can imagine. It has 32MB of
> RAM. you could pick up such a machine for, oh, $100? (i paid more
> because i wanted SCSI). you could compile the kernel to use a 1000HZ
> timer to make things even more precise than they would be otherwise.
> Linux will run just fine (better than that, even) on such a box.

Also cool: You don't even really need a separate monitor for the
midi box. You could set it up as a "headless box" which you
interface entirely from your main system. Run console or X apps on
the 486 and see them displayed on your audio system's screen, and
save the cost, electrical usage, and desktop space of a separate
monitor. Granted I have never actually _done_ this, I've just heard
about it.

----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.
email=========================slinkp AT ulster DOT net
ARMS online=======================http://reacharms.com    
personal page===========http://www.ulster.net/~abigoo/


From - Fri Oct 29 17:16:42 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA20884
	for <slinkp@ulster.net>; Fri, 29 Oct 1999 16:19:38 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA08216 for linux-audio-dev-list; Fri, 29 Oct 1999 15:03:53 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA08213 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 29 Oct 1999 15:03:50 -0400
Received: from ulster.net (port145.ts2.ulster.net [208.242.164.145])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id PAA09552;
	Fri, 29 Oct 1999 15:03:12 -0400
Message-ID: <3819D6D7.C32B8E7D@ulster.net>
Date: Fri, 29 Oct 1999 13:18:15 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: jiva@mindless.com
CC: "linux-audio-dev@ginette.musique.umontreal.ca" 
 <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Linux audio questions...
References: <199910290135.VAA13675@renoir.op.net> <38193984.3F7622D4@mindless.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7e2faed493628fea77aec153e94ee1f3

jiva@mindless.com wrote:
> 
> > >                                     - most music will probably be coded
> > >in csound.
> >
> > fairly restrictive :)

I get the impression you haven't actually used csound much (or at
all?). I'll take the liberty of commenting a little: 

csound is actually very versatile at processing sound. It just takes
some time to learn how to get simple sounds out of it, then some
more time to stop making the same mistakes over and over, then some
more time learning something about synthesis to understand how to
translate ideas into csound, then some more time browsing the manual
trying to find the "opcodes" that will enable you to do the things
you want, then lots more time to get your instruments to actually
please you. In short, it takes lots ... and lots... of time.

Where I think csound is _very_ restrictive is in two places:

1) The score language is very flexible and very primitive. It's way
too cumbersome to actually compose music "by hand" with it. Many
people use MIDI and convert to csound one way or another. Other
options are using a spreadsheet, or using "helper" apps or languages
such as Silence, common music, sybil, cscore, etc. to generate
csound scores.

2) The orc language is really pretty dumb when looked at as a
programming language. There will be times when you want instruments
that behave one way some of the time, and another way under other
conditions. In csound you have to learn to understand a pretty
ancient kind of programming logic: the only tools are "if" and
"goto", which you generally use like this:

if <some_condition> goto some_label_name
   <here you put things to do if some_condition is NOT true>
   goto end_of_tests
some_label_name:
  <here you put things to do if some_condition IS true>
end_of_tests:
   <we end up here after either condition>

This looks weird to anyone who knows even a little of any
programming language invented since, oh, say, 1970, because in C,
perl, python, java, and I don't know how many other languages, the
"if" is followed immediately by what you want to do if the condition
IS true. So in csound you have to learn to think in this peculiar
"backwards" manner.

Now imagine trying to write a csound instrument with conditional
tests nested inside other conditional tests. I haven't been brave
enough to try that yet.

> Yes, that's true. Actually, I understand there are other languages such
> as cmix and common music, I just haven't found as extensive reference
> for creation of music using these languages.

I used cmix a bit a long time ago. It's probably quicker to learn
than csound if you just want to process soundfiles, but for
synthesizing whole pieces with it, you probably need some sort of
external tool such as Common Music or maybe some prog to translate
midi files to cmix? (does anything like that exist?)

common music as I understand it is basically a dialect of LISP
optimized for making music. I don't know if it can do realtime, but
it's almost certainly a more powerful language than csound, though
it comes with fewer built-in "opcodes" or whatever you want to call
them.

> Also, Arts, SLab, AUBE,
> gAlan and so on look extremely promising and being as they run under
> Linux I'm sure I'll work with them.

I've tried AUBE and while it's a fun idea, it was also extremely
buggy and crash-prone last time I tried it (6 months ago?). I don't
think there's been many updates to it since then.

I also tried SLab. I found the user interface to be overly
cumbersome -- too much crap I didn't care about on the screen all
the time. I just don't think you can effectively cram a
full-featured analog mixer into the space of a 15" monitor; the
computer screen calls for different ways of using space. And I never
did get full duplex working with SLab so I gave up. On a P133 I
found the interface was very slow to do redraws and stuff (it's
written in tcl/tk); it might be OK on a celeron-300A.

I have not tried Arts or gAlan yet.

> Originally I was thinking of working
> with csound exclusively this seems a bit restrictive as you've observed.
> Also, I'm wondering perhaps if Stomper, Orangator and other freeware
> soft synths I have experience with run under WINE.
> 
> > >           What I am particularly curious about is the use of csound in
> > >realtime when driven by a sequencer, I'm hoping to use KeyKit. Is this
> > >possible or has it been known to work?
> >
> > it can be done (i've done it), but i would not call it particularly
> > nice. csound isn't really all that fast, and its handling of real-time
> > MIDI is not its greatest asset. But it can be made to work, either
> > using a special kind of file called a FIFO to act as the MIDI output
> > for KeyKit and the input for csound, or using the default sound driver
> > set's "virtual MIDI port".
> >
> > if you want csound to do complex stuff, you'd better plan on doing
> > quite a bit of non-real-time synthesis.
> >
> 
> What I'm planning on doing is completing long passages of fairly simple
> ambience - say two and a half minutes of arpeggios in 7/8 with a couple
> of very slow lfos and envelopes creating modulation sweeps - printing
> the audio files, adding fx later and then ultimately merging them in a
> program such as SLab. I don't want to send it so much information it
> patches out. That's the idea right now I suppose...

This is doable. One way to do more realtime work in csound is, when
things get too complex to render in realtime, render what you've got
so far into a soundfile, then read it in to a new orc / sco using a
simple "diskin" instrument, then add more instruments or voices or
whatever. You can always go back later and change the orc/sco that
created the rendered file if you want to modify it.

(stuff about soundcards snipped)
If you haven't yet, you should check my Audio-Quality-HOWTO at:
http://www.ulster.net/~abigoo/pw_linux/Audio-Quality-HOWTO.html

It's not always the most up to date information, but I try. :)
 
> > >I'm very curious also if anyone has completed any commercially released
> > >CDs using Linux as the sole platform for composing and recording.

Hmm, I'd better get moving. I kind of wanted to be the first guy to
be able to say he did this, but I haven't really got anywhere with
it yet. I'll race ya. :)

> Thanks again, I'm planning on keeping a diary of my experiences with
> Linux and Linux sound apps during the course of this project.

This is a good idea -- you should put it online so other linux sound
newbies can read it.. I meant to do something like this but I
haven't found the time.

----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.
email=========================slinkp AT ulster DOT net
ARMS online=======================http://reacharms.com    
personal page===========http://www.ulster.net/~abigoo/


From - Fri Oct 29 17:16:46 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA21816
	for <slinkp@ulster.net>; Fri, 29 Oct 1999 16:26:13 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA08282 for linux-audio-dev-list; Fri, 29 Oct 1999 15:38:29 -0400
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA08279 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 29 Oct 1999 15:38:24 -0400
Received: from d1o43.telia.com (d1o43.telia.com [194.22.195.241])
	by mailb.telia.com (8.9.3/8.9.3) with ESMTP id VAA01110;
	Fri, 29 Oct 1999 21:34:06 +0200 (CEST)
Received: from skelleftea.mail.telia.com (t6o43p2.telia.com [194.237.168.62])
	by d1o43.telia.com (8.8.8/8.8.5) with ESMTP id VAA15280;
	Fri, 29 Oct 1999 21:34:04 +0200 (CEST)
Message-ID: <381A0093.1A1FAF2F@skelleftea.mail.telia.com>
Date: Fri, 29 Oct 1999 21:16:19 +0100
From: Roger Larsson <roger.larsson@skelleftea.mail.telia.com>
X-Mailer: Mozilla 4.6 [en] (Win95; I)
X-Accept-Language: sv,en
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
CC: linux-sound@vger.rutgers.edu
Subject: Re: [linux-audio-dev] Re: Sync Issues (was Re: External MIDI Sync using 
 OSS/Free)
References: <199910281517.LAA12294@renoir.op.net> <99102902112102.00774@linuxhost.localdomain>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by mailb.telia.com id VAA01110
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id QAA21816
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: de8c732e92f332502f5e8753959085c5



Benno Senoner wrote:
> 
> On Thu, 28 Oct 1999, Paul Barton-Davis wrote:

> > to an old ISA-based Diamond Speedstar, the performance of my audio
> > stuff has gone down the tubes. i can't do *anything* with X and hope
> > to not get dropouts. this never happened with the Matrox card, and i
> > am very confident that as soon as Matrox ships me a new one, the
> > problem will go away.
> >
> > right now, my system is essentially useless for audio work unless you
> > avoid using X. totally useless. i can't even play WAV files without
> > *huge* dropouts, and thats on a *dual* PII-450 !
> 
> Yes,
> 
> the idiotproof test is the following:
> install 2.2.10 + lowlatency patch  ( not SMP !),
> tune the IDE diskas as described in the README
> and run a testsession
> if the GFX stress graph is the only bad graph,
> then I'm sorry but you have to throw away your videocard if you want
> to do reliable low latency stuff.
> :-)
> 

Or you can try to find out what part of your video card driver that
destroys latency and correct that.

You can find out the problematic spot with my patch:
 latency-profiling-2.2.10-r6.patch [for Linux 2.2.10]
I will put it on some own web page at the moment you could get it from:

http://www.gardena.net/benno/linux/audio/patches/latency-profiling-2.2.10-r5.patch

And remove this part of the patch since it is not correct...
(you should not be tempted to improve things in an instrumentation
patch...)
 
-       if (tq_scheduler)
+       //RL latency improvement, correct?
+       //RL skip if forced reschedule (a normal will arrive soon...)
+       if (!current->need_resched && 
+           tq_scheduler)

The results are messages in 'dmesg', latency time and instruction
pointers
are printed. You then decode the instruction pointers to routine name.
 
/RogerL

-- 

The Internet interprets Windows as damage, 
             and routes around it.

Roger Larsson
Skellefte
Sweden

From - Fri Oct 29 17:16:48 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA27828
	for <slinkp@ulster.net>; Fri, 29 Oct 1999 17:06:12 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA08422 for linux-audio-dev-list; Fri, 29 Oct 1999 16:31:26 -0400
Received: from chekov.Belgium.EU.net (chekov.belgium.eu.net [193.74.208.161]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA08419 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 29 Oct 1999 16:31:23 -0400
Received: from (adial182.liege.eunet.be [195.207.174.182])
	by chekov.Belgium.EU.net  with SMTP id WAA12720;
	Fri, 29 Oct 1999 22:27:12 +0200 (MET DST)
Subject: Re: [linux-audio-dev] please end crossposting !
From: Benjamin GOLINVAUX <golinvaux@benjamin.net>
Reply-To: Benjamin GOLINVAUX <golinvaux@benjamin.net>
In-Reply-To: <381A04D4.CDD12AD8@folkwang.uni-essen.de>
Message-ID: <0003580ad50d483b_mailit@relay.eunet.be>
References: <381A04D4.CDD12AD8@folkwang.uni-essen.de>
Date: Fri, 29 Oct 1999 22:21:17 +0200
X-Mailer: BeatWare Mail-It 2.0.3
X-BeOS-Platform: Intel or clone
X-Priority: 3 (Normal)
To: linux-audio-dev@ginette.musique.umontreal.ca
Cc: linux-sound@vger.rutgers.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 865664ad6c4015efb35fe435078948a6

what's the difference between those lists ?

Benjamin-


From - Fri Oct 29 17:16:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA20559
	for <slinkp@ulster.net>; Fri, 29 Oct 1999 16:17:32 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA08277 for linux-audio-dev-list; Fri, 29 Oct 1999 15:30:58 -0400
Received: from icemserv.folkwang.uni-essen.de (icemserv.folkwang.uni-essen.de [132.252.170.129]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA08274 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 29 Oct 1999 15:30:39 -0400
Received: from folkwang.uni-essen.de (nettings@dialup7.folkwang.uni-essen.de [132.252.170.7]) by icemserv.folkwang.uni-essen.de (8.8.8/8.7.3) with ESMTP id UAA08421; Fri, 29 Oct 1999 20:29:50 +0200 (CEST)
Message-ID: <381A04D4.CDD12AD8@folkwang.uni-essen.de>
Date: Fri, 29 Oct 1999 20:34:28 +0000
From: =?iso-8859-1?Q?J=F6rn?= Nettingsmeier <nettings@folkwang.uni-essen.de>
Reply-To: nettings@folkwang.uni-essen.de
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
CC: linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] please end crossposting !
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: eaa9f533e63001b57d4349ccdcd0603d

hello everybody !

i'm one of the poor lads who are subscribed to *both* l-a-d and l-s.
somehow it seems to have become fashionable to crosspost everything.
but this is not usenet, most mail readers *do not* erase duplicates,
and each messages is actually carried and displayed twice.
moreover, it works around my mail filters and makes my folders go
haywire !
this is really a drag, apart from being a huge waste of bandwidth.

imho, crossposting is inappropriate for the majority of messages
that showed up lately.
if you definitely think your message has to go to both groups,
specify *one* return address in your initial posting and carry on
with the discussion in either group, but not both !

please think about this.

yours

jrn

ps: forgive me this one time. i know i have sinned. i shall never
cc: again.  >;->


-- 
Jrn Nettingsmeier     
Kurfrstenstr. 49        
45138 Essen, Germany

From - Sat Oct 30 15:06:02 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA06644
	for <slinkp@ulster.net>; Fri, 29 Oct 1999 18:27:51 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA08567 for linux-audio-dev-list; Fri, 29 Oct 1999 17:54:58 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA08564 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 29 Oct 1999 17:54:55 -0400
Received: from localhost.localdomain (d212-151-107-251.swipnet.se [212.151.107.251]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id XAA11157; 
          Fri, 29 Oct 1999 23:50:28 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Billy Biggs <vektor@DIV8.NET>, Benno Senoner <sbenno@gardena.net>
Subject: [linux-audio-dev] Re: Sync Issues (was Re: External MIDI Sync using OSS/Free)
Date: Fri, 29 Oct 1999 23:01:31 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca,
        linux-sound@vger.rutgers.edu
References: <Pine.LNX.4.04.9910280938390.31398-100000@shell.dhp.com>
In-Reply-To: <Pine.LNX.4.04.9910280938390.31398-100000@shell.dhp.com>
MIME-Version: 1.0
Message-Id: <99102923261401.00467@localhost.localdomain>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA06644
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: b07ccb6b70fceba4aefdb473d08bb394

On Thu, 28 Oct 1999, Billy Biggs wrote:
> > Do not forget to apply the lowlatency patches, or your timing will
> > simply suck ! even an untuned IDE disk, when it reads/writes a small
> > amount of data from/to the disk, could cause 20-50ms delay in your app
> > and this is very bad for MIDI. ( see my tests , especially the non DMA
> > ones = horrible :-)  )
> 
>   What lowlatency patches??  kernel patches??  That's just ugly.  Where
> can I get them?

There's no way you'll ever have real time performance in a non-RT
system... The pre 2.2 and 2.2 "RT" was flawed, and close to useless,
so it had to be fixed. As far as we have seen, the patch has no effect
on, or even improves performance of non-real time stuff. The patch is
not an uggly RT scheduling hack, but a quite clean and very useful
improvement. (Especially to us audio guys, and to multimedia folks in
general. :-)

>   How can you tell if you've underrun under OSS?  Using ALSA, I guess you
> can use it's time stuff to calculate if you've missed a frame, but even
> that seems hacky.

Waitaminnit'... "Underrun" is a severe error condition, and must
never occur in a real time system. What you need to know is when you
can throw in another buffer. Before generationg the buffer, you also
need to know exactly when it will be played, in relation to your
time base.

>   I don't like using one dsp as the sync master since I always want to be
> able to sync to something external, like MIDI.

Sync master, no; bad idea. *Timing* master is different, though. You
have to decide on one single sample rate to use in your engine, and
that one is easiest derived from the timing master card. This card's
play position is what you use as your system time base.

>   So, the problem becomes, how do you sync many soundcards and have it all
> synced off external MIDI. :)

You could run one engine/card, and just translate all "MIDI event"
timestamps (the ones you set when you recieve the events) to the time
base of the engine each one is sent to.

Or you have only one engine thread, running at the sample rate of
the timing master card, resampling all data that doesn't match that
sample rate. That would include any streamed audio tracks, as their
playback rates would have to follow the external MIDI clock.

Alternatively, you run the engine at the sample rate of the audio
tracks, and resample for *all* audio cards. However, that;

1) ...doesn't make much sense unless all audio tracks are recorded
   with the exact same sample rate. (Which will *not* be the case
   if they were recorded on different cards!)

2) ...means you have to resample for all cards, including the one
   that still actually acts as timing master, in that your engine
   syncs to it.

3) ...results in weird buffer sizes through the engine. (You do
   the math here; I've seen enough of that variant, I think...)

So, timing master is one thing, sync master is another. You can see
it as the engine running at a fixed rate no matter what you do,
resampling data and adjusting the sequencer/automation tempo as needed
to follow the external sync clock.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Oct 29 18:06:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA02930
	for <slinkp@ulster.net>; Fri, 29 Oct 1999 17:59:41 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA08509 for linux-audio-dev-list; Fri, 29 Oct 1999 17:19:04 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA08506 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 29 Oct 1999 17:19:02 -0400
Received: from ulster.net (port145.ts2.ulster.net [208.242.164.145])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id RAA29755;
	Fri, 29 Oct 1999 17:19:26 -0400
Message-ID: <381A102D.EEC044F@ulster.net>
Date: Fri, 29 Oct 1999 17:22:53 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: jiva@mindless.com,
        "linux-audio-dev@ginette.musique.umontreal.ca" 
 <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Linux audio questions...
References: <199910291244.IAA04849@renoir.op.net> <3819CDFE.8933DEAD@ulster.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 122634ffe9e819919b53629079e253df

Whoops, there's a mistake in that csound orc I posted. At the end,
this section:

>   done:
>     aout  oscili  kamp, ifreq * klfo, 1  ;  use f1 for audio table
>   out     aout
> endin

... you should replace "oscili" with "loscil".

loscil3 would sound better than loscil but it doesn't seem to work
at the moment.

----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.
email=========================slinkp AT ulster DOT net
ARMS online=======================http://reacharms.com    
personal page===========http://www.ulster.net/~abigoo/

From - Sat Oct 30 15:06:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA08167
	for <slinkp@ulster.net>; Fri, 29 Oct 1999 18:39:08 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA08632 for linux-audio-dev-list; Fri, 29 Oct 1999 18:08:20 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA08629 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 29 Oct 1999 18:08:17 -0400
Received: from localhost.localdomain (d212-151-107-251.swipnet.se [212.151.107.251]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA18960 for <linux-audio-dev@ginette.musique.umontreal.ca>; 
          Sat, 30 Oct 1999 00:04:07 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Some DSP links
Date: Sat, 30 Oct 1999 00:09:17 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <99103000114103.00467@localhost.localdomain>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA08167
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 7a9df6deac87c910d95d15e7a6c24b1a


Found this when looking for some "noise reduction for control systems"
stuff earlier today;

	http://www.hut.fi/Misc/Electronics/dsp.html


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Oct 30 15:06:15 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA11887
	for <slinkp@ulster.net>; Fri, 29 Oct 1999 19:08:59 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA08668 for linux-audio-dev-list; Fri, 29 Oct 1999 18:36:08 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA08665 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 29 Oct 1999 18:36:05 -0400
Received: from localhost.localdomain (d212-151-107-251.swipnet.se [212.151.107.251]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA29778; 
          Sat, 30 Oct 1999 00:25:47 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: alsa-devel@alsa-project.org, Paul Barton-Davis <pbd@Op.Net>,
        alsa-devel@alsa-project.org
Subject: [linux-audio-dev] Re: [alsa-devel] Re: Timestamping
Date: Sat, 30 Oct 1999 00:18:37 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <199910281225.IAA23191@renoir.op.net>
In-Reply-To: <199910281225.IAA23191@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99103000332104.00467@localhost.localdomain>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA11887
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 4d4cbd5c3df5930f94890cb09c0ad435

On Thu, 28 Oct 1999, Paul Barton-Davis wrote:
> i am a little sceptical of SGI's implementation, however - its not
> clear whether they are doing kernel/driver timestamping or
> inferencing. also, the fact that you cannot use read(2)/write(2)
> anymore is always a negative from my perspective, but hey, alsa-lib
> challenges that model already. i will just be sad to have to abandon
> read/write for MIDI in order to get timestamps, but i see no other way
> of doing it.

Well, an ioctl() that returns the timestamp of the next sample you'll
get from read() or write() seems possible to me, as a first idea...
What am i missing?

> i am very intrigued by their description of when the timestamp is done
> for audio. they claim to timestamp analog data at "the instant the
> voltage is sampled or produced" and digital data at the "edge of the
> recovered sample clock from the input signal or the driving sample
> clock for the output signal".
> 
> do we have any hope of doing this ? does SGI ? :)

It's possible to do within a few s (worst case 25 s on a P120;
around 3 on a Celeron) with RTLinux drivers, if the hardware is well
known and/or calibrated. I don't know the figure for standard Linux
with the lowlatency patch, but the "average" case should be about the
same as with RTL. Drivers with slow IRQ handlers will make the worst
case orders of magnitude worse, though.

Calibration at this level is non-trivial, at least to the average
user; you need to be able to generate and measure signals with some
device with known, or at least very low latency. A driver, a buffer
and two probes connected to the parallel port shold do.

Of course, we could measure the latencies of all hardware we can get
at, and build reasonable defaults into the drivers. Should hit within
some .1 ms or so, probably better.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Oct 30 15:06:10 1999
Received: from pop06.iname.net (pop06.iname.net [165.251.8.76])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id TAA11016
	for <slinkp@ulster.net>; Fri, 29 Oct 1999 19:01:40 -0400
Received: from mindless.com ([216.111.166.87])
	by pop06.iname.net (8.9.3/8.9.3) with ESMTP id SAA20661
	for <slinkp@ulster.net>; Fri, 29 Oct 1999 18:56:07 -0400 (EDT)
Message-ID: <381A25B4.E3CE0219@mindless.com>
Date: Fri, 29 Oct 1999 15:54:45 -0700
From: jiva <jiva@mindless.com>
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: Paul Winkler <slinkp@ulster.net>
Subject: Re: [linux-audio-dev] Linux audio questions...
References: <199910290135.VAA13675@renoir.op.net> <38193984.3F7622D4@mindless.com> <3819D6D7.C32B8E7D@ulster.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: c754d40bba4a774983b2d2bb04b1c147

Paul Winkler wrote:
>
> I get the impression you haven't actually used csound much (or at
> all?). I'll take the liberty of commenting a little:
>
true, but I've read up enough to know that I'm not entirely restricting
myself, and I find the idea of limitations exhilarating to a certain
degree, so it will work out alright. again, though - I have not written
any csound code yet, but I'm familiar with modular instrument design and
programming to a certain degree (read basic, assembly and pascal during
my formative years) and look forward to the oppurtunity of reacquainting
myself with the thought process.
 
> csound is actually very versatile at processing sound. It just takes

I can tell!

> some time to learn how to get simple sounds out of it, then some
> more time to stop making the same mistakes over and over, then some
> more time learning something about synthesis to understand how to
> translate ideas into csound, then some more time browsing the manual
> trying to find the "opcodes" that will enable you to do the things
> you want, then lots more time to get your instruments to actually
> please you. In short, it takes lots ... and lots... of time.
> 
> Where I think csound is _very_ restrictive is in two places:
> 
> 1) The score language is very flexible and very primitive. It's way
> too cumbersome to actually compose music "by hand" with it. Many
> people use MIDI and convert to csound one way or another. Other
> options are using a spreadsheet, or using "helper" apps or languages
> such as Silence, common music, sybil, cscore, etc. to generate
> csound scores.
> 
> 2) The orc language is really pretty dumb when looked at as a
> programming language. There will be times when you want instruments
> that behave one way some of the time, and another way under other
> conditions. In csound you have to learn to understand a pretty
> ancient kind of programming logic: the only tools are "if" and
> "goto", which you generally use like this:
> 
> if <some_condition> goto some_label_name
>    <here you put things to do if some_condition is NOT true>
>    goto end_of_tests
> some_label_name:
>   <here you put things to do if some_condition IS true>
> end_of_tests:
>    <we end up here after either condition>
> 

sounds like c64 basic to me, minus the <if condition is not true>,
meaning you would have to add a second condition elsewhere. I think I'm
prepared to experiment within this context.

> This looks weird to anyone who knows even a little of any
> programming language invented since, oh, say, 1970, because in C,
> perl, python, java, and I don't know how many other languages, the
> "if" is followed immediately by what you want to do if the condition
> IS true. So in csound you have to learn to think in this peculiar
> "backwards" manner.
> 

hehehehe

----- omitted: informed answers about other applications besides csound.

> > > if you want csound to do complex stuff, you'd better plan on doing
> > > quite a bit of non-real-time synthesis.
> > >
> >
> > What I'm planning on doing is completing long passages of fairly simple
> > ambience - say two and a half minutes of arpeggios in 7/8 with a couple
> > of very slow lfos and envelopes creating modulation sweeps - printing
> > the audio files, adding fx later and then ultimately merging them in a
> > program such as SLab. I don't want to send it so much information it
> > patches out. That's the idea right now I suppose...
> 
> This is doable. One way to do more realtime work in csound is, when
> things get too complex to render in realtime, render what you've got
> so far into a soundfile, then read it in to a new orc / sco using a
> simple "diskin" instrument, then add more instruments or voices or
> whatever. You can always go back later and change the orc/sco that
> created the rendered file if you want to modify it.

yeah, I imagine that would work very well.
 
> (stuff about soundcards snipped)
> If you haven't yet, you should check my Audio-Quality-HOWTO at:
> http://www.ulster.net/~abigoo/pw_linux/Audio-Quality-HOWTO.html
> 
> It's not always the most up to date information, but I try. :)

I hadn't seen it - great page!

> > > >I'm very curious also if anyone has completed any commercially released
> > > >CDs using Linux as the sole platform for composing and recording.
> 
> Hmm, I'd better get moving. I kind of wanted to be the first guy to
> be able to say he did this, but I haven't really got anywhere with
> it yet. I'll race ya. :)
> 

you are a bit ahead of me! at least you are currently running Linux and
have written some technical documentation concerning sound and Linux. It
could take me a while, I tend to do fairly involved things with sound,
and csound and keykit are very extensive - no to mention other apps that
are available.

> > Thanks again, I'm planning on keeping a diary of my experiences with
> > Linux and Linux sound apps during the course of this project.
> 
> This is a good idea -- you should put it online so other linux sound
> newbies can read it.. I meant to do something like this but I
> haven't found the time.
> 

I'm hoping once I have enough material to post it... starting when I
pack up my win95 files and go to my first linux meeting I'll start
documenting.

> ----------------    paul winkler    ------------------
> slinkP arts:  music, sound, illustration, design, etc.
> email=========================slinkp AT ulster DOT net
> ARMS online=======================http://reacharms.com
> personal page===========http://www.ulster.net/~abigoo/

checked out the websites - I like the arms material, though I only
checked out two mp3s. I think I liked seperation the best though I liked
the hardness and shout-outs in nines, too. I liked the conscious lyrics
and unique format.

Ian
www.mp3.com/iread

From - Sat Oct 30 15:06:16 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA14604
	for <slinkp@ulster.net>; Fri, 29 Oct 1999 19:31:29 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA08687 for linux-audio-dev-list; Fri, 29 Oct 1999 19:00:02 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id SAA08684 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 29 Oct 1999 18:59:59 -0400
From: est@hyperreal.org
Received: (qmail 17066 invoked by uid 162); 29 Oct 1999 22:55:49 -0000
Message-ID: <19991029225549.17065.qmail@hyperreal.org>
Subject: [linux-audio-dev] s1 updated & python news
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Fri, 29 Oct 1999 15:55:49 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 376d103503d910a07fb8ff983f50db42

There's an updated version of the csound-based-MIDI-sampler s1 at 
www.hyperreal.org/~est/csound/s1/s1-0.1.1.tar.gz

Paul Winkler was kind enough to go over s1.py and explain what's going
on in comments! :D

This is far from an application..more example code for python and/or
csound.  OTOH, it does make real sounds.

In other python news, I've been having trouble getting my python
MidiIn library to be sluggish under controlled testing.  I've spewed
1000 continuous controller events a second at a test program using it
and the processor load was much better than I expected.  There's still
got to be a reason why handling such events is disturbingly sluggish
in oolaboola, but it may lie somewhere in gtk/pygtk.  Anyhow, it's
some reason to be less pessimistic regarding python than I have been
in the recent past.  The MidiIn library should receive independent
release RSN.

Eric

From - Sat Oct 30 15:06:14 1999
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA11510
	for <slinkp@ulster.net>; Fri, 29 Oct 1999 19:05:40 -0400
From: est@hyperreal.org
Received: (qmail 18290 invoked by uid 162); 29 Oct 1999 22:58:33 -0000
Message-ID: <19991029225833.18289.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] Linux audio questions...
In-Reply-To: <381A11FE.7247820B@ulster.net> from Paul Winkler at "Oct 29, 1999
 05:30:38 pm"
To: Paul Winkler <slinkp@ulster.net>
Date: Fri, 29 Oct 1999 15:58:32 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: a8051e511fe56d43b81476fd0f53be48

Paul Winkler discourseth:
> 
> I've been working my way through "learning python" and I was
> intrigued by your python / midi / csound gadgets. I just spent an
> hour playing with bits of your code at the python prompt to figure
> out what you're doing. Pretty cool.

Have you checked out the MidiIn module in oolaboola?  You may find it
useful.

> Attached is a pretty thoroughly commented (otherwise unmodified)
> version of s1.py in case you find that useful for anything.

I've posted it..thanks! :)

E

From - Fri Oct 29 18:26:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA05829
	for <slinkp@ulster.net>; Fri, 29 Oct 1999 18:21:42 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA08558 for linux-audio-dev-list; Fri, 29 Oct 1999 17:49:22 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA08555 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 29 Oct 1999 17:49:16 -0400
Received: from linuxhost.localdomain (IDENT:root@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id XAA05686;
	Fri, 29 Oct 1999 23:44:59 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id BAA00799;
	Sat, 30 Oct 1999 01:45:24 +0200
From: Benno Senoner <sbenno@gardena.net>
To: Roger Larsson <roger.larsson@skelleftea.mail.telia.com>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Sync Issues (was Re: External MIDI Sync using OSS/Free)
Date: Sat, 30 Oct 1999 01:40:07 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <381A0093.1A1FAF2F@skelleftea.mail.telia.com>
MIME-Version: 1.0
Message-Id: <99103001452400.00737@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 10842474a5839166a36f2e499b6f0c57

On Fri, 29 Oct 1999, Roger Larsson wrote:
>> 
> Or you can try to find out what part of your video card driver that
> destroys latency and correct that.
> 
> You can find out the problematic spot with my patch:
>  latency-profiling-2.2.10-r6.patch [for Linux 2.2.10]
>> 
> The results are messages in 'dmesg', latency time and instruction
> pointers
> are printed. You then decode the instruction pointers to routine name.
>  
> /RogerL

Not quite correct: actually it's not a driver's fault !
In most cases the audio dropout while doing heavy GFX is caused by PCI busmaster
transfers by the gfx card that hogs the entire PCI bus for SEVERAL milliseconds,
in order to provide better gfx throughput.
On some cards you can avoid this problem by setting a special variable into
your XF86Config (no sample handy at the moment) , which slows down the gfx
performance a bit but gives you better lowlatency performance.

On some other cards the only solution is to throw your gfx card out of the
nearest window.
:-)

PS: Benjamin, I stopped the crossposting , at least for this mail.
:-)

Benno.

From - Sat Oct 30 15:06:20 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA23473
	for <slinkp@ulster.net>; Fri, 29 Oct 1999 20:44:49 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA08809 for linux-audio-dev-list; Fri, 29 Oct 1999 20:12:37 -0400
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA08806 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 29 Oct 1999 20:12:34 -0400
Received: from localhost.localdomain (d212-151-107-251.swipnet.se [212.151.107.251]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA06756; 
          Sat, 30 Oct 1999 02:08:18 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Benno Senoner <sbenno@gardena.net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Timestamped MIDI interfaces ....
Date: Sat, 30 Oct 1999 01:52:58 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <99102916521601.00738@linuxhost.localdomain>
In-Reply-To: <99102916521601.00738@linuxhost.localdomain>
MIME-Version: 1.0
Message-Id: <99103002155206.00467@localhost.localdomain>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA23473
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2b25af6933afa42f047dcb117335839b

On Fri, 29 Oct 1999, Benno Senoner wrote:
> Hi folks,
> what do you think about this timestamping MIDI interface ?
> 
> http://www.harmony-central.com/Newp/107AES/MOTU/MTS.html
> 
> seems that our upcoming timestamped event system could easily drive this
> beast. :-)

Well... They're still dealing with MIDI. It's basically just a
performance hack to solve one of the most serious problems with MIDI,
at least in systems with many MIDI devices. (It won't help much for a
single synth, unless it's very accurate and has at least two MIDI
inputs.)

Our system OTOH, is operating in a slightly different area; it's not
really a dedicated MIDI style communication protocol, but rather an
advanced IPC API. However, such an API can be made network
transparent and other coll things...

And what about a simple streaming interface for those who don't even
want to link in the API lib? My event header currently looks like
this:

-----8<------------------------------------------------------------
typedef unsigned long long mcs_event_time_t;
typedef unsigned int mcs_event_code_t;
struct mcs_event_t {
	struct mcs_event_t	*next;	/* for the oport list */
	mcs_event_time_t	time;
	mcs_event_code_t	code;
	int			size;	/* Number of data bytes */
};
------------------------------------------------------------>8-----

Version for read()/write()/ioctl() API:

-----8<------------------------------------------------------------
typedef unsigned long long mcs_event_time_t;
typedef unsigned int mcs_event_code_t;
typedef unsigned int mcs_port_id_t;
struct mcs_event_t {
	mcs_port_id_t		port;	/* where to send */
	mcs_event_time_t	time;
	mcs_event_code_t	code;
	int			size;	/* Number of data bytes */
};
------------------------------------------------------------>8-----

Send across suitable interface (serial, parallel, USB, dedicated or
RT ethernet, ...), and have a MuCoS client turn it into real events
on the other side. That client may of course be an RTLinux engine,
running on an embeded PC-104 system, driving a bunch of MIDI UARTs.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Oct 30 15:06:19 1999
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id UAA20948
	for <slinkp@ulster.net>; Fri, 29 Oct 1999 20:24:44 -0400
Received: from localhost.localdomain (d212-151-107-251.swipnet.se [212.151.107.251]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA09774; 
          Sat, 30 Oct 1999 02:19:59 +0200 (MET DST)
From: David Olofson <audiality@swipnet.se>
To: Paul Winkler <slinkp@ulster.net>, jiva@mindless.com
Subject: Re: [linux-audio-dev] Linux audio questions...
Date: Sat, 30 Oct 1999 02:19:54 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: "linux-audio-dev@ginette.musique.umontreal.ca" <linux-audio-dev@ginette.musique.umontreal.ca>
References: <199910291244.IAA04849@renoir.op.net> <3819CDFE.8933DEAD@ulster.net>
In-Reply-To: <3819CDFE.8933DEAD@ulster.net>
MIME-Version: 1.0
Message-Id: <99103002273307.00467@localhost.localdomain>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA20948
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 96f2bae33d94662a835e5bdca182b08d

On Fri, 29 Oct 1999, Paul Winkler wrote:
> Also cool: You don't even really need a separate monitor for the
> midi box. You could set it up as a "headless box" which you
> interface entirely from your main system. Run console or X apps on
> the 486 and see them displayed on your audio system's screen, and
> save the cost, electrical usage, and desktop space of a separate
> monitor. Granted I have never actually _done_ this, I've just heard
> about it.

Well, I played XGalaga across our sloppy 10 Mbit network at work, and
there was no noticeable performance degradation; the pixmaps are
uploaded to the X server, and the latency of further operations was
certainly not a problem. However, I haven't seriously been using
applications that way for extended periods, so I can't say how well
it works with Qt, GTK+ (toolkits run on the application side - not
with the X server!), various applications and so on...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Oct 30 15:06:28 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA12005
	for <slinkp@ulster.net>; Sat, 30 Oct 1999 09:12:41 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA13672 for linux-audio-dev-list; Sat, 30 Oct 1999 08:42:04 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA13669 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 30 Oct 1999 08:42:01 -0400
Received: from someip.ppp.op.net (d-bm3-03.ppp.op.net [209.152.194.67]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id IAA17952 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 30 Oct 1999 08:37:49 -0400 (EDT)
Message-Id: <199910301237.IAA17952@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Sync Issues (was Re: External MIDI Sync using OSS/Free) 
In-reply-to: Your message of "Sat, 30 Oct 1999 01:40:07 +0200."
             <99103001452400.00737@linuxhost.localdomain> 
Date: Sat, 30 Oct 1999 09:34:15 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 421346ac571cc4783e4f02d1a11b3e22

>Not quite correct: actually it's not a driver's fault !  In most
>cases the audio dropout while doing heavy GFX is caused by PCI
>busmast er transfers by the gfx card that hogs the entire PCI bus for
>SEVERAL millisecond s, in order to provide better gfx throughput. 

in my case, its an ISA card, so there is none of this PCI bus crap at
work, and its the standard VGA driver.

>On some other cards the only solution is to throw your gfx card out of the
>nearest window.
>:-)

or wait for the delivery truck to return a better one from the
manufacturer. oh happy day ...

From - Sat Oct 30 15:06:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA13154
	for <slinkp@ulster.net>; Sat, 30 Oct 1999 09:25:20 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA13725 for linux-audio-dev-list; Sat, 30 Oct 1999 08:47:52 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA13722 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 30 Oct 1999 08:47:50 -0400
Received: from someip.ppp.op.net (d-bm3-03.ppp.op.net [209.152.194.67]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id IAA18224 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 30 Oct 1999 08:43:38 -0400 (EDT)
Message-Id: <199910301243.IAA18224@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Linux audio questions... 
In-reply-to: Your message of "Fri, 29 Oct 1999 13:18:15 EDT."
             <3819D6D7.C32B8E7D@ulster.net> 
Date: Sat, 30 Oct 1999 09:40:04 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: db5166e309eb68256e3b5ef3cde15072

In message <3819D6D7.C32B8E7D@ulster.net>you write:
>jiva@mindless.com wrote:
>> 
>> > >                                     - most music will probably be coded
>> > >in csound.
>> >
>> > fairly restrictive :)
>
>I get the impression you haven't actually used csound much (or at
>all?). I'll take the liberty of commenting a little: 

Paul - the attributions here are wrong. It was me who commented that
only using Csound was fairly restrictive, and it wasn't so much a
comment on Csound, but on not the idea of not using any outboard
h/w. I'll let anyone else how much *i* have actually used Csound :)

>Now imagine trying to write a csound instrument with conditional
>tests nested inside other conditional tests. I haven't been brave
>enough to try that yet.

if <condition1> goto second_test
   ... stuff to do when condition1 is false ...
   goto end_tests

second_test:
   if <condition2> goto all_true
      ... stuff to do when condition1 is true and condition2 is false ...
      goto end_tests

all_true:             
      ... stuff to do when condition1 is true and condition2 is true ...

end_tests:
      ... proceed ...

there, what could possibly be wrong with that ? :))))


From - Sat Oct 30 15:06:31 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA13210
	for <slinkp@ulster.net>; Sat, 30 Oct 1999 09:25:55 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA13772 for linux-audio-dev-list; Sat, 30 Oct 1999 08:56:12 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA13769 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 30 Oct 1999 08:56:10 -0400
Received: from someip.ppp.op.net (d-bm3-03.ppp.op.net [209.152.194.67]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id IAA18555 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 30 Oct 1999 08:51:57 -0400 (EDT)
Message-Id: <199910301251.IAA18555@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Linux audio questions... 
In-reply-to: Your message of "Fri, 29 Oct 1999 08:58:44 PDT."
             <19991029155845.15397.qmail@hyperreal.org> 
Date: Sat, 30 Oct 1999 09:48:24 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: db3c5f642caef2b6176a384944461add

>Paul Barton-Davis discourseth:
>> if by sequencing, you just mean MIDI sequencing: be sure to use a
>> cheap, old, 2nd hand box for the sequencing one. i have a 100MHz
>> 486-DX that sits (mostly idle) next to my main rack (which holds a
>> dual PII-450 as my "main" computer). the 486 is *more than adequate*
>> for any Linux MIDI sequencing task you can imagine.
>
>Hmm..doesn't it depend on the sequencer(s)?  How much of that
>processor does softwerk use.  I expect the next-generation of softwerk
>will use more.  What if a sequencer were written in Python?  "Software
>is a gas." :)

i think i would still stick to the claim that even a 486-100 should be
able to do this. its really just a question of how much work the
software will do per clock tick (whether its SIGIO from the RTC,
SIGALRM from sigitimer or whatever). i find it *very* hard to believe
that any MIDI-only sequencer will ever have too much to do in that
interval. even a hyperseq-like system - i mean, whats the longest time
you've ever seen a spreadsheet take for a full-cell update. duh. don't
answer that :) lets just say that the current meaning of "sequencer"
(i.e. "i have 162,234 recorded notes of MIDI along with 23,000
controller messages, and i want them all played back") will *never*
cause there to be too much work to do per clock tick. OK, OK: all
162,234 notes are to be played simultaneously by the largest ensemble
of outboard synths you've ever seen - yes, then we'd have a problem :)

Of course, it might have a lot of graphics to do, but that should in a
separate thread, and should never block the actual "sequencer"
thread. So yes, the screen representation might lag whats actually
happening for a few hundred milliseconds, or perhaps even a second,
but the MIDI output would still be totally precise.

>I'd actually like some cheapo machines myself.  I always worry about
>how I'll find replacement parts for them.  It can be pretty difficult
>to find new cpus below a certain clock-rate, for example.  Does one
>just use used replacement parts?  

my attitude (and it hasn't been tested yet) is to throw away the box
if that happens. these things are like paperweights these days.

--p

From - Sat Oct 30 15:06:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA22896
	for <slinkp@ulster.net>; Sat, 30 Oct 1999 11:05:53 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA13989 for linux-audio-dev-list; Sat, 30 Oct 1999 10:37:21 -0400
Received: from pop06.iname.net (pop06.iname.net [165.251.8.76]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA13986 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 30 Oct 1999 10:37:19 -0400
Received: from mindless.com ([216.111.166.87])
	by pop06.iname.net (8.9.3/8.9.3) with ESMTP id KAA16811;
	Sat, 30 Oct 1999 10:33:04 -0400 (EDT)
Message-ID: <381B0128.9A4BBB09@mindless.com>
Date: Sat, 30 Oct 1999 07:31:04 -0700
From: jiva <jiva@mindless.com>
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Linux audio questions...
References: <199910301251.IAA18555@renoir.op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1ca7a137887bc1ed19082c5598fbc50d

Paul Barton-Davis wrote:
> 
> >Paul Barton-Davis discourseth:
> >> if by sequencing, you just mean MIDI sequencing: be sure to use a
> >> cheap, old, 2nd hand box for the sequencing one. i have a 100MHz
> >> 486-DX that sits (mostly idle) next to my main rack (which holds a
> >> dual PII-450 as my "main" computer). the 486 is *more than adequate*
> >> for any Linux MIDI sequencing task you can imagine.
> >
> >Hmm..doesn't it depend on the sequencer(s)?  How much of that
> >processor does softwerk use.  I expect the next-generation of softwerk
> >will use more.  What if a sequencer were written in Python?  "Software
> >is a gas." :)
> 

ok, the sequencer is keykit and it will be running on an amd k6-200 with
40MB of ram, so I don't think clock speed is going to be an issue...
what will be an issue is what network card, video card and IDE HD to
use. I'd like to use SCSI, but I don't want to spend too much on a box
just for sequencing. At this point, these questions are probably best
addressed to another list, you know, [linux-box-newbie].

> i think i would still stick to the claim that even a 486-100 should be
> able to do this. its really just a question of how much work the
> software will do per clock tick (whether its SIGIO from the RTC,
> SIGALRM from sigitimer or whatever). i find it *very* hard to believe
> that any MIDI-only sequencer will ever have too much to do in that
> interval. even a hyperseq-like system - i mean, whats the longest time
> you've ever seen a spreadsheet take for a full-cell update. duh. don't
> answer that :) lets just say that the current meaning of "sequencer"
> (i.e. "i have 162,234 recorded notes of MIDI along with 23,000
> controller messages, and i want them all played back") will *never*
> cause there to be too much work to do per clock tick. OK, OK: all
> 162,234 notes are to be played simultaneously by the largest ensemble
> of outboard synths you've ever seen - yes, then we'd have a problem :)
> 
> Of course, it might have a lot of graphics to do, but that should in a
> separate thread, and should never block the actual "sequencer"
> thread. So yes, the screen representation might lag whats actually
> happening for a few hundred milliseconds, or perhaps even a second,
> but the MIDI output would still be totally precise.
> 

keykit's graphics are basic at best, but still not like cakewalk for DOS
which I used to great satisfaction for many years on a 286 with two megs
or RAM and seemed to hold time much tighter than the first time I used
cakewalk audio on Win3.1 - my first GUI letdown. Still, I would think
with the box, the OS and that I'm going to go for... oh, btw - best
cheap MIDI soundcard? - video card, tuned drive (I still don't know what
this means)... it should be ample.

> >I'd actually like some cheapo machines myself.  I always worry about
> >how I'll find replacement parts for them.  It can be pretty difficult
> >to find new cpus below a certain clock-rate, for example.  Does one
> >just use used replacement parts?
> 
> my attitude (and it hasn't been tested yet) is to throw away the box
> if that happens. these things are like paperweights these days.
> 
> --p

From - Sat Oct 30 15:06:37 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA32672
	for <slinkp@ulster.net>; Sat, 30 Oct 1999 12:39:31 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA14165 for linux-audio-dev-list; Sat, 30 Oct 1999 12:08:31 -0400
Received: from gate.suse.cz (perex.cb.cesnet.cz [194.212.165.105]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA14162 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 30 Oct 1999 12:08:28 -0400
Received: from localhost (perex@localhost)
	by gate.suse.cz (8.8.8/8.8.8) with ESMTP id RAA05243;
	Sat, 30 Oct 1999 17:54:50 +0200
X-Authentication-Warning: gate.suse.cz: perex owned process doing -bs
Date: Sat, 30 Oct 1999 17:54:50 +0200 (MEST)
From: Jaroslav Kysela <perex@suse.cz>
To: est@hyperreal.org
cc: Steve Ratcliffe <steve@parabola.demon.co.uk>,
        Linux Audio Development Mailing list <linux-audio-dev@ginette.musique.umontreal.ca>,
        ALSA development <alsa-devel@alsa-project.org>
Subject: Re: [linux-audio-dev] Re: rtcd vs hz > 100!
In-Reply-To: <19991028180846.25208.qmail@hyperreal.org>
Message-ID: <Pine.LNX.4.05.9910301751070.5136-100000@gate.suse.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7dcae60246602390dce38ca34a2a6c4d

On Thu, 28 Oct 1999 est@hyperreal.org wrote:

> Steve Ratcliffe discourseth:
> > 
> > For those using ALSA, you can already do this without a user daemon.
> > The timer interface allows more than one process to access the same timer,
> > there is a user interface via open/read of /dev/snd/timer and a kernel
> > interface so that the sequencer can be driven from a better clock than
> > the 10ms system timer.  I have a demo timer module that uses the RTC as
> > a loadable ALSA timer.
> 
> This sounds better than the rtcd concept.  I'm curious what others
> think..and happy I posted a design before coding. :)

It looks that we need an universal timer interface not only for the sound
applications. What about to move the timer abstract code from the ALSA
driver into separate kernel module?

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA project  http://www.alsa-project.org

From - Sat Oct 30 15:06:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA01191
	for <slinkp@ulster.net>; Sat, 30 Oct 1999 12:48:58 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA14189 for linux-audio-dev-list; Sat, 30 Oct 1999 12:20:19 -0400
Received: from gate.suse.cz (perex.cb.cesnet.cz [194.212.165.105]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA14186 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 30 Oct 1999 12:20:16 -0400
Received: from localhost (perex@localhost)
	by gate.suse.cz (8.8.8/8.8.8) with ESMTP id SAA05297;
	Sat, 30 Oct 1999 18:06:32 +0200
X-Authentication-Warning: gate.suse.cz: perex owned process doing -bs
Date: Sat, 30 Oct 1999 18:06:32 +0200 (MEST)
From: Jaroslav Kysela <perex@suse.cz>
To: Benno Senoner <sbenno@gardena.net>
cc: Billy Biggs <vektor@DIV8.NET>, Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca,
        linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: Sync Issues (was Re: External MIDI Sync using OSS/Free)
In-Reply-To: <99102901582200.00774@linuxhost.localdomain>
Message-ID: <Pine.LNX.4.05.9910301804520.5136-100000@gate.suse.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: e94c34b259ec905b42f7bcbbe208a2e0

On Fri, 29 Oct 1999, Benno Senoner wrote:

> > > BTW: which card are you using ?
> > 
> >   For MIDI I'm using a Roland MPU-IPC-T card.  MPU-401.
> 
> Jaroslav do you know if there are similar problems on this card with too little
> MIDI TX/RX FIFO size  , and/or lack of an IRQ connected to it ?

Yes, the problem is in the MPU-401 hardware specification. This hardware
haven't the TX interrupt. Every soundcard with the standard MPU-401
emulation has this problem.

							Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA project  http://www.alsa-project.org


From - Sat Oct 30 15:06:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA30067
	for <slinkp@ulster.net>; Sat, 30 Oct 1999 12:15:16 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA14091 for linux-audio-dev-list; Sat, 30 Oct 1999 11:40:31 -0400
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA14088 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 30 Oct 1999 11:40:25 -0400
Received: from linuxhost.localdomain (IDENT:root@ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id RAA18098;
	Sat, 30 Oct 1999 17:35:53 +0200
Received: from linuxhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id TAA01305;
	Sat, 30 Oct 1999 19:36:20 +0200
From: Benno Senoner <sbenno@gardena.net>
To: sdl@lokigames.com
Subject: [linux-audio-dev] fullscreen video performance vs. running in window  & latency issues 
Date: Sat, 30 Oct 1999 18:55:13 +0200
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>,
        linuxdvd@linuxdvd.corepower.com
MIME-Version: 1.0
Message-Id: <99103019362001.00738@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: c4cb163db340e9c79a168a6a001ead2e

Hi,

( for linux-audio-dev readers: not directly audio related but low-latency
related, and we want our realtime audio apps deliver reliable video too   :-) ) 


I have a few questions about the actual performance you can achieve doing
graphics output using direct access techniques.

In the case of SDL in fullscreen: is the Xserver still involved in the
displaying process ?
That means: cal you achieve true hardware speed by writing directly into
the framebuffer memory (double buffering), and then flip buffers,
or are you forced to write to an intermediate graphics buffer, which is 
updated by the xserver ?

I ask this because Linux is becoming low-latency capabilities 
( patches available, very probably scheduled to go into kernel 2.4) 
thanks to the exeptional work of Ingo Molnar who found the problematic,high
latency causing spots in the kernel.

This feature is wonderful for audio since it allows one to run
realtime audio processing with very low latency ( <3ms on a P133 !)
extremely reliably even when you stress the machine with huge
disk transfers / graphics output etc.

see the whole story, accurate tests with charts, kernel patch
and my latency measurement tool at my page:

http://www.gardena.net/benno/linux/audio
 
Now to my video questions:
typical video latencies are  much higher than audio latencies:
realtime audio <5-10ms 
realtime video <20-50ms

You can only achieve rock solid low latencies, 
by using SCHED_FIFO scheduling in your process and make sure that
the pages are locked in mem by using mlock() / mlockall().

When the system is stressed with disk access, regular processes
(SCHED_OTHER) can experience bad latencies because the disk driver
/ bdflush can steal CPU time to these processes. (especially in the EIDE disk
case).
And one of these processes could be your X server.
The idea or running your X server SCHED_FIFO / SCHED_RR and mlock()ed in mem,
is simply silly, because it could eat up your entire memory and/or freeze your
system (during heavy font rendering etc).

A typical example of high performance video playback + rock solid low-latency
could be DVD playback (by software-only decoder)  without frame dropouts/audio
dropouts when there is something running in background.

Assume that your DVD software player uses 50% of the CPU for the decoding,
then if in fullscreen mode the SDL (or Xv / DGA) allows you to write directly
to the framebuffer, using a low-latency-enabled  kernel would provide wonderful
performance:
the video would not loose any video frames/audio fragments as long your run
SCHED_FIFO+mlock()ed , even if you do heavy disk access and/or CPU work.

What in the case that I watch my DVD movie in a window ?
Is the X server now involved ? = potential frame losses due to other processes
running in background ?
Or is there a way to use an overlay mask on GFX boards  which does support
this ?  
It would be ideal to specify "give me direct access to the rectancle 300x200
startinng at position (150,170) and leave out the X server of the business"
If the user changes the position/size of the video window, just update
the overlay region in the gfx board in order to reflect changes.

Could please the SDL / Xv / DGA experts explain the actual / planned
capabilities in this field.

Of course these features would put Linux much ahead in the realtime video field,
and on the same level playing field as BeOs. ( Linux becoming *the* mediaOS
soon  :-) )


regards,
Benno.

From - Sat Oct 30 15:06:43 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA12447
	for <slinkp@ulster.net>; Sat, 30 Oct 1999 14:52:09 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA14476 for linux-audio-dev-list; Sat, 30 Oct 1999 14:19:09 -0400
Received: from gate.suse.cz (perex.cb.cesnet.cz [194.212.165.105]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA14473 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 30 Oct 1999 14:19:06 -0400
Received: from localhost (perex@localhost)
	by gate.suse.cz (8.8.8/8.8.8) with ESMTP id UAA05775;
	Sat, 30 Oct 1999 20:05:27 +0200
X-Authentication-Warning: gate.suse.cz: perex owned process doing -bs
Date: Sat, 30 Oct 1999 20:05:27 +0200 (MEST)
From: Jaroslav Kysela <perex@suse.cz>
To: Billy Biggs <vektor@DIV8.NET>
cc: Benno Senoner <sbenno@gardena.net>, Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca,
        linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: Sync Issues (was Re: External MIDI Sync using OSS/Free)
In-Reply-To: <Pine.LNX.3.96.991030141012.12637B-100000@vektor.div8.net>
Message-ID: <Pine.LNX.4.05.9910302003060.5585-100000@gate.suse.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: c366785c71ede50597459ea70cf6c338

On Sat, 30 Oct 1999, Billy Biggs wrote:

> On Sat, 30 Oct 1999, Jaroslav Kysela wrote:
> 
> > On Fri, 29 Oct 1999, Benno Senoner wrote:
> > 
> > > >   For MIDI I'm using a Roland MPU-IPC-T card.  MPU-401.
> > > 
> > > Jaroslav do you know if there are similar problems on this card with
> > > too little MIDI TX/RX FIFO size, and/or lack of an IRQ connected to
> > > it ? 
> > 
> > Yes, the problem is in the MPU-401 hardware specification. This hardware
> > haven't the TX interrupt. Every soundcard with the standard MPU-401
> > emulation has this problem.
> 
>   What card would you recommend for responsive MIDI then?  Or, should I
> not care, and just make sure I code to be as low-latency as possible?

Chipsets with full IRQ based RX & TX:

Trident 4DWave DX or NX
Creative Ensoniq AudioPCI (ES1370,ES1371,ES1373)
Gravis UltraSound

							Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA project  http://www.alsa-project.org

From - Sat Oct 30 15:06:42 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA11942
	for <slinkp@ulster.net>; Sat, 30 Oct 1999 14:46:22 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA14469 for linux-audio-dev-list; Sat, 30 Oct 1999 14:15:38 -0400
Received: from hme0.smtp04.sprint.ca (hme0.smtp04.sprint.ca [207.107.250.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA14466 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 30 Oct 1999 14:15:36 -0400
Received: from vektor.div8.net (spc-isp-ktc-uas-8-6.sprint.ca [209.148.133.57])
	by hme0.smtp04.sprint.ca (8.8.8/8.8.8) with ESMTP id OAA00660;
	Sat, 30 Oct 1999 14:10:59 -0400 (EDT)
Received: from localhost by div8.net
	via sendmail with smtp
	id <m11hczC-00091aC@vektor.div8.net> (Debian Smail3.2.0.102)
	for <pbd@Op.Net>; Sat, 30 Oct 1999 14:12:18 -0400 (EDT) 
Date: Sat, 30 Oct 1999 14:12:17 -0400 (EDT)
From: Billy Biggs <vektor@DIV8.NET>
To: Jaroslav Kysela <perex@suse.cz>
cc: Benno Senoner <sbenno@gardena.net>, Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca,
        linux-sound@vger.rutgers.edu
Subject: [linux-audio-dev] Re: Sync Issues (was Re: External MIDI Sync using OSS/Free)
In-Reply-To: <Pine.LNX.4.05.9910301804520.5136-100000@gate.suse.cz>
Message-ID: <Pine.LNX.3.96.991030141012.12637B-100000@vektor.div8.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: dee6d00669873b92a972dac4468f592f

On Sat, 30 Oct 1999, Jaroslav Kysela wrote:

> On Fri, 29 Oct 1999, Benno Senoner wrote:
> 
> > >   For MIDI I'm using a Roland MPU-IPC-T card.  MPU-401.
> > 
> > Jaroslav do you know if there are similar problems on this card with
> > too little MIDI TX/RX FIFO size, and/or lack of an IRQ connected to
> > it ? 
> 
> Yes, the problem is in the MPU-401 hardware specification. This hardware
> haven't the TX interrupt. Every soundcard with the standard MPU-401
> emulation has this problem.

  What card would you recommend for responsive MIDI then?  Or, should I
not care, and just make sure I code to be as low-latency as possible?

--
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

From - Sat Oct 30 15:14:17 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA14012
	for <slinkp@ulster.net>; Sat, 30 Oct 1999 15:08:44 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA14492 for linux-audio-dev-list; Sat, 30 Oct 1999 14:37:54 -0400
Received: from hme0.smtp04.sprint.ca (hme0.smtp04.sprint.ca [207.107.250.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA14489 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 30 Oct 1999 14:37:51 -0400
Received: from vektor.div8.net (spc-isp-ktc-uas-8-6.sprint.ca [209.148.133.57])
	by hme0.smtp04.sprint.ca (8.8.8/8.8.8) with ESMTP id OAA23973;
	Sat, 30 Oct 1999 14:33:35 -0400 (EDT)
Received: from localhost by div8.net
	via sendmail with smtp
	id <m11hdL4-00091aC@vektor.div8.net> (Debian Smail3.2.0.102)
	for <alsa-devel@alsa-project.org>; Sat, 30 Oct 1999 14:34:54 -0400 (EDT) 
Date: Sat, 30 Oct 1999 14:34:54 -0400 (EDT)
From: Billy Biggs <vektor@DIV8.NET>
To: Jaroslav Kysela <perex@suse.cz>
cc: Linux Audio Dev <linux-audio-dev@ginette.musique.umontreal.ca>,
        ALSA development <alsa-devel@alsa-project.org>
Subject: Re: [linux-audio-dev] Re: rtcd vs hz > 100!
In-Reply-To: <Pine.LNX.4.05.9910301751070.5136-100000@gate.suse.cz>
Message-ID: <Pine.LNX.3.96.991030143327.27286A-100000@vektor.div8.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ee257de9927d83c0a0d7e79aeb9c8bd0

On Sat, 30 Oct 1999, Jaroslav Kysela wrote:

> It looks that we need an universal timer interface not only for the sound
> applications. What about to move the timer abstract code from the ALSA
> driver into separate kernel module?

  You'd make alot of people very happy.

--
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

From - Sat Oct 30 17:51:02 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA17551
	for <slinkp@ulster.net>; Sat, 30 Oct 1999 15:48:06 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA14552 for linux-audio-dev-list; Sat, 30 Oct 1999 15:18:34 -0400
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA14549 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 30 Oct 1999 15:18:31 -0400
Received: from ulster.net (port220.ts2.ulster.net [208.242.164.220])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id PAA14975;
	Sat, 30 Oct 1999 15:18:59 -0400
Message-ID: <381B45A5.C124FE7F@ulster.net>
Date: Sat, 30 Oct 1999 15:23:17 -0400
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Barton-Davis <pbd@Op.Net>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Linux audio questions...
References: <199910301243.IAA18224@renoir.op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5b5766c5f0e9d1892aa6a10b9815bf8b

Paul Barton-Davis wrote:
> Paul - the attributions here are wrong. It was me who commented that
> only using Csound was fairly restrictive, and it wasn't so much a
> comment on Csound, but on not the idea of not using any outboard
> h/w. I'll let anyone else how much *i* have actually used Csound :)

Whoops, I knew who said what, but I think I mangled my message so it
wasn't clear. Sorry.
 
> >Now imagine trying to write a csound instrument with conditional
> >tests nested inside other conditional tests. I haven't been brave
> >enough to try that yet.
> 
> if <condition1> goto second_test
>    ... stuff to do when condition1 is false ...
>    goto end_tests
> 
> second_test:
>    if <condition2> goto all_true
>       ... stuff to do when condition1 is true and condition2 is false ...
>       goto end_tests
> 
> all_true:
>       ... stuff to do when condition1 is true and condition2 is true ...
> 
> end_tests:
>       ... proceed ...
> 
> there, what could possibly be wrong with that ? :))))

I can't find anything wrong with it, except that I can barely follow
the logic well enough to know if it's right! :)
 I really, really wish csound supported something more like  if /
elif / else, with block delimiters of some sort, so you could make
structures like this more readable. Do you have any plans to put
something like that in Quasimodo?

best,

PW
-- 

----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.
email=========================slinkp AT ulster DOT net
ARMS online=======================http://reacharms.com    
personal page===========http://www.ulster.net/~abigoo/

From - Sat Oct 30 17:51:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA30998
	for <slinkp@ulster.net>; Sat, 30 Oct 1999 17:28:39 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA14641 for linux-audio-dev-list; Sat, 30 Oct 1999 16:56:40 -0400
Received: from gauss.deltav.hu (gauss.deltav.hu [194.9.64.225]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA14638 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 30 Oct 1999 16:56:36 -0400
Received: from boksi (106.dial02.deltav.hu [194.9.64.106])
          by gauss.deltav.hu (Netscape Messaging Server 3.6)  with ESMTP
          id AAA1502 for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Sat, 30 Oct 1999 22:56:11 +0200
Received: from reactor by boksi with local (Exim 1.92 #1 (Debian))
	id 11hfb0-000060-00; Sat, 30 Oct 1999 22:59:30 +0200
Message-ID: <19991030225930.B360@boksi>
Date: Sat, 30 Oct 1999 22:59:30 +0200
From: reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] limiting
Reply-To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91.2
Organization: CTP media laboratories
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 8a33b0c28b1c4702853fa3d03e2e6fb7

yo!

is there any way in csound to clip the samples between 2 values?

i mean like sample values shouldn't be bigger than 32767 and smaller
than -32768. how can i do this easily? the "limit" opcode just doesn't
work. it limits the values, but makes the sound noisy even if NO CLIPPING
should be done!

bye!

-- 

(Racz Mate       ) (JATE hallgato, elsoeves programtervezo-matematikus)
(reactor/CTPmedia) (http://linux.gyakg.u-szeged.hu/~reactor/index.html)
(linux audiowarez) (http://www.bright.net/~dlphilp/linuxsound/toc.html)

From - Sat Oct 30 18:00:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA01538
	for <slinkp@ulster.net>; Sat, 30 Oct 1999 17:47:40 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA14678 for linux-audio-dev-list; Sat, 30 Oct 1999 17:13:30 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id RAA14675 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 30 Oct 1999 17:13:28 -0400
From: est@hyperreal.org
Received: (qmail 25495 invoked by uid 162); 30 Oct 1999 21:09:15 -0000
Message-ID: <19991030210915.25494.qmail@hyperreal.org>
Subject: [linux-audio-dev] audio-friendly boxes
In-Reply-To: <381B0128.9A4BBB09@mindless.com> from jiva at "Oct 30, 1999 07:31:04
 am"
To: jiva <jiva@mindless.com>
Date: Sat, 30 Oct 1999 14:09:15 -0700 (PDT)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 759e067913570c7645e1af5ba94c26e6

jiva discourseth:
> 
> ok, the sequencer is keykit and it will be running on an amd k6-200 with
> 40MB of ram, so I don't think clock speed is going to be an issue...
> what will be an issue is what network card, video card and IDE HD to
> use. I'd like to use SCSI, but I don't want to spend too much on a box
> just for sequencing. At this point, these questions are probably best
> addressed to another list, you know, [linux-box-newbie].
[...]
> Still, I would think
> with the box, the OS and that I'm going to go for... oh, btw - best
> cheap MIDI soundcard? - video card, tuned drive (I still don't know what
> this means)... it should be ample.

Low-latency adds some extra requirements.  You definitely want an
IDE-chipset with supported DMA (and an EIDE drive that does DMA) or
SCSI (I got a new TekRam DC390F card this year for $90).  As for video
cards, I've had good luck with an ATI RageII+DVD.  Among soundcards,
the Creative PCI128 is popular and pbd love's the Hoontech
card..probably best to get both. (they're cheap :)

Eric

From - Sat Oct 30 18:04:10 1999
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA02364
	for <slinkp@ulster.net>; Sat, 30 Oct 1999 17:56:53 -0400
From: est@hyperreal.org
Received: (qmail 14821 invoked by uid 162); 30 Oct 1999 21:52:02 -0000
Message-ID: <19991030215202.14820.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] Linux audio questions...
In-Reply-To: <381B68AD.DF153309@ulster.net> from Paul Winkler at "Oct 30, 1999
 05:52:45 pm"
To: Paul Winkler <slinkp@ulster.net>
Date: Sat, 30 Oct 1999 14:52:02 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 68b39500d72ecef7ea50c67ccb3bc1f1

Paul Winkler discourseth:
> est@hyperreal.org wrote:
> > 
> > Paul Winkler discourseth:
> > >
> > > I've been working my way through "learning python" and I was
> > > intrigued by your python / midi / csound gadgets. I just spent an
> > > hour playing with bits of your code at the python prompt to figure
> > > out what you're doing. Pretty cool.
> > 
> > Have you checked out the MidiIn module in oolaboola?  You may find it
> > useful.
> 
> I haven't... I assume this is a module for reading from the midi
> port? I'm sure I can find uses for that!

Actually, it doesn't do any reading..just parsing.  You create a
MidiIn object, register callbacks for various midi events, and run the
object on midi bytes.  Given that it doesn't do any i/o of its own,
I'm thinking it may be able to go in the main python distribution.

> > > Attached is a pretty thoroughly commented (otherwise unmodified)
> > > version of s1.py in case you find that useful for anything.
> > 
> > I've posted it..thanks! :)
> 
> No problem; I did it for myself... learned a thing or two (I hadn't
> done anything with "eval" before, and I immediately understood you
> were using it as just a way to toss a dictionary into a text file
> and slurp it in... nice.)

Others may benefit from those comments!

I just ran into a guy doing nice csound/python work on the alternate
tunings list.  I'll post about his stuff soon. :)

E

From - Sat Oct 30 22:25:03 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA07972
	for <slinkp@ulster.net>; Sat, 30 Oct 1999 18:58:02 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA14789 for linux-audio-dev-list; Sat, 30 Oct 1999 18:28:33 -0400
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id SAA14786 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 30 Oct 1999 18:28:30 -0400
From: est@hyperreal.org
Received: (qmail 2113 invoked by uid 162); 30 Oct 1999 22:24:17 -0000
Message-ID: <19991030222417.2112.qmail@hyperreal.org>
Subject: [linux-audio-dev] musical ratio python module
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Sat, 30 Oct 1999 15:24:17 -0700 (PDT)
CC: wsannis@execpc.com
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 56ed7d8418558b819c588a122059fec0

William Annis has posted a neat python module for manipulating musical
ratios at www.execpc.com/~wsannis/ratio.html.

This is of most interest to just intonation fiends such as
myself..people who thrill to

 >>> Ratio(3,2) + Ratio(7,6)
 <7:4>

..and are charmed by methods like

   katapykne_ab(a, b)
          For people who find 1:1 katapyknosis boring, this does a/b
          katapyknosis by the formula in Chalmers' "Divisions of the
          Tetrachord", p 14.

:D

Eric

From - Sat Oct 30 22:25:04 1999
Received: from pop06.iname.net (pop06.iname.net [165.251.8.76])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id SAA08141
	for <slinkp@ulster.net>; Sat, 30 Oct 1999 18:59:59 -0400
Received: from mindless.com ([216.111.166.87])
	by pop06.iname.net (8.9.3/8.9.3) with ESMTP id SAA13086
	for <slinkp@ulster.net>; Sat, 30 Oct 1999 18:55:07 -0400 (EDT)
Message-ID: <381B7729.4D65E603@mindless.com>
Date: Sat, 30 Oct 1999 15:54:33 -0700
From: jiva <jiva@mindless.com>
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: Paul Winkler <slinkp@ulster.net>
Subject: Re: [linux-audio-dev] Linux audio questions...
References: <199910290135.VAA13675@renoir.op.net> <38193984.3F7622D4@mindless.com> <3819D6D7.C32B8E7D@ulster.net> <381A25B4.E3CE0219@mindless.com> <381B670E.461D3611@ulster.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: U
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: a1f00f0f7da8338c7bd3d99514406cdb

> You should be fine, then.
> Oh yeah... the one other annoyance with csound is bugs.
> Sometimes opcodes don't work as advertised, or don't work at all.

that's quite possible; nonetheless it seems like a versitile language,
and well documented. I'm probably going to get the csound book sometime
soon.
 
> well, thanks! I am hoping that Arms will become a self-supporting
> venture at least to the degree of allowing us to be musicians most
> of the time. Actually, I hope it goes farther than that, but that
> would do.

arms is very creative and I'll be sure to check out more material. I
listened to the sound sculpture on your web page today and that was
quite interesting and enjoyable though dissonant, the reverse drops were
fun. I didn't make it to the multitrack project yet, nice to know it
works on Linux though.

have you worked on much multitracking with Linux recently?

Ian

From - Sat Oct 30 22:25:01 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA07845
	for <slinkp@ulster.net>; Sat, 30 Oct 1999 18:56:27 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA14796 for linux-audio-dev-list; Sat, 30 Oct 1999 18:30:03 -0400
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA14792 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 30 Oct 1999 18:30:01 -0400
Received: from someip.ppp.op.net (d-bm3-14.ppp.op.net [209.152.194.84]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id SAA17656 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 30 Oct 1999 18:25:46 -0400 (EDT)
Message-Id: <199910302225.SAA17656@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Linux audio questions... 
In-reply-to: Your message of "Sat, 30 Oct 1999 15:23:17 EDT."
             <381B45A5.C124FE7F@ulster.net> 
Date: Sat, 30 Oct 1999 19:22:19 -0400
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: e99acdf833aff01e7477b1f1a44681d8


  [ ... bizarre Csound logic example elided for sanity's sake ... ]

> I really, really wish csound supported something more like  if /
>elif / else, with block delimiters of some sort, so you could make
>structures like this more readable. Do you have any plans to put
>something like that in Quasimodo?

more than plans. there is already a stealth source code module in the
form of an 80% complete bison grammer for a "C style" audio
programming language that uses the csound opcodes. i definitely have
plans to finish this at some point. 

it will have variables typed by declarations, not "first letter of
name", C-style flow control (including while(){}), named instruments,
named function tables. also all opcodes will be invoked as C-style
function calls, instead of the current nonsensical mixture of
"converters" which look like function calls, and "opcode" calls which
look like assembler. the underlying implementation of both things is
identical in Csound (and in Quasimodo), and so the "user interface"
for programming with them should be consistent.

       aout = soundin (... , cpsmidi (), ...);
       
not
       aout soundin ..., cpsmidi(), ...

i have good reason to believe that it will not be particularly hard to
make this fully functional.

--p

       


From - Sat Oct 30 22:25:07 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA19570
	for <slinkp@ulster.net>; Sat, 30 Oct 1999 20:56:28 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA14934 for linux-audio-dev-list; Sat, 30 Oct 1999 20:26:29 -0400
Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA14931 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 30 Oct 1999 20:26:25 -0400
Received: from d1o43.telia.com (d1o43.telia.com [194.22.195.241])
	by mailg.telia.com (8.9.3/8.9.3) with ESMTP id CAA23352
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 31 Oct 1999 02:22:11 +0200 (CEST)
Received: from skelleftea.mail.telia.com (t8o43p1.telia.com [194.237.168.181])
	by d1o43.telia.com (8.8.8/8.8.5) with ESMTP id CAA26035
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 31 Oct 1999 02:22:10 +0200 (CEST)
Message-ID: <381B958E.FFEAE2DE@skelleftea.mail.telia.com>
Date: Sun, 31 Oct 1999 02:04:14 +0100
From: Roger Larsson <roger.larsson@skelleftea.mail.telia.com>
X-Mailer: Mozilla 4.6 [en] (Win95; I)
X-Accept-Language: sv,en
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Re: Sync Issues (was Re: External MIDI Sync using 
 OSS/Free)
References: <381A0093.1A1FAF2F@skelleftea.mail.telia.com> <99103001452400.00737@linuxhost.localdomain>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by mailg.telia.com id CAA23352
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA19570
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 16cbe6b083b54155a2a2f85797ad51b9

Hi,

Benno I guess you mean something like "PCI Latency Timer (PCI Clocks)"
I have it as a BIOS option, mine is set to 32 with a 30 MHz PCI
(180 MHz CPU) it should give 1 us latency.
It can be configured up to 248 that should give about 8 us latency.

If I understand the 440FX documentation correctly no PCI device is
allowed to hold the PCI bus a longer time...

Strange.

/RogerL


Benno Senoner wrote:
> 
> On Fri, 29 Oct 1999, Roger Larsson wrote:
> >>
> > Or you can try to find out what part of your video card driver that
> > destroys latency and correct that.
> >
> > You can find out the problematic spot with my patch:
> >  latency-profiling-2.2.10-r6.patch [for Linux 2.2.10]
> >>
> > The results are messages in 'dmesg', latency time and instruction
> > pointers
> > are printed. You then decode the instruction pointers to routine name.
> >
> > /RogerL
> 
> Not quite correct: actually it's not a driver's fault !
> In most cases the audio dropout while doing heavy GFX is caused by PCI busmaster
> transfers by the gfx card that hogs the entire PCI bus for SEVERAL milliseconds,
> in order to provide better gfx throughput.
> On some cards you can avoid this problem by setting a special variable into
> your XF86Config (no sample handy at the moment) , which slows down the gfx
> performance a bit but gives you better lowlatency performance.
> 
> On some other cards the only solution is to throw your gfx card out of the
> nearest window.
> :-)
> 
> PS: Benjamin, I stopped the crossposting , at least for this mail.
> :-)
> 
> Benno.

-- 

The Internet interprets Windows as damage, 
             and routes around it.

Roger Larsson
Skellefte
Sweden

From - Mon Nov  1 00:30:03 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA23916
	for <slinkp@ulster.net>; Sun, 31 Oct 1999 06:17:31 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA19282 for linux-audio-dev-list; Sun, 31 Oct 1999 05:43:53 -0500
Received: from bologna.nettuno.it (bologna.nettuno.it [193.43.2.1]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA19279 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 31 Oct 1999 05:43:49 -0500
Received: from mar095k1 (ppp24-nas0.marano.nettuno.it [193.207.118.218])
	by bologna.nettuno.it (8.9.3/8.9.3/NETTuno 3.3) with SMTP id LAA23043
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 31 Oct 1999 11:39:31 +0100 (MET)
Message-ID: <007601bf238c$13fffb80$da76cfc1@mar095k1>
From: "Alessandro Fogar" <mar095k1@ud.nettuno.it>
To: "linux-audio-dev" <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] SBlive GPL drivers !
Date: Sun, 31 Oct 1999 11:38:30 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: b7109527d6bfe15ded5c720ab5190674

>From the Creative Linux Newsgroup:

OK, I guess the cat is out of the bag now.  Like the article says,
Creative is opening the sources to the existing SBLive (Emu10K1,
technically) Linux kernel driver.  The current sourcebase is what would
have been release as beta4 of the driver, with 4-speaker support (stereo
mirroring only at present) and SPDIF output being the main changes from
beta3.  Also being released are beta sources for a DXR2 driver which
were donated to Creative by Andrew de Quincey (thanks, Andrew!).  The
source for both projects will be released under the GPL.  We are
planning to submit kernel patches as soon as possible, after the
open-source development community has had a chance to beat on the driver
sources for a bit and whip them into shape.

Also as the article mentioned, Creative is going to launch an
open-source development support site with FAQs, CVS repositiories,
CVSWeb tracking, Bugzilla, mailing lists, and all the other standard
open source project website services.  The site will be up and running
sometime early next week - PLEASE do not overload
developer.soundblaster.com with repeated checks to see if the site is up
yet, OK?  We'll announce loud and clear when the server goes live.

So, that's where things stand as of Friday evening.  All of us here at
Creative are really excited about this, and we have all worked hard to
get to this point.  Huge numbers of people have been asking for the
source since we announced the driver development project early this
year.  Many of those same e-mails were from people who wanted to be able
to hack the driver sources themselves.  Well, here's what you all have
been asking for all year, and what we promised you back in February.  

Happy hacking!

Jon Taylor
Linux Driver Engineer
Creative Labs
jtaylor@creativelabs.com

From - Mon Nov  1 00:30:06 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA03416
	for <slinkp@ulster.net>; Sun, 31 Oct 1999 07:17:03 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA19376 for linux-audio-dev-list; Sun, 31 Oct 1999 06:50:13 -0500
Received: from bologna.nettuno.it (bologna.nettuno.it [193.43.2.1]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA19373 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 31 Oct 1999 06:50:10 -0500
Received: from mar095k1 (ppp29-nas0.marano.nettuno.it [193.207.118.223])
	by bologna.nettuno.it (8.9.3/8.9.3/NETTuno 3.3) with SMTP id MAA19372
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 31 Oct 1999 12:45:53 +0100 (MET)
Message-ID: <000b01bf2395$59165bc0$df76cfc1@mar095k1>
From: "Alessandro Fogar" <mar095k1@ud.nettuno.it>
To: "linux-audio-dev" <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] SBlive GPL drivers - addendum
Date: Sun, 31 Oct 1999 12:44:51 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 20328b6afc2c6b470cc4189fd37b2738

You can find the article referred in my last message at:

http://www.ga-source.com/all/news/bits/09+29+1999/15:09:37.shtml

Bye

Alessandro Fogar

From - Mon Nov  1 01:19:52 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA09752
	for <slinkp@ulster.net>; Mon, 1 Nov 1999 00:14:56 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA20922 for linux-audio-dev-list; Sun, 31 Oct 1999 23:29:37 -0500
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA20919 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 31 Oct 1999 23:29:34 -0500
Received: from ulster.net (port141.ts2.ulster.net [208.242.164.141])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id XAA06402;
	Sun, 31 Oct 1999 23:30:08 -0500
Message-ID: <381D265F.91A3A3D5@ulster.net>
Date: Mon, 01 Nov 1999 00:34:23 -0500
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Barton-Davis <pbd@Op.Net>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Linux audio questions...
References: <199910302225.SAA17656@renoir.op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 89e303832ecc784ca613621b5062c158

Paul Barton-Davis wrote:
> 
>   [ ... bizarre Csound logic example elided for sanity's sake ... ]
(snip)
> 
>        aout = soundin (... , cpsmidi (), ...);
> 
> not
>        aout soundin ..., cpsmidi(), ...
> 
> i have good reason to believe that it will not be particularly hard to
> make this fully functional.

If you ever do, I will gladly kiss csound goodbye.

thanks,

PW
-- 

----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.
email=========================slinkp AT ulster DOT net
ARMS online=======================http://reacharms.com    
personal page===========http://www.ulster.net/~abigoo/

From - Tue Nov  2 11:25:03 1999
Received: from pop04.iname.net (pop04.iname.net [165.251.8.69])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id XAA15829
	for <slinkp@ulster.net>; Mon, 1 Nov 1999 23:05:35 -0500
Received: from mindless.com ([216.111.166.87])
	by pop04.iname.net (8.9.3/8.9.3) with ESMTP id XAA23376
	for <slinkp@ulster.net>; Mon, 1 Nov 1999 23:00:23 -0500 (EST)
Message-ID: <381E61B1.7DB2317C@mindless.com>
Date: Mon, 01 Nov 1999 19:59:45 -0800
From: jiva <jiva@mindless.com>
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: Paul Winkler <slinkp@ulster.net>
Subject: Re: [linux-audio-dev] Linux audio questions...
References: <199910290135.VAA13675@renoir.op.net> <38193984.3F7622D4@mindless.com> <3819D6D7.C32B8E7D@ulster.net> <381A25B4.E3CE0219@mindless.com> <381B670E.461D3611@ulster.net> <381B7729.4D65E603@mindless.com> <381BA969.9C78BCE0@ulster.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ec3f0792e3349b90ade647bc2cdbf874

> Thanks much for the kind words. I downloaded one of your MP3s but I
> haven't checked it out yet-- I have to run out the door to a
> halloween party now. I'll get back to you.

hope you enjoyed them...

> Nope, I haven't made much progress with any computer music recently.
> I'm kind of annoyed with Multitrack. It's usable but has some
> annoying bugs which never get fixed, and the code is not available.
> I'm looking forward to paul barton-davis's upcoming "hdr" prog,
> which should be simpler and eventually more robust due to GPL.

yes, I'm enthused about it as well... I was curious about the other
applications available, though. Sounds like hdr is going be a welcome
application to those interested in Linux and recording.
 

Ian

From - Wed Nov  3 13:22:55 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id EAA25769
	for <slinkp@ulster.net>; Wed, 3 Nov 1999 04:17:21 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id DAA05419 for linux-audio-dev-list; Wed, 3 Nov 1999 03:41:40 -0500
Received: from mbox.wins.uva.nl (mbox.wins.uva.nl [146.50.16.22]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA05416 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 3 Nov 1999 03:41:38 -0500
Received: from celeste.wins.uva.nl
          by mbox.wins.uva.nl with ESMTP (sendmail 8.8.7/config 8.9).
          id JAA09877; Wed, 3 Nov 1999 09:37:08 +0100 (MET)
Received: from celeste.wins.uva.nl
          by celeste.wins.uva.nl with ESMTP (sendmail 8.8.7/config 8.8).
          id JAA17142; Wed, 3 Nov 1999 09:37:06 +0100 (MET)
Message-Id: <199911030837.JAA17142@celeste.wins.uva.nl>
X-Organisation: Faculty of Mathematics, Computer Science, Physics & Astronomy
                University of Amsterdam
                The Netherlands
X-Address:      See http://www.wins.uva.nl/location
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] List traffic
Date: Wed, 03 Nov 1999 09:37:06 +0100
From: Ruben van Royen <rvroyen@wins.uva.nl>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: e49045740d114a05b83975a430ed1d32

Hi, 

I haven't received a single email from the list in the past two days.
Is something wrong? 

Besides, I would like to know if their is new information on the 
release of the gpl-ed version of the sblive driver.

Also, does anybody know if the Hoontech soundtrack digital will be
supported and, if so, how soon.

Greatings, 

Ruben

From - Thu Nov  4 00:01:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA07376
	for <slinkp@ulster.net>; Wed, 3 Nov 1999 14:45:00 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA06759 for linux-audio-dev-list; Wed, 3 Nov 1999 14:04:29 -0500
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA06756 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 3 Nov 1999 14:04:22 -0500
Received: by epy.co.at
	via sendmail from stdin
	id <m11j6BV-000e2DC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Wed, 3 Nov 1999 20:35:05 +0100 (CET) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Wed,  3 Nov 1999 20:35:05 +0100 (CET)
To: Ruben van Royen <rvroyen@wins.uva.nl>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] List traffic
In-Reply-To: <199911030837.JAA17142@celeste.wins.uva.nl>
References: <199911030837.JAA17142@celeste.wins.uva.nl>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14368.36008.757881.765535@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id OAA07376
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 9cc52a58c83046263c3b1509e54f38c8

Ruben van Royen writes:
 > Hi, 
 > 
 > I haven't received a single email from the list in the past two days.
 > Is something wrong? 
 > 

 winter draws near, ......

 > Besides, I would like to know if their is new information on the 
 > release of the gpl-ed version of the sblive driver.
 > 
 > Also, does anybody know if the Hoontech soundtrack digital will be
 > supported and, if so, how soon.
 > 

Hm, cant supply any information about that but .....
Just received my RME Hammerfall today :)

I had to change Winfrieds driver a little bit to make it work
on the Alpha .. but now, everythings running fine :) 

Well, OK, SPDIF out is running, I cant test multichannel, because
I havent got my ADAT converters yet.

I have contacted Winfried about when he is planning to release his
driver code,
meanwhile I have to decide if I should adapt Winfrieds driver
to fit into ALSA or OSS/Free ...

Guenter

From - Thu Nov  4 00:01:34 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA12090
	for <slinkp@ulster.net>; Wed, 3 Nov 1999 15:13:55 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA06840 for linux-audio-dev-list; Wed, 3 Nov 1999 14:41:20 -0500
Received: from vcn.bc.ca ([207.102.64.2]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA06837 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 3 Nov 1999 14:41:16 -0500
Received: from localhost (ivar@localhost)
	by vcn.bc.ca (8.9.2/8.9.2) with ESMTP id LAA25226
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 3 Nov 1999 11:35:56 -0800 (PST)
Date: Wed, 3 Nov 1999 11:35:56 -0800 (PST)
From: Ivar Vasara <ivar@vcn.bc.ca>
To: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] SBLive driver status - recap of events.. 
In-Reply-To: <007601bf238c$13fffb80$da76cfc1@mar095k1>
Message-ID: <Pine.GSO.4.10.9911031105090.14084-100000@vcn.bc.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 9c3296798f0ac805c70174d38213b24d



When Creative open sourced their SBLive drivers there was quite a cheer
from the user community, but developers were skeptical, especially since
the info at the Creative website at the time was misleading in a negative
sense. In particular, it was unclear whether the dsp interface would be
open sourced and what Creative meant when they mentioned a seperate binary
driver as well. (If the dsp wasn't opened, the SBLive would be 'just another
sound card' and not justify it's premium price) 

Below is a transcript of a recent exchange on the Alsa-devel mailing list,
and it should help clear things up...

(also, it was made clear that the creative binary driver was basically the
open source driver precompiled for people afraid of gcc. 
ie: not involving proprietary code)

---------------------------

From:"Jacob Hawley" <jhawley@creaf.com>
1999-11-03 13:47:12 

Thanks. I needed my feathers un ruffled.

So far I have delivered on everything I promised to in my "Stated Plan"
posted to SlashDot in February. For those that don't want to find the mail
here is a short recap:

- Release a binary (Done)
- Work on a Source / Binary version (Done)
- Work on an Open Source version (Done)
- Work on a software development kit with docs, sample source, etc. (we
  are working on it).

I need to reiterate also that we have an army of programmers on the 
Windows stuff. While there are only 3 of us working on the Linux stuff --
and this is only part time because we have to deliver products as well.
Part of the reason I have pushed so hard internally for open source is so
that I would be able to have more people helping to improve the driver.

Well now that the driver is open source, that is happening. In 1 day we
received 9 patches to the driver (Jon is integrating them now and
committing them to CVS). This is exactly what I expected, and I am happy
that people took the time to improve the code.

Obviously, the community wants to program the DSP. Well that isn't
trivial, and in fact it can be destructive to things such as speakers. We
are trying to think about the best way to teach people about the DSP.
Right now there is in the source basic configuration of the DSP, source
routing information, and DSP setup information. I am actually looking
right now for some public domain effects (Reverb, Chorus, Flange) that I
could port to our DSP as examples. But not surpisingly there isn't a lot
out there.

Also keep in mind it took our experts almost a year to get the effects
written for a DSP that they fully understood. It is non-trivial to program
this thing and to take full advantage of its power.

Jon Taylor will be heading up further development on this driver and our
expectation is that folks from the Linux community will provide feedback
and improvements. If people still want to criticize the way were doing it,
I guess I just don't have time for them -- I would rather focus on the
people providing positive input and suggestions so that we can improve
things.

Best Regards,
Jake

-----Original Message-----
From: Jaroslav Kysela <perex@suse.cz>
To: Jacob Hawley <jhawley@creaf.com>
Cc: ALSA development <alsa-devel@alsa-project.org>; Bernd Kaindl
<bk@suse.de>
Date: Wednesday, November 03, 1999 12:51 AM

>Jake, I - as the only one official speaker for the ALSA team - doesn't
>agree with some people on the ALSA development mailing list. I'm
>personally very glad, that I can do the SB Live driver for ALSA which
>would be comparable with your current sources/binaries available for
>Linux. I also undestands the positions of others on this mailing list,
>that Creative might prevent to release full information which we need
>to create a driver which fully exploits the EMU10k chip. We'll simply
>stay on the half of the path in this case and there is more cheap
>hardware with same functionality on the current market.
>
>To all people on this list:
>
>My feeling is this: I want to create the basic driver which will contain
>all features available in the current driver from Creative. After this
>step, we could begin a discussion, if we can get from SB Live hardware
>more than the current driver from Creative does. I think that all
problems
>are caused, that Creative released only source code. If we have had some
>programming datasheet (like for Trident chipsets), this situation
>would be probably never occured, because nobody has some chance to
>complain.
>
>Jake, I'm looking for our next co-operation and I hope that your
>sentences in your e-mail will fly away.
>
> Best regards,
> Jaroslav
>
>-----
>Jaroslav Kysela <perex@suse.cz>
>SuSE Linux http://www.suse.com
>ALSA project http://www.alsa-project.org
------
-----------------------------snip----------------------------------


relevant links----

Creative:
http://developer.soundblaster.com/linux/
http://opensource.creative.com/

Alsa-devel mailing list archives:
http://hyppo.screwdriver.net/list.phtml?archive=alsa-devel


Hope this helps,
	Ivar
                            





From - Thu Nov  4 00:01:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA25862
	for <slinkp@ulster.net>; Wed, 3 Nov 1999 16:28:55 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA07022 for linux-audio-dev-list; Wed, 3 Nov 1999 15:56:51 -0500
Received: from bashir.belgium.eu.net (bashir.Belgium.EU.net [193.74.208.147]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA07019 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 3 Nov 1999 15:56:45 -0500
Received: from (adial123.liege.eunet.be [195.207.174.123])
	by bashir.belgium.eu.net  with SMTP id VAA12351 
	for <linux-audio-dev@ginette.musique.umontreal.ca>;
	Wed, 3 Nov 1999 21:51:42 +0100 (MET)
Subject: Re: [linux-audio-dev]HAMMERFALL (was :  List traffic)
From: Benjamin GOLINVAUX <golinvaux@benjamin.net>
Reply-To: Benjamin GOLINVAUX <golinvaux@benjamin.net>
In-Reply-To: <14368.36008.757881.765535@gige>
Message-ID: <0003586efe1c1e93_mailit@relay.eunet.be>
References: <199911030837.JAA17142@celeste.wins.uva.nl> <14368.36008.757881.765535@gige>
Date: Wed, 03 Nov 1999 20:51:03 +0100
X-Mailer: BeatWare Mail-It 2.0.3
X-BeOS-Platform: Intel or clone
X-Priority: 3 (Normal)
To: linux-audio-dev@ginette.musique.umontreal.ca
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: bdf63923316d5199f8ef4c7dbc8fbfa4

>I have contacted Winfried about when he is planning to release his
>driver code,
>meanwhile I have to decide if I should adapt Winfrieds driver
>to fit into ALSA or OSS/Free ...

mrmxxx ! 

Wouldn't it make sense to support alsa, because of the oss 
emulation layer ?

But I understand the alsa driver model is perhaps more difficult...

Do Winfried and you plan to release the source code of this driver ?


Benjamin-




From - Thu Nov  4 00:01:36 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA20483
	for <slinkp@ulster.net>; Wed, 3 Nov 1999 16:04:09 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA06956 for linux-audio-dev-list; Wed, 3 Nov 1999 15:29:11 -0500
Received: from vcn.bc.ca (vcn.bc.ca [207.102.64.2]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA06953 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 3 Nov 1999 15:29:07 -0500
Received: from localhost (ivar@localhost)
	by vcn.bc.ca (8.9.2/8.9.2) with ESMTP id MAA11004
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 3 Nov 1999 12:24:23 -0800 (PST)
Date: Wed, 3 Nov 1999 12:24:23 -0800 (PST)
From: Ivar Vasara <ivar@vcn.bc.ca>
To: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] SBLive driver status -correction.. 
In-Reply-To: <Pine.GSO.4.10.9911031105090.14084-100000@vcn.bc.ca>
Message-ID: <Pine.GSO.4.10.9911031214380.14084-100000@vcn.bc.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: c3e778082045a26e0ad689365b82578a

On Wed, 3 Nov 1999, Ivar Vasara wrote:
> (also, it was made clear that the creative binary driver was basically the
> open source driver precompiled for people afraid of gcc. 
> ie: not involving proprietary code)

I'm sorry. There appears to be a completely seperate binary driver, not
related to the open source one.. read on for details...

------------------------------------------------------------
"Garin Hiebert" <ghiebert@creaf.com>
1999-11-03 14:30:40 
<quote snipped>

Please note that the proprietary driver Creative is developing is an
entirely different code base. It was not forked from the Open Source code
at any point. Creative has been working for quite a while now to develop a
large binary module to be used on many platforms, and this is the code
that will become the "proprietary" code base for Linux and other operating
systems.

This may still cause concern as it doesn't look efficient, but trust me
when I say that corporate efficiency is not at all similar to Open Source
efficiency -- the company knows how to develop proprietary code extremely
well and for us to abandon that model would be a very bad idea. Do
remember that Creative supports some operating systems where the customers
wouldn't know how to (or have the tools to) compile their own drivers. ;-)
Historically, we've done a pretty good job supporting those customers. Now
we're trying to serve the Open Source community as well, which I think is
a Good Thing.

Summing up -- take the Open Source code base and be happy with it. Those
of us at Creative who work with Linux are very excited to have been able
to distribute this code, and some of us will be working on it.

>2. Users will be confused, because there is word of an open source
>driver, but it does
> not support all features, and there is another driver, which seems to
>be "free" (you
> can download for gratis) which supports them. The user should
>understand that the latter
> is not free software...


I think things will be clear enough -- much like the decision to use OSS
versus OSS-Lite versus ALSA drivers today.

Garin Hiebert
Software Engineer
Creative Labs Inc.
--------------------------------------------------------------

Sorry about the confusion, I thought I knew what I was talking about.. :(

Regards,
	Ivar

From - Thu Nov  4 00:01:43 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA10395
	for <slinkp@ulster.net>; Wed, 3 Nov 1999 21:41:12 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA07525 for linux-audio-dev-list; Wed, 3 Nov 1999 21:10:53 -0500
Received: from elysium.uwa.edu.au (elysium.uwa.edu.au [130.95.128.2]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA07522 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 3 Nov 1999 21:10:48 -0500
Received: from tartarus.uwa.edu.au (jedi@tartarus.uwa.edu.au [130.95.128.3]) by elysium.uwa.edu.au (8.8.7/8.8.0) with ESMTP id KAA32499 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 4 Nov 1999 10:06:08 +0800 (WST)
Received: (from jedi@localhost) by tartarus.uwa.edu.au (8.8.8/8.8.0) id KAA00286 for linux-audio-dev@ginette.musique.umontreal.ca; Thu, 4 Nov 1999 10:06:07 +0800
From: Scott McNab <jedi@tartarus.uwa.edu.au>
Message-Id: <199911040206.KAA00286@tartarus.uwa.edu.au>
Subject: Re: [linux-audio-dev]HAMMERFALL (was :  List traffic)
In-Reply-To: <0003586efe1c1e93_mailit@relay.eunet.be> from Benjamin GOLINVAUX at "Nov 3, 1999  8:51: 3 pm"
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Thu, 4 Nov 1999 10:06:06 +0800 (WST)
X-Mailer: ELM [version 2.4ME+ PL48 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 51d8fc8278f5aaaec38d75cd36d96e75

> >I have contacted Winfried about when he is planning to release his
> >driver code,
> >meanwhile I have to decide if I should adapt Winfrieds driver
> >to fit into ALSA or OSS/Free ...
> 
> Wouldn't it make sense to support alsa, because of the oss 
> emulation layer ?

I second the notion. Write an ALSA driver...you get multi-open and
advanced mixer capabilities trivially and OSS compatibility for free.

> But I understand the alsa driver model is perhaps more difficult...

Writing ALSA drivers is much simpler than OSS driver. Because of the
modular nature of the code most of the work is done for you. Just need
to implement a handful of lowlevel functions.

The only 'difficult' bit is that there isn't really any solid 
documentation on writing drivers yet. That being said, there is a lot
of example code in other drivers you can copy from to get you off the 
ground and the alsa-devel mailing list is usually pretty responsive 
to any questions you may have.

------------------------------------------------------------------------
Scott McNab                                       Phone: +61 8 9386 0540
http://ciips.ee.uwa.edu.au/~mcnab-sd/             mcnab-sd@ee.uwa.edu.au

From - Sat Nov  6 01:00:10 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA05997
	for <slinkp@ulster.net>; Thu, 4 Nov 1999 09:14:41 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA12733 for linux-audio-dev-list; Thu, 4 Nov 1999 08:38:09 -0500
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA12730 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 4 Nov 1999 08:38:04 -0500
Received: by epy.co.at
	via sendmail from stdin
	id <m11jNZZ-000dxvC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Thu, 4 Nov 1999 15:09:05 +0100 (CET) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Thu,  4 Nov 1999 15:09:04 +0100 (CET)
To: Benjamin GOLINVAUX <golinvaux@benjamin.net>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev]HAMMERFALL (was :  List traffic)
In-Reply-To: <0003586efe1c1e93_mailit@relay.eunet.be>
References: <199911030837.JAA17142@celeste.wins.uva.nl>
	<14368.36008.757881.765535@gige>
	<0003586efe1c1e93_mailit@relay.eunet.be>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14369.37100.551153.712552@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id JAA05997
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3ebbcd3004348313d635f63b45d383e2

Benjamin GOLINVAUX writes:
 > >I have contacted Winfried about when he is planning to release his
 > >driver code,
 > >meanwhile I have to decide if I should adapt Winfrieds driver
 > >to fit into ALSA or OSS/Free ...
 > 
 > mrmxxx ! 
 > 
 > Wouldn't it make sense to support alsa, because of the oss 
 > emulation layer ?
 > 
 > But I understand the alsa driver model is perhaps more difficult...

 Implementing OSS will be faster, as the current driver is OSSish.

 Anyhow, its a PCM only card (basically no mixing, only switches).
 As an OSS driver it could go faster into the kernel.

 The goal is to be able to release it ASAP, writing
 an ALSA driver from the OSS code should be trivial for someone
 experienced in the field.

 > 
 > Do Winfried and you plan to release the source code of this driver ?
 > 

 Last I have talked to Wini, he said he is planning to clean it up
 and put it in shape for ALSA and then release it.
 
 Im still waiting for an answer how far he got with that, so probably
 I can speed up the release by helping him.

 Guenter


From - Sat Nov  6 01:00:14 1999
Received: from toad.ilogic.com.au (IDENT:postfix@intern12.lnk.telstra.net [139.130.53.38])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id KAA13592
	for <slinkp@ulster.net>; Thu, 4 Nov 1999 10:02:17 -0500
Received: by toad.ilogic.com.au (Postfix)
	id 5B23E25279; Fri,  5 Nov 1999 01:56:29 +1100 (EST)
Delivered-To: csound-unix-dev-list@toad.ilogic.com.au
Received: by toad.ilogic.com.au (Postfix, from userid 91)
	id 32AEA2528A; Fri,  5 Nov 1999 01:56:29 +1100 (EST)
Delivered-To: csound-unix-dev@ilogic.com.au
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5])
	by toad.ilogic.com.au (Postfix) with ESMTP id DA30F25279
	for <csound-unix-dev@ilogic.com.au>; Fri,  5 Nov 1999 01:56:24 +1100 (EST)
Received: from bright.net (find-cas1-cs-44.dial.bright.net [209.143.26.147])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id JAA09841;
	Thu, 4 Nov 1999 09:55:45 -0500 (EST)
Message-ID: <3821A3C5.30AB5B95@bright.net>
Date: Thu, 04 Nov 1999 10:18:29 -0500
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: ALSA Mail <alsa-user@alsa-project.org>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>,
        Csound Linux Development Mail <csound-unix-dev@ilogic.com.au>
Subject: [CUD] new pages
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-unix-dev@ilogic.com.au
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 7b995d1108694297b2e3e6a3eb3a6fd1

Greetings:

  A new edition of the Linux Sound & Music Applications site has been
placed on-line with a lot of news and a lot of new software listings.
The frames version is up and available now, the 1-page format will
follow yet this week. Also, please note that I have a new mirror in
Europe at:

	http://www.linuxsound.at

(Thanks to Guenter and Georg !)

  Enjoy !

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
       http://www.bright.net/~dlphilp/linuxsound/

From - Sat Nov  6 01:00:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA27557
	for <slinkp@ulster.net>; Thu, 4 Nov 1999 18:19:40 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA13665 for linux-audio-dev-list; Thu, 4 Nov 1999 17:55:18 -0500
Received: from gauss.deltav.hu (gauss.deltav.hu [194.9.64.225]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA13662 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 4 Nov 1999 17:55:15 -0500
Received: from boksi (117.dial02.deltav.hu [194.9.64.117])
          by gauss.deltav.hu (Netscape Messaging Server 3.6)  with ESMTP
          id AAA8FE for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Thu, 4 Nov 1999 23:54:26 +0100
Received: from reactor by boksi with local (Exim 1.92 #1 (Debian))
	id 11jVpC-00004x-00; Thu, 4 Nov 1999 23:57:46 +0100
Message-ID: <19991104235746.C281@boksi>
Date: Thu, 4 Nov 1999 23:57:46 +0100
From: reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] OSALP
Reply-To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91.2
Organization: CTP media laboratories
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: d16795bf7458ba785f9ff0ef25eb3314

i found something interesting in the http://freshmeat.net
newsletter again: Open Source Audio Library Project

http://members.tripod.com/bforsberg/audio.html


is this dude here on the list?

-- 

(Racz Mate       ) (                                                  )
(reactor/CTPmedia) (http://linux.gyakg.u-szeged.hu/~reactor/index.html)
(linux audiowarez) (http://www.bright.net/~dlphilp/linuxsound/toc.html)

From - Sat Nov  6 01:00:49 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA01134
	for <slinkp@ulster.net>; Thu, 4 Nov 1999 18:54:41 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA13741 for linux-audio-dev-list; Thu, 4 Nov 1999 18:29:29 -0500
Received: from gauss.deltav.hu (gauss.deltav.hu [194.9.64.225]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA13738 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 4 Nov 1999 18:29:26 -0500
Received: from boksi (117.dial02.deltav.hu [194.9.64.117])
          by gauss.deltav.hu (Netscape Messaging Server 3.6)  with ESMTP
          id AAA1AAF for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Fri, 5 Nov 1999 00:28:40 +0100
Received: from reactor by boksi with local (Exim 1.92 #1 (Debian))
	id 11jWMK-00009R-00; Fri, 5 Nov 1999 00:32:00 +0100
Message-ID: <19991105003200.A570@boksi>
Date: Fri, 5 Nov 1999 00:32:00 +0100
From: reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] csound again
Reply-To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91.2
Organization: CTP media laboratories
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 43dd2df75398a06c2b223f009cee5c2d

yo!

sorry if i send this for the second time, but as i remember,
it hasn't arrived to the list...

so, how can i "clip" in csound? the "limit" opcode is makes the sound
noisy even if no clipping should be involved... :(


bye!

-- 

(Racz Mate       ) (                                                  )
(reactor/CTPmedia) (http://linux.gyakg.u-szeged.hu/~reactor/index.html)
(linux audiowarez) (http://www.bright.net/~dlphilp/linuxsound/toc.html)

From - Sat Nov  6 01:01:10 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA12485
	for <slinkp@ulster.net>; Fri, 5 Nov 1999 15:32:50 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA20682 for linux-audio-dev-list; Fri, 5 Nov 1999 14:54:37 -0500
Received: from pop06.iname.net (pop06.iname.net [165.251.8.76]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA20679 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 5 Nov 1999 14:54:03 -0500
Received: from mindless.com ([216.111.166.87])
	by pop06.iname.net (8.9.3/8.9.3) with ESMTP id OAA15997
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 5 Nov 1999 14:49:17 -0500 (EST)
Message-ID: <38233498.646C69A8@mindless.com>
Date: Fri, 05 Nov 1999 11:48:40 -0800
From: jiva <jiva@mindless.com>
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Linux audio questions...
References: <199910302225.SAA17656@renoir.op.net> <381D265F.91A3A3D5@ulster.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f65f3dacc37eefa51432a005c801d384

I've been looking around for MIDI file creation utilities as an
alternative to KeyKit as it is not entirely entirely open source. One of
the more interesting options looks to be the tclmidi toolkit, though I'm
a bit concerned because it seems primarily developed for freebsd and due
to my lack of linux experience I know only the very basics about the
differences between freebsd and linux. Does this toolkit work within
linux?

thanks,

Ian

From - Sat Nov  6 01:01:15 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA03279
	for <slinkp@ulster.net>; Fri, 5 Nov 1999 18:09:41 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA20959 for linux-audio-dev-list; Fri, 5 Nov 1999 17:42:05 -0500
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA20956 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 5 Nov 1999 17:41:54 -0500
Received: from op.net (d-bm3-15.ppp.op.net [209.152.194.85]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id RAA16444 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 5 Nov 1999 17:37:14 -0500 (EST)
Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id RAA09105; Fri, 5 Nov 1999 17:38:18 -0500
Date: Fri, 5 Nov 1999 17:38:18 -0500
Message-Id: <199911052238.RAA09105@op.net>
From: Paul Barton-Davis <pbd@Op.Net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] card recommendation ?
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: de2dd87f43fa4444ba4e642ee67ade56

a friend writes:

>Do you have a recommendation for a PCI sound card that is:
>   a) Cheap (<$40).
>   b) Guaranteed to be supported by "standard" (i.e., non-ALSA,
>      non-OSS) Linux 2.2.X.
>I was trying to get Ensoniq AudioPCI (es1371) cards but the supply
>seems to be drying up.          

as a devotee of ALSA, i can't answer him. can you ?

--p

From - Sat Nov  6 01:01:17 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA05123
	for <slinkp@ulster.net>; Fri, 5 Nov 1999 18:23:28 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA21001 for linux-audio-dev-list; Fri, 5 Nov 1999 17:58:07 -0500
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA20998 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 5 Nov 1999 17:58:04 -0500
Received: by epy.co.at
	via sendmail from stdin
	id <m11jsnV-000dxtC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Sat, 6 Nov 1999 00:29:33 +0100 (CET) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Sat,  6 Nov 1999 00:29:33 +0100 (CET)
To: Paul Barton-Davis <pbd@Op.Net>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] card recommendation ?
In-Reply-To: <199911052238.RAA09105@op.net>
References: <199911052238.RAA09105@op.net>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14371.26577.688387.909920@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA05123
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 7110895d218b82460fda9479cba2503b

Paul Barton-Davis writes:
 > a friend writes:
 > 
 > >Do you have a recommendation for a PCI sound card that is:
 > >   a) Cheap (<$40).
 > >   b) Guaranteed to be supported by "standard" (i.e., non-ALSA,
 > >      non-OSS) Linux 2.2.X.
 > >I was trying to get Ensoniq AudioPCI (es1371) cards but the supply
 > >seems to be drying up.          
 > 

Really ? I think Creatives PCI128 are still easy to get.

 > as a devotee of ALSA, i can't answer him. can you ?
 > 

the Hoontech 4Dwave doesnt work on my Alpha hmpf ...

Guenter

 > --p
 > 

From - Mon Nov  8 01:44:51 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA00656
	for <slinkp@ulster.net>; Sat, 6 Nov 1999 13:17:26 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA26642 for linux-audio-dev-list; Sat, 6 Nov 1999 12:50:03 -0500
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA26639 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 6 Nov 1999 12:50:00 -0500
Received: from localhost.localdomain (d212-151-58-248.swipnet.se [212.151.58.248]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id SAA11161; 
          Sat, 6 Nov 1999 18:45:13 +0100 (MET)
From: David Olofson <audiality@swipnet.se>
To: alsa-devel@alsa-project.org
Subject: [linux-audio-dev] ALSA + lowlatency hang (?)
Date: Sat, 6 Nov 1999 18:31:15 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>,
        mingo@chiara.csoma.elte.hu
MIME-Version: 1.0
Message-Id: <99110618530301.00487@localhost.localdomain>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id NAA00656
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 3df3b1b385581481a067356e2bf19c35

I'm running ALSA 0.4.1c on a 2.2.10 + lowlatency N6B kernel (Mingo's
patch), and I have managed to freeze my system twice. (Nothing in
the logs, magic SysRq is dead etc...)

Both times, I'd been using the OSS emulation (audio+MIDI) for hours
(many open/close cycles) with no problems, and then, from what I can
see, the system freezes somewhere around when closing the devices.

The problem here is that I can't find out how to repeat it, so it's a
bit hard to track it down. I suspect that it might alternatively be
related to the kernel + ppp, as the last freeze was shortly after
being thrown off-line. Bad luck, however - I stopped an audio
program just about that time as well, so I can't really tell, and
my "statistics database" is two entries...

I'll try and find a way to repeat it and track it down; I was just
wondering if this seems familiar to anyone.


//David


PS. BTW, now, I consider this a serious problem that must be resolved
- while this kind of thing is to be *expected* from a Windoze box...
Different world. Not going back there - too much for my nerves.


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Mon Nov  8 01:45:05 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA01094
	for <slinkp@ulster.net>; Sat, 6 Nov 1999 19:23:49 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA27187 for linux-audio-dev-list; Sat, 6 Nov 1999 19:00:03 -0500
Received: from zhora.replicant.apana.org.au (replicant.apana.org.au [203.12.238.34]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA27184 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 6 Nov 1999 18:59:50 -0500
Received: (from smap@localhost)
	by zhora.replicant.apana.org.au (8.8.5/8.8.5) id KAA27415
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 7 Nov 1999 10:54:50 +1100
Received: from hexdance.replicant.apana.org.au(192.168.200.126) by zhora.replicant.apana.org.au via smap (V1.3)
	id xma027413; Sun, 7 Nov 99 10:54:35 +1100
Received: (from jlittler@localhost)
	by localhost.localdomain (8.9.3/8.9.3) id KAA00733
	for linux-audio-dev@ginette.musique.umontreal.ca; Sun, 7 Nov 1999 10:55:19 +1100
Date: Sun, 7 Nov 1999 10:55:17 +1100
From: John Littler <linuxmusic@crosswinds.net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] ALSA + lowlatency hang (?)
Message-ID: <19991107105517.A723@localhost.localdomain>
Mail-Followup-To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
References: <99110618530301.00487@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
In-Reply-To: <99110618530301.00487@localhost.localdomain>; from David Olofson on Sat, Nov 06, 1999 at 06:31:15PM +0100
X-Mailer: Mutt http://www.mutt.org/
X-URL: http://linuxmusic.cjb.net/
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 94778d41a61affa3729bfb97e1ae4f60

Yep, I'm having freeze problems too..

 David Olofson spake thusly<audiality@swipnet.se>:
> I'm running ALSA 0.4.1c on a 2.2.10 + lowlatency N6B kernel (Mingo's
> patch), and I have managed to freeze my system twice. (Nothing in
> the logs, magic SysRq is dead etc...)

but mine are unrelated to ALSA or the lowlatency patch
 
> Both times, I'd been using the OSS emulation (audio+MIDI) for hours
> (many open/close cycles) with no problems, and then, from what I can
> see, the system freezes somewhere around when closing the devices.

At first mine seemed related to netscape 4.6x and then it seemed
related to a combination of 4.7 plus emacs. With xemacs 21.1.7
and netscape 4.7 the problem has receeded (once a week instead
of 3 times a day!)... all this is on a RH6 based system BTW
 
> The problem here is that I can't find out how to repeat it, so it's a
> bit hard to track it down. I suspect that it might alternatively be
> related to the kernel + ppp, as the last freeze was shortly after
> being thrown off-line. Bad luck, however - I stopped an audio
> program just about that time as well, so I can't really tell, and
> my "statistics database" is two entries...

I'll watch out for a ppp or audio concurrence in the future ...
now that I think of it I've been online the last two times I've
had a freeze - don't think I had any audio going tho
tt
John
-- 
http://linuxmusic.cjb.net

From - Mon Nov  8 01:45:14 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA20466
	for <slinkp@ulster.net>; Sat, 6 Nov 1999 22:55:04 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA27480 for linux-audio-dev-list; Sat, 6 Nov 1999 22:33:04 -0500
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA27477 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 6 Nov 1999 22:33:01 -0500
Received: from localhost.localdomain (d212-151-108-33.swipnet.se [212.151.108.33]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id EAA25929; 
          Sun, 7 Nov 1999 04:28:18 +0100 (MET)
From: David Olofson <audiality@swipnet.se>
To: John Littler <linuxmusic@crosswinds.net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] ALSA + lowlatency hang (?)
Date: Sun, 7 Nov 1999 04:26:15 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <99110618530301.00487@localhost.localdomain> <19991107105517.A723@localhost.localdomain>
In-Reply-To: <19991107105517.A723@localhost.localdomain>
MIME-Version: 1.0
Message-Id: <99110704360700.02412@localhost.localdomain>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id WAA20466
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0886cf93abae8289d2d2fa0fdf6496b1

On Sun, 07 Nov 1999, John Littler wrote:
> I'll watch out for a ppp or audio concurrence in the future ...
> now that I think of it I've been online the last two times I've
> had a freeze - don't think I had any audio going tho

Hmm... I'm getting more and more suspicious about kernel + ppp. I
have been using both ALSA and the kernel drivers for many hours, and
done hundreds of open/close cycles without a problem, and I've been
on-line for some hours too - no freeze today. (Yet.) The crappy
dial-up server hasn't thrown me out.

Of course, when you're looking for a bug, it doesn't exist! *heh...*

I'll do various stress tests later, I think. I've had ppp do very bad
things with some kernels (unstable RTLinux versions for example), so
it's my prime suspect. It seems to be very sensitive for some
reason...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Mon Nov  8 01:45:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id IAA27007
	for <slinkp@ulster.net>; Sun, 7 Nov 1999 08:59:53 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA28099 for linux-audio-dev-list; Sun, 7 Nov 1999 08:37:07 -0500
Received: from localhost.localdomain ([194.242.217.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA28096 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 7 Nov 1999 08:37:03 -0500
Received: from localhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with SMTP id OAA00946;
	Sun, 7 Nov 1999 14:33:09 +0100
From: Benno Senoner <sbenno@gardena.net>
To: David Olofson <audiality@swipnet.se>,
        John Littler <linuxmusic@crosswinds.net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] ALSA + lowlatency hang (?)
Date: Sun, 7 Nov 1999 14:27:10 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <99110618530301.00487@localhost.localdomain> <19991107105517.A723@localhost.localdomain> <99110704360700.02412@localhost.localdomain>
In-Reply-To: <99110704360700.02412@localhost.localdomain>
Cc: alsa-devel@alsa-project.org, mingo@chiara.csoma.elte.hu
MIME-Version: 1.0
Message-Id: <99110714330900.00862@localhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7c27fa9ac6cc6395b1d58ab0107bb548

On Sun, 07 Nov 1999, David Olofson wrote:
> On Sun, 07 Nov 1999, John Littler wrote:
> > I'll watch out for a ppp or audio concurrence in the future ...
> > now that I think of it I've been online the last two times I've
> > had a freeze - don't think I had any audio going tho
> 
> Hmm... I'm getting more and more suspicious about kernel + ppp. I
> have been using both ALSA and the kernel drivers for many hours, and
> done hundreds of open/close cycles without a problem, and I've been
> on-line for some hours too - no freeze today. (Yet.) The crappy
> dial-up server hasn't thrown me out.
> 
> Of course, when you're looking for a bug, it doesn't exist! *heh...*
> 
> I'll do various stress tests later, I think. I've had ppp do very bad
> things with some kernels (unstable RTLinux versions for example), so
> it's my prime suspect. It seems to be very sensitive for some
> reason...
> 
> 
> //David

I can't tell much about ppp+lowlatency2.2.10 hangs, but the hisax.o ISDN
module crashes everytime in the init phase.

Ingo do you have some version of your patch for the 2.3.x tree available so
that we can try it on cutting edge kernel ?
Because you said the 2.2.10 patch was only meant as a "demo" and doesn't
deliver low latencies ( mainly /proc stress) for SMP boxes.

PS: Ingo do you know if your low latency extensions will be integrated in 
the next 2.3.x patches, or just before the 2.4 kernel release ?

If you have some patches available please post these somewhere so that we can
find potential bugs beforethe official release.

regards,
Benno.

From - Mon Nov  8 01:45:54 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA16502
	for <slinkp@ulster.net>; Sun, 7 Nov 1999 12:50:06 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA28390 for linux-audio-dev-list; Sun, 7 Nov 1999 12:18:30 -0500
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA28387 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 7 Nov 1999 12:18:28 -0500
Received: from localhost.localdomain (d212-151-42-114.swipnet.se [212.151.42.114]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id SAA26348 for <linux-audio-dev@ginette.musique.umontreal.ca>; 
          Sun, 7 Nov 1999 18:13:44 +0100 (MET)
From: David Olofson <audiality@swipnet.se>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Total latency measurement tool
Date: Sun, 7 Nov 1999 18:02:16 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <99110718120200.00831@localhost.localdomain>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id MAA16502
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: d2ea4d7910308e98323a4099ae78df95

Hacked a little total latency (analog+digital+driver) measurement tool
yesterday... It can't get all information out (a hardware hack is
needed for that), but at least it gives an idea what kind of figures
we're dealing with.

	http://www.linuxdj.com/audiality/analoglatency.html


Time to hack the MuCoS site and release the softsynth toy I've been
playing with for a few days now. Then it's time to break it up into
plugins, using the headers I hacked before. Remains to see how it
turns out...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Mon Nov  8 01:46:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA25467
	for <slinkp@ulster.net>; Sun, 7 Nov 1999 14:14:31 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA28493 for linux-audio-dev-list; Sun, 7 Nov 1999 13:51:21 -0500
Received: from localhost.localdomain ([194.242.217.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA28490 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 7 Nov 1999 13:51:16 -0500
Received: from localhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with SMTP id TAA02291;
	Sun, 7 Nov 1999 19:47:38 +0100
From: Benno Senoner <sbenno@gardena.net>
To: David Olofson <audiality@swipnet.se>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Total latency measurement tool
Date: Sun, 7 Nov 1999 19:45:41 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <99110718120200.00831@localhost.localdomain>
In-Reply-To: <99110718120200.00831@localhost.localdomain>
MIME-Version: 1.0
Message-Id: <99110719473803.00862@localhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4653ba0c829f879590384e491e1d172e

On Sun, 07 Nov 1999, David Olofson wrote:
> Hacked a little total latency (analog+digital+driver) measurement tool
> yesterday... It can't get all information out (a hardware hack is
> needed for that), but at least it gives an idea what kind of figures
> we're dealing with.
> 
> 	http://www.linuxdj.com/audiality/analoglatency.html
> 
> 
> Time to hack the MuCoS site and release the softsynth toy I've been
> playing with for a few days now. Then it's time to break it up into
> plugins, using the headers I hacked before. Remains to see how it
> turns out...

Nice work, meanwhile can you tell us which kind of IOlatencies you get
on your soundcard ?

I own 3 types of soundcards , TropezPlus , SB AWE64 , SB 128PCI,
If I get some useful figures I will post the results here.

Benno.

From - Mon Nov  8 01:46:10 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA28790
	for <slinkp@ulster.net>; Sun, 7 Nov 1999 14:51:50 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA28561 for linux-audio-dev-list; Sun, 7 Nov 1999 14:31:09 -0500
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA28558 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 7 Nov 1999 14:31:06 -0500
Received: from someip.ppp.op.net (d-bm2-19.ppp.op.net [209.152.194.57]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id OAA15516 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 7 Nov 1999 14:26:23 -0500 (EST)
Message-Id: <199911071926.OAA15516@renoir.op.net>
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Total latency measurement tool 
In-reply-to: Your message of "Sun, 07 Nov 1999 19:45:41 +0100."
             <99110719473803.00862@localhost.localdomain> 
Date: Sun, 07 Nov 1999 14:27:55 -0500
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 255188fb191a25ad8e235f4c7aa33363

1) Diffs enclosed below to allow use with something other than /dev/dsp.
   A pet peeve of mine - too many programs assume that you only have
   one soundcard :)

2) the README should probably make it clearer that to use it
   out, you'll need a physical loopback cable. Neither my Tropez+ nor
   my Hoontech card can be set to record PCM output (I think).

*** al.c~	Sun Nov  7 11:17:45 1999
--- al.c	Sun Nov  7 14:22:22 1999
***************
*** 241,247 ****
  	int a, err = 0;
  	int timeout = 200000;
  
! 	audiodev_init(&adev);
  	adev.fragmentsize = 256;
  	adev.fragments = 4;
  
--- 241,249 ----
  	int a, err = 0;
  	int timeout = 200000;
  
! 	audiodev_init(argv[1], &adev);
! 	argv++;
! 	argc--;
  	adev.fragmentsize = 256;
  	adev.fragments = 4;
  
*** include/audiodev.h~	Tue Nov  2 20:50:04 1999
--- include/audiodev.h	Sun Nov  7 14:21:13 1999
***************
*** 13,25 ****
  
  struct audiodev_t
  {
  	int outfd, infd;
  	int mode;
  	int rate;
  	int fragmentsize;
  	int fragments;
  };
! void audiodev_init(struct audiodev_t *ad);
  int audiodev_open(struct audiodev_t *ad);
  void audiodev_close(struct audiodev_t *ad);
  
--- 13,26 ----
  
  struct audiodev_t
  {
+         const char *devicename;
  	int outfd, infd;
  	int mode;
  	int rate;
  	int fragmentsize;
  	int fragments;
  };
! void audiodev_init(const char *name, struct audiodev_t *ad);
  int audiodev_open(struct audiodev_t *ad);
  void audiodev_close(struct audiodev_t *ad);
  
*** audiodev.c~	Sun Nov  7 00:50:50 1999
--- audiodev.c	Sun Nov  7 14:22:59 1999
***************
*** 17,25 ****
  #include <sys/types.h>
  #include "audiodev.h"
  
! void audiodev_init(struct audiodev_t *ad)
  {
! 	ad->mode = O_WRONLY;
  	ad->rate = 44100;
  	ad->fragmentsize = 256;
  	ad->fragments = 4;
--- 17,26 ----
  #include <sys/types.h>
  #include "audiodev.h"
  
! void audiodev_init(const char *name, struct audiodev_t *ad)
  {
! 	ad->devicename = name;
!         ad->mode = O_WRONLY;
  	ad->rate = 44100;
  	ad->fragmentsize = 256;
  	ad->fragments = 4;
***************
*** 38,47 ****
  		fragmentshift = 4;
  	printf("  Fragment size: %d bytes\n", 1<<fragmentshift);
  
! 	ad->outfd = ad->infd = open("/dev/dsp", ad->mode);
  	if(ad->outfd < 0)
  	{
! 		fprintf(stderr, "ERROR: Failed to open audio device!\n");
  		return -1;
  	}
  
--- 39,49 ----
  		fragmentshift = 4;
  	printf("  Fragment size: %d bytes\n", 1<<fragmentshift);
  
! 	ad->outfd = ad->infd = open(ad->devicename, ad->mode);
  	if(ad->outfd < 0)
  	{
! 		fprintf(stderr, "ERROR: Failed to open audio device %s!\n",
! 			ad->devicename);
  		return -1;
  	}
  

From - Mon Nov  8 01:46:13 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA01751
	for <slinkp@ulster.net>; Sun, 7 Nov 1999 15:47:07 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA28623 for linux-audio-dev-list; Sun, 7 Nov 1999 15:24:01 -0500
Received: from localhost.localdomain ([194.242.217.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA28620 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 7 Nov 1999 15:23:56 -0500
Received: from localhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with SMTP id VAA02850;
	Sun, 7 Nov 1999 21:20:14 +0100
From: Benno Senoner <sbenno@gardena.net>
To: Paul Barton-Davis <pbd@Op.Net>
Subject: Re: [linux-audio-dev] Total latency measurement tool
Date: Sun, 7 Nov 1999 21:18:53 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
References: <199911071926.OAA15516@renoir.op.net>
In-Reply-To: <199911071926.OAA15516@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99110721201406.00862@localhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: fdb05c5ad679df41d5bcf6109fb5dfa8

On Sun, 07 Nov 1999, Paul Barton-Davis wrote:
> 1) Diffs enclosed below to allow use with something other than /dev/dsp.
>    A pet peeve of mine - too many programs assume that you only have
>    one soundcard :)
> 
> 2) the README should probably make it clearer that to use it
>    out, you'll need a physical loopback cable. Neither my Tropez+ nor
>    my Hoontech card can be set to record PCM output (I think).

Paul, do you already got some realworld numbers for the Tropez and the Trident ?

(I have no loopback cable handy at this moment  :-( )

Benno.

From - Mon Nov  8 01:46:14 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA08614
	for <slinkp@ulster.net>; Sun, 7 Nov 1999 16:58:11 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA28702 for linux-audio-dev-list; Sun, 7 Nov 1999 16:30:18 -0500
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA28699 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 7 Nov 1999 16:30:16 -0500
Received: from someip.ppp.op.net (d-bm2-11.ppp.op.net [209.152.194.49]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id QAA21206 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 7 Nov 1999 16:25:34 -0500 (EST)
Message-Id: <199911072125.QAA21206@renoir.op.net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Total latency measurement tool 
In-reply-to: Your message of "Sun, 07 Nov 1999 21:18:53 +0100."
             <99110721201406.00862@localhost.localdomain> 
Date: Sun, 07 Nov 1999 16:27:08 -0500
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0d057da3a96360f69c890d3b0c9e01cc

>Paul, do you already got some realworld numbers for the Tropez and the Trident ?
>
>(I have no loopback cable handy at this moment  :-( )

i have no loopback cable, but i can loopback through my 24 channel
analog mixer (given that analog gear should have more or less
unmeasurable effects latency).

in theory, anyway: right now, i am stuck in between working versions
of ALSA, and i can't do anything until the ALSA CVS server gets fixed.

--p

From - Mon Nov  8 01:46:17 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA31297
	for <slinkp@ulster.net>; Sun, 7 Nov 1999 20:21:25 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA28974 for linux-audio-dev-list; Sun, 7 Nov 1999 19:47:17 -0500
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA28971 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 7 Nov 1999 19:47:14 -0500
Received: from localhost.localdomain (d212-151-56-17.swipnet.se [212.151.56.17]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA17184; 
          Mon, 8 Nov 1999 01:42:23 +0100 (MET)
From: David Olofson <audiality@swipnet.se>
To: Benno Senoner <sbenno@gardena.net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Total latency measurement tool
Date: Mon, 8 Nov 1999 01:19:03 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <99110718120200.00831@localhost.localdomain> <99110719473803.00862@localhost.localdomain>
In-Reply-To: <99110719473803.00862@localhost.localdomain>
MIME-Version: 1.0
Message-Id: <99110801501401.04917@localhost.localdomain>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA31297
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1fca33b4f0269deb3d8e33b2259e27b6

On Sun, 07 Nov 1999, Benno Senoner wrote:
> Nice work, meanwhile can you tell us which kind of IOlatencies you get
> on your soundcard ?

I get 26 samples regardless of sample rate with the PCI128 and the
kernel driver. That is, all measurable latency seems to be in the
digital filters in the CODEC, and/or the driver + DMA.

(I have a problem with ALSA and input, so I can't get reliable
results with it. Discovered that when running the audio input through
the "reverb" in my softsynth... The same full duplex code.)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Mon Nov  8 01:46:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA03682
	for <slinkp@ulster.net>; Sun, 7 Nov 1999 21:01:53 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA29034 for linux-audio-dev-list; Sun, 7 Nov 1999 20:38:55 -0500
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA29031 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 7 Nov 1999 20:38:53 -0500
Received: from localhost.localdomain (d212-151-103-20.swipnet.se [212.151.103.20]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA24595; 
          Mon, 8 Nov 1999 02:34:07 +0100 (MET)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>
Subject: Re: [linux-audio-dev] Total latency measurement tool
Date: Mon, 8 Nov 1999 02:25:54 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
References: <199911071926.OAA15516@renoir.op.net>
In-Reply-To: <199911071926.OAA15516@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99110802401700.05447@localhost.localdomain>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA03682
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f4250b181ce98ba0aa2e834b5ed4c4ce

On Sun, 07 Nov 1999, Paul Barton-Davis wrote:
> 1) Diffs enclosed below to allow use with something other than /dev/dsp.
>    A pet peeve of mine - too many programs assume that you only have
>    one soundcard :)

My version enclosed. :-) The device name is now optional, and the
default is /dev/dsp. (Apply with 'patch -p0 <whateveryounameit'.)

> 2) the README should probably make it clearer that to use it
>    out, you'll need a physical loopback cable. Neither my Tropez+ nor
>    my Hoontech card can be set to record PCM output (I think).

Ok, many cards can't record their PCM outputs, so the loopback cable
should be described as the normal solution. (The AudioPCI seems to
have almost a full matrix of switches - the only problem is to find a
mixer that lets you set it up correctly... amixer works fine.)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer


----8<---------------------------------------------------------

diff -ru analoglatency-0.0.1/al.c analoglatency-0.0.2/al.c
--- analoglatency-0.0.1/al.c	Sun Nov  7 17:17:45 1999
+++ analoglatency-0.0.2/al.c	Mon Nov  8 02:16:33 1999
@@ -1,6 +1,6 @@
 /*
  *	al - The Analog Latency test
- *      0.0.1
+ *      0.0.2
 ------------------------------------------------------------
 al.c:	The analog latency measurement tool
 ------------------------------------------------------------
@@ -255,10 +255,7 @@
 		if('-'==argv[a][0])
 			err = parse_arg(argv[a]);
 		else
-		{
-			print_help();
-			err = -100;
-		}
+			adev.devicename = argv[a];
 	}
 	if(err)
 		return 0;
diff -ru analoglatency-0.0.1/audiodev.c analoglatency-0.0.2/audiodev.c
--- analoglatency-0.0.1/audiodev.c	Sun Nov  7 06:50:50 1999
+++ analoglatency-0.0.2/audiodev.c	Mon Nov  8 02:16:36 1999
@@ -19,6 +19,7 @@
 
 void audiodev_init(struct audiodev_t *ad)
 {
+	ad->devicename = "/dev/dsp";
 	ad->mode = O_WRONLY;
 	ad->rate = 44100;
 	ad->fragmentsize = 256;
@@ -38,7 +39,7 @@
 		fragmentshift = 4;
 	printf("  Fragment size: %d bytes\n", 1<<fragmentshift);
 
-	ad->outfd = ad->infd = open("/dev/dsp", ad->mode);
+	ad->outfd = ad->infd = open(ad->devicename, ad->mode);
 	if(ad->outfd < 0)
 	{
 		fprintf(stderr, "ERROR: Failed to open audio device!\n");
diff -ru analoglatency-0.0.1/include/audiodev.h analoglatency-0.0.2/include/audiodev.h
--- analoglatency-0.0.1/include/audiodev.h	Wed Nov  3 02:50:04 1999
+++ analoglatency-0.0.2/include/audiodev.h	Mon Nov  8 02:16:38 1999
@@ -13,6 +13,7 @@
 
 struct audiodev_t
 {
+	const char *devicename;
 	int outfd, infd;
 	int mode;
 	int rate;

From - Mon Nov  8 16:09:37 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id EAA00376
	for <slinkp@ulster.net>; Mon, 8 Nov 1999 04:10:17 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id DAA03468 for linux-audio-dev-list; Mon, 8 Nov 1999 03:42:01 -0500
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA03465 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 8 Nov 1999 03:41:58 -0500
Received: from ulster.net (port65.ts2.ulster.net [208.242.164.65])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id DAA31676
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 8 Nov 1999 03:43:13 -0500
Message-ID: <38268DDB.1701A570@ulster.net>
Date: Mon, 08 Nov 1999 03:46:19 -0500
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Low latency and WINE?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 695c63cb59eeda8450fb423ed4754bc7

Just wondering...

Has anyone tried using a lowlatency-patched kernel with WINE and a
Windows MIDI sequencer?

I'm wondering because last time I tried WINE, about a year ago, it
was just about good enough to run the ancient version of Cakewalk
that came with my cheap MIDI keyboard. Ditto for some Voyetra
sequencer that came with my soundcard. But one of them (I forget
which) didn't really work; the other looked OK and even found the
wavetable synth in my Malibu card, but the output timing was
terrible-- obviously off by hundreds of milliseconds for some notes.

I assume this was a WINE problem, but just wondered if maybe the
low-latency patches helped any? Has anyone tried this?
Or is running Windows sequencers on Linux just doomed?

-- 

----------------    paul winkler    ------------------
slinkP arts:  music, sound, illustration, design, etc.
email=========================slinkp AT ulster DOT net
ARMS online=======================http://reacharms.com    
personal page===========http://www.ulster.net/~abigoo/

From - Mon Nov  8 16:09:39 1999
Received: from mail.mailstart.com (ns1.mailstart.com [207.231.76.65])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id EAA01169
	for <slinkp@ulster.net>; Mon, 8 Nov 1999 04:28:51 -0500
From: Golinvaux-Benjamin.net@mb.mailbank.com
Received: from yellow [207.231.76.48] by mail.mailstart.com
  (SMTPD32-5.05) id A665AB100D2; Mon, 08 Nov 1999 01:22:45 -0800
To: slinkp@ulster.net
CC: 
Subject: RE: [linux-audio-dev] Low latency and WINE?
Message-Id: <081199312.4965@195.207.174.32>
Content-Type: TEXT/PLAIN; charset=US-ASCII
Date: Mon,  8 Nov 1999 01:22:49 -0800
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: be58afac6b171e0c11a71a6bd9a1f560


They day someone runs cubase or cakewalk with lower
latency under WINE than under Windoze, I promise I
open two or three bottles of Champagne ;-)

(the 16 bit stuff will be hard to emulate... maybe
with the new 32 bit WDM driverz ?)

A thin DirectSound layer above /dev/dsp !!! I want it ;-)

Benjamin-




-----
Sent using MailStart.com ( http://MailStart.Com/welcome.html )
The FREE way to access your mailbox via any web browser, anywhere!

From - Mon Nov  8 16:09:40 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id EAA02219
	for <slinkp@ulster.net>; Mon, 8 Nov 1999 04:54:17 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id EAA03715 for linux-audio-dev-list; Mon, 8 Nov 1999 04:28:08 -0500
Received: from mail.mailstart.com (ns1.mailstart.com [207.231.76.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA03712 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 8 Nov 1999 04:28:05 -0500
From: golinvaux@benjamin.net
Received: from maroon [207.231.76.76] by mail.mailstart.com
  (SMTPD32-5.05) id A68A6E500DC; Mon, 08 Nov 1999 01:23:22 -0800
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: RE: [linux-audio-dev] Low latency and WINE?
Message-Id: <081199312.5003@195.207.174.32>
Content-Type: TEXT/PLAIN; charset=US-ASCII
Date: Mon,  8 Nov 1999 01:23:24 -0800
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 674a5b9bd724615f1783ec58e3fa17bd


They day someone runs cubase or cakewalk with lower
latency under WINE than under Windoze, I promise I
open two or three bottles of Champagne ;-)

(the 16 bit stuff will be hard to emulate... maybe
with the new 32 bit WDM driverz ?)

A thin DirectSound layer above /dev/dsp !!! I want it ;-)

Benjamin-




-----
Sent using MailStart.com ( http://MailStart.Com/welcome.html )
The FREE way to access your mailbox via any web browser, anywhere!

From - Mon Nov  8 16:09:46 1999
Received: from em.gardena.net ([212.11.71.70])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id IAA13691
	for <slinkp@ulster.net>; Mon, 8 Nov 1999 08:06:26 -0500
Received: (from sbenno@localhost)
	by em.gardena.net (8.9.1/8.9.0) id OAA16710;
	Mon, 8 Nov 1999 14:00:10 +0100
From: Benno Senoner <sbenno@em.gardena.net>
Message-Id: <199911081300.OAA16710@em.gardena.net>
Subject: Re: [linux-audio-dev] Low latency and WINE?
To: slinkp@ulster.net (Paul Winkler)
Date: Mon, 8 Nov 1999 14:00:10 +0100 (MET)
Cc: linux-audio-dev@ginette.musique.umontreal.ca
In-Reply-To: <38268DDB.1701A570@ulster.net> from "Paul Winkler" at Nov 8, 99 03:46:19 am
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f40201b9eeac6408519d8154fad68ca7

> 
> Just wondering...
> 
> Has anyone tried using a lowlatency-patched kernel with WINE and a
> Windows MIDI sequencer?
> 
> I'm wondering because last time I tried WINE, about a year ago, it
> was just about good enough to run the ancient version of Cakewalk
> that came with my cheap MIDI keyboard. Ditto for some Voyetra
> sequencer that came with my soundcard. But one of them (I forget
> which) didn't really work; the other looked OK and even found the
> wavetable synth in my Malibu card, but the output timing was
> terrible-- obviously off by hundreds of milliseconds for some notes.
> 
> I assume this was a WINE problem, but just wondered if maybe the
> low-latency patches helped any? Has anyone tried this?
> Or is running Windows sequencers on Linux just doomed?
> 

I don't know WINE internals, but the "earliest deadline" approach
should work here too:

I don't know how exactly Windoze sequencers are implemented,
but if they run their MIDI/audio stuff as a separate thread,
then it could be definitively possible.

Assume the sequencer runs the GUI in 1 thread and the midi/audio stuff
in an other thread.
On Linux there will be concurrency between these 2 threads and the
other Linux stuff, especially the X server.
If you set the audio/midi thread SCHED_FIFO max priority,
(maybe using an external program, or patching WINE to
set SCHED_FIFO when a thread requests realtime privileges
(is this already implemented?)  ),
then it should be possible.

A smart gui has even managed to run a VQF (similar to mp3 made by Yamaha),
decoder to run under Linux. (by using winelib to load the CODEC)
With a similar technique, we could even run
Waves Trueverb with 3ms IOlatency under Linux, and
misuse our Linux bock as a realtime FX.
:-)
But this scares David very much, because he says if it turns out
to be true, then windoze plugin developer will not have any motivation
to port the plugins to our native Mucos plugin API.
But it would be *EXTREMELY FUNNY* runnning windoze plugins
with orders of magnitude lower latencies on Linux than on the
original host operating system.
That would be an extremely impressive technical demo,
for developers which are still sceptical about the capabilities
of Linux.

Benno

From - Mon Nov  8 16:09:51 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id IAA17322
	for <slinkp@ulster.net>; Mon, 8 Nov 1999 08:39:16 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA03962 for linux-audio-dev-list; Mon, 8 Nov 1999 08:07:53 -0500
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA03959 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 8 Nov 1999 08:07:48 -0500
Received: (from sbenno@localhost)
	by em.gardena.net (8.9.1/8.9.0) id OAA16765;
	Mon, 8 Nov 1999 14:02:50 +0100
From: Benno Senoner <sbenno@em.gardena.net>
Message-Id: <199911081302.OAA16765@em.gardena.net>
Subject: Re: [linux-audio-dev] Low latency and WINE?
To: Golinvaux-Benjamin.net@mb.mailbank.com
Date: Mon, 8 Nov 1999 14:02:50 +0100 (MET)
Cc: linux-audio-dev@ginette.musique.umontreal.ca
In-Reply-To: <081199312.5011@195.207.174.32> from "Golinvaux-Benjamin.net@mb.mailbank.com" at Nov 8, 99 01:23:12 am
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3cd5c80a3ce2ab285005241bd35ad8c7

> 
> 
> They day someone runs cubase or cakewalk with lower
> latency under WINE than under Windoze, I promise I
> open two or three bottles of Champagne ;-)
> 
> (the 16 bit stuff will be hard to emulate... maybe
> with the new 32 bit WDM driverz ?)
> 
> A thin DirectSound layer above /dev/dsp !!! I want it ;-)
> 
> Benjamin-
> 
> 
Benjamin, when I get some time, I will test this with simple
VST plugins, (using the VQF hack as guideline),
there is a possibility that you have to prepare the bottles
sonn ... hopefully sharing the content with us.
:-)

Benno.

From - Mon Nov  8 16:09:59 1999
Received: from pop02.iname.net (pop02.iname.net [165.251.20.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id KAA03392
	for <slinkp@ulster.net>; Mon, 8 Nov 1999 10:46:23 -0500
Received: from mindless.com ([216.111.166.87])
	by pop02.iname.net (8.9.3/8.9.3) with ESMTP id KAA26172
	for <slinkp@ulster.net>; Mon, 8 Nov 1999 10:40:14 -0500 (EST)
Message-ID: <3826EEBE.FC2C6BAE@mindless.com>
Date: Mon, 08 Nov 1999 07:39:42 -0800
From: jiva <jiva@mindless.com>
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: Paul Winkler <slinkp@ulster.net>
Subject: Re: [linux-audio-dev] Low latency and WINE?
References: <38268DDB.1701A570@ulster.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d1e7b2240c6ac59a184beff53f07d732

How about the very ancient version of cakewalk I still have around - the
dos version under the dos emulator. cool, huh? I'm going to have to try
it when I get a chance.

Ian

From - Tue Nov  9 01:57:17 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA05140
	for <slinkp@ulster.net>; Mon, 8 Nov 1999 17:42:12 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA04761 for linux-audio-dev-list; Mon, 8 Nov 1999 17:11:37 -0500
Received: from alsa.alsa-project.org (alsa.jcu.cz [160.217.1.49]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA04758 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 8 Nov 1999 17:11:33 -0500
Received: from localhost (andy@localhost)
	by alsa.alsa-project.org (8.8.8/8.8.8) with ESMTP id XAA20856
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 8 Nov 1999 23:07:06 +0100
Date: Mon, 8 Nov 1999 23:07:06 +0100 (MET)
From: Andy Lo A Foe <andy@alsa-project.org>
To: Linux Audio Dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] alsaplayer 0.99.29
Message-ID: <Pine.LNX.4.05.9911082305460.20702-100000@alsa.alsa-project.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 8a44e7f8f185765960567afc8a7ed8cc

For those interested I just release a new version of alsaplayer. Major
change in this release includes support for current ALSA CVS.

Get it at http://www.alsa-project.org/~andy/

or via ftp: 

ftp://ftp.alsa-project.org/pub/people/andy/alsaplayer-0.99.29.tar.gz

Regs,
Andy
--
AlsaPlayer, http://www.alsa-project.org/~andy/

From - Tue Nov  9 01:57:20 1999
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id SAA15070
	for <slinkp@ulster.net>; Mon, 8 Nov 1999 18:42:51 -0500
Received: from localhost.localdomain (d212-151-47-45.swipnet.se [212.151.47.45]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA15130; 
          Tue, 9 Nov 1999 00:36:35 +0100 (MET)
From: David Olofson <audiality@swipnet.se>
To: Benno Senoner <sbenno@em.gardena.net>, slinkp@ulster.net (Paul Winkler)
Subject: Re: [linux-audio-dev] Low latency and WINE?
Date: Tue, 9 Nov 1999 00:22:27 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <199911081300.OAA16710@em.gardena.net>
In-Reply-To: <199911081300.OAA16710@em.gardena.net>
MIME-Version: 1.0
Message-Id: <99110900442902.00563@localhost.localdomain>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id SAA15070
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c9442f969b6f635a78b0d1d6bdddcc33

On Mon, 08 Nov 1999, Benno Senoner wrote:
> I don't know how exactly Windoze sequencers are implemented,
> but if they run their MIDI/audio stuff as a separate thread,
> then it could be definitively possible.

16 bit:	Callbacks from a "multimedia timer". The code runs in
	interrupt context, and has restrictions as to what
	system calls can be used.

32 bit:	Used to suck real bad, because you had to run it in a
	normal thread, and I guess you can figure out what that
	meant to timing... However, M$ fixed this through the
	usual API extansion; timestamped MIDI calls were added
	to the multimedia driver API, so that you can queue
	some events ahead.

(You didn't think they use a real fs style API, did you!? Nope,
dedicated function calls for *everything*. Now, that's one way to
make sure porting gets painful...)

> Assume the sequencer runs the GUI in 1 thread and the midi/audio stuff
> in an other thread.

Well, kind of...

> On Linux there will be concurrency between these 2 threads and the
> other Linux stuff, especially the X server.
> If you set the audio/midi thread SCHED_FIFO max priority,
> (maybe using an external program, or patching WINE to
> set SCHED_FIFO when a thread requests realtime privileges
> (is this already implemented?)  ),
> then it should be possible.

Yes, as long as no extra threads get in the way when the audio/MIDI
thread uses the Windows APIs.

> A smart gui has even managed to run a VQF (similar to mp3 made by Yamaha),
> decoder to run under Linux. (by using winelib to load the CODEC)
> With a similar technique, we could even run
> Waves Trueverb with 3ms IOlatency under Linux, and
> misuse our Linux bock as a realtime FX.
> :-)
> But this scares David very much, because he says if it turns out
> to be true, then windoze plugin developer will not have any motivation
> to port the plugins to our native Mucos plugin API.

Depends on how use(full|less) this solution becomes, compared to
MuCoS or whatever "native" API we'll have.

> But it would be *EXTREMELY FUNNY* runnning windoze plugins
> with orders of magnitude lower latencies on Linux than on the
> original host operating system.

Yep, that would certainly make Windows look pretty bad as a so called
professional OS. *hehe*

> That would be an extremely impressive technical demo,
> for developers which are still sceptical about the capabilities
> of Linux.

I don't think the developers are much of a problem to convince - just
show them the figures, and perhaps help them to set up a development
system.

The marketing people, however, have no clue about technical
specifications. It's all about looking and sounding impressive. This
demo would probably work rather well to convince a few of them.

(There are quite a few people that don't see anything
non-(M$|MacOS|whatever), no matter if you show thew stuff that has
10 times the performance. These are the dangerous ones; the ones that
understand marketing and money, but don't even give a damn if the
stuff works. Ain't seen enough of that already?)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Tue Nov  9 01:57:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA01999
	for <slinkp@ulster.net>; Tue, 9 Nov 1999 01:07:19 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA05400 for linux-audio-dev-list; Tue, 9 Nov 1999 00:37:39 -0500
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA05397 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 9 Nov 1999 00:37:32 -0500
Received: from op.net (d-bm2-0d.ppp.op.net [209.152.194.45]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id AAA17457 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 9 Nov 1999 00:33:02 -0500 (EST)
Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id AAA17018; Tue, 9 Nov 1999 00:34:55 -0500
Date: Tue, 9 Nov 1999 00:34:55 -0500
Message-Id: <199911090534.AAA17018@op.net>
From: Paul Barton-Davis <pbd@Op.Net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] FYI: softwerk, v2.0 coming soon
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: fba76143b74baadd9cef57e0669d0c73

today, i got a long way porting softwerk to GTK (well OK, Gtk--).
about 80% of the functionality is in place already.

a major new feature that GTK makes easy to support is an arbitrary
number of steps and an arbitrary number of sequences. you can
dynamically add steps and sequences while softwerk is running. of
course, this ends up involving the dreaded scrollable windows and
their associated scrolling controls, but the benefits currently seem to
outweigh the inconvenience. if anyone has any good UI tips on how to
minimize the damage these cause, i'd love to hear them.

minor new features: a mute button for each sequence, plus the control
over the visual appearance offered by using GTK's rc files.

i still need to add trigger editing, a patternfile interface, and some
other minor details, but this shouldn't take too long given how quick
the bulk of it has been.

and of course, softwerk is now based on libsigc++ as well as my own
libmidi++, and will use autoconf/automake. there are no calls to the
UI from the "engine" any more, although this particular piece of
software will not be split into a library any time soon :)

--p

From - Wed Nov 10 00:15:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA10051
	for <slinkp@ulster.net>; Tue, 9 Nov 1999 20:18:35 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA11227 for linux-audio-dev-list; Tue, 9 Nov 1999 19:53:03 -0500
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA11224 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 9 Nov 1999 19:53:00 -0500
Received: from localhost.localdomain (d212-151-98-186.swipnet.se [212.151.98.186]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA17952; 
          Wed, 10 Nov 1999 01:48:24 +0100 (MET)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] FYI: softwerk, v2.0 coming soon
Date: Wed, 10 Nov 1999 01:49:19 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199911090534.AAA17018@op.net>
In-Reply-To: <199911090534.AAA17018@op.net>
MIME-Version: 1.0
Message-Id: <99111001562102.00486@localhost.localdomain>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA10051
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: aed2f557230687137299f7f0e17d661b

On Tue, 09 Nov 1999, Paul Barton-Davis wrote:
> today, i got a long way porting softwerk to GTK (well OK, Gtk--).
> about 80% of the functionality is in place already.
> 
> a major new feature that GTK makes easy to support is an arbitrary
> number of steps and an arbitrary number of sequences. you can
> dynamically add steps and sequences while softwerk is running. of
> course, this ends up involving the dreaded scrollable windows and
> their associated scrolling controls, but the benefits currently seem to
> outweigh the inconvenience. if anyone has any good UI tips on how to
> minimize the damage these cause, i'd love to hear them.

Well, there are the two tracker variants; full scrolling and moving
cursor + page flipping.

The full scrolling way was an obvious choice for the Amiga, as it had
hardware scrolling (no, not the blitter; changing the video read
pointer on the fly). It was actually easier to code than a moving
cursor row... But even on fast machines and video boards, that
requires some effort not to result in a completely useless
flickering CPU+video accelerator hog.

Page flipping OTOH, has to be handled in some clever way not to
become very confusing. Which way works best may depend on what the
display looks like, and of course, user preference...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Nov 10 02:05:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA17525
	for <slinkp@ulster.net>; Wed, 10 Nov 1999 01:55:24 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id BAA15536 for linux-audio-dev-list; Wed, 10 Nov 1999 01:26:04 -0500
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA15533 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 10 Nov 1999 01:25:58 -0500
Received: from someip.ppp.op.net (d-bm3-18.ppp.op.net [209.152.194.88]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id BAA09859; Wed, 10 Nov 1999 01:21:18 -0500 (EST)
Message-Id: <199911100621.BAA09859@renoir.op.net>
To: David Olofson <audiality@swipnet.se>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Total latency measurement tool 
In-reply-to: Your message of "Mon, 08 Nov 1999 01:19:03 +0100."
             <99110801501401.04917@localhost.localdomain> 
Date: Wed, 10 Nov 1999 01:22:11 -0500
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 80d4998af1f38fd8f111a29965bfe33d

>I get 26 samples regardless of sample rate with the PCI128 and the
>kernel driver. That is, all measurable latency seems to be in the
>digital filters in the CODEC, and/or the driver + DMA.
>
>(I have a problem with ALSA and input, so I can't get reliable
>results with it. Discovered that when running the audio input through
>the "reverb" in my softsynth... The same full duplex code.)

what does reliable mean ? for example, is this "stable" ?

Delay: 61 samples
Delay: 45 samples
Delay: 49 samples
Delay: 49 samples
Delay: 73 samples
Delay: 56 samples
Delay: 72 samples
Delay: 60 samples
Delay: 72 samples
Delay: 67 samples
Delay: 76 samples
Delay: 43 samples
Delay: 69 samples
Delay: 62 samples
Delay: 80 samples
Delay: 56 samples
Delay: 57 samples
Delay: 51 samples
Delay: 48 samples
Delay: 56 samples
Delay: 63 samples
Delay: 47 samples
Delay: 56 samples
Delay: 67 samples
Delay: 43 samples
Delay: 41 samples
Delay: 56 samples
Delay: 66 samples
Delay: 57 samples
Delay: 56 samples     

if not, its a bug in ALSA 0.5.0 (OSS emulation?) that needs to be fixed.

--p

From - Wed Nov 10 02:15:40 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id CAA17912
	for <slinkp@ulster.net>; Wed, 10 Nov 1999 02:02:55 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id BAA15557 for linux-audio-dev-list; Wed, 10 Nov 1999 01:41:39 -0500
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA15554 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 10 Nov 1999 01:41:36 -0500
Received: from someip.ppp.op.net (d-bm3-18.ppp.op.net [209.152.194.88]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id BAA10479 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 10 Nov 1999 01:37:02 -0500 (EST)
Message-Id: <199911100637.BAA10479@renoir.op.net>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Total latency measurement tool 
In-reply-to: Your message of "Mon, 08 Nov 1999 02:25:54 +0100."
             <99110802401700.05447@localhost.localdomain> 
Date: Wed, 10 Nov 1999 01:37:55 -0500
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4c374fd1478292155f0fa0fac5e06da2

david - can you explain why the input/output level should have such a
pronounced effect on the test ? i understand the idea of a threshold
for detection, but it seems that moving the input gain or pcm volume
up and down can have quite a substantial impact on the numbers being
displayed. this seems counter-intuitive to me. it could be a side
effect of my current super-crappy-video card too.

for my trident 4d-nx card, i can get stable readings of about 32
samples (using ALSA-OSS-emulation) - makes sense given the PCI burst
size, doesn't it ?

for my tropez+ (ISA bus), the test doesn't seem to work: it complains
about the level being too low, despite everything being turned all the
way up.

these numbers involve routing the signal through a samson 24 track
analog mixer, but i can't imagine that this should affect them given
the measurement being performed.

--p

From - Thu Nov 11 14:09:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA08403
	for <slinkp@ulster.net>; Wed, 10 Nov 1999 15:34:03 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA17014 for linux-audio-dev-list; Wed, 10 Nov 1999 14:58:22 -0500
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id OAA17011 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 10 Nov 1999 14:58:15 -0500
From: est@hyperreal.org
Received: (qmail 19115 invoked by uid 162); 10 Nov 1999 19:23:03 -0000
Message-ID: <19991110192303.19111.qmail@hyperreal.org>
Subject: [linux-audio-dev] implementing EQ
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Wed, 10 Nov 1999 11:23:03 -0800 (PST)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 20d6a07a999bfa9feb82ccedd38dbadb

Hello, All

I was wondering what people like to use to implement EQ.  I've used
parallel biquadratic filters..low and high pass on the ends and
band-pass in the middle.  It's OK for 3 bands, but I'm thinking that
for more, iterated biquads in the middle might be better.

I guess one handy visual way to test such things would be passing
noise through them and looking at the spectrum.  What do people
recommend for spectrum viewing?

Thanks,

Eric

From - Thu Nov 11 14:09:14 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA23209
	for <slinkp@ulster.net>; Wed, 10 Nov 1999 17:16:31 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA17280 for linux-audio-dev-list; Wed, 10 Nov 1999 16:42:00 -0500
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id QAA17277 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 10 Nov 1999 16:41:57 -0500
Message-Id: <199911102141.QAA17277@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] implementing EQ
To: est@hyperreal.org
Date: Wed, 10 Nov 1999 16:36:42 -0500 (EST)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
In-Reply-To: <19991110192303.19111.qmail@hyperreal.org> from "est@hyperreal.org" at Nov 10, 99 11:23:03 am
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f871d12895b18761a5f368458b2fb61f

est@hyperreal.org wrote:
> I was wondering what people like to use to implement EQ.  I've used
> parallel biquadratic filters..low and high pass on the ends and
> band-pass in the middle.

The standard parametric EQ filters, shelving and boost/cut, are
familiar to people.  And they're suitable for being run in series so
you don't have the phase cancellation hassle of parallel filter banks.

function [B, A] = eqgen(Fc, gain, width)
% [B, A] = eqgen(Fc, gain, width)
% calculate biquad coefficients for a boost/cut filter.
% Fc normalized 0-1, gain in dB, width in octaves.

O = Fc*pi;
bw = width;
K = 10^(gain/20);
J = sqrt(K);
g = sinh( log(2)/2 * O/sin(O) * bw) * sin(O);

den = 1 + g/J;

b0 = (1 + g*J) / den;
b1 = -2*cos(O) / den;
b2 = (1 - g*J) / den;
a2 = (1 - g/J) / den;
a1 = b1;

B = [b0 b1 b2];
A = [ 1 a1 a2];

> I guess one handy visual way to test such things would be passing
> noise through them and looking at the spectrum.  What do people
> recommend for spectrum viewing?

I use Matlab, but don't necessarily recommend buying it as a private
citizen.  Scilab and Octave are good free alternatives.
http://www-rocq.inria.fr/scilab/
http://www.che.wisc.edu/octave/
You might, by the way, want to get non-noisy amplitude response
directly from the transfer function or impulse response.

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Thu Nov 11 14:09:36 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA10447
	for <slinkp@ulster.net>; Wed, 10 Nov 1999 19:18:09 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA17690 for linux-audio-dev-list; Wed, 10 Nov 1999 18:47:31 -0500
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA17687 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 10 Nov 1999 18:47:27 -0500
Received: from localhost.localdomain (IDENT:root@[194.242.217.41])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id AAA02911;
	Thu, 11 Nov 1999 00:41:22 +0100
Received: from localhost.localdomain (IDENT:benno@localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with SMTP id AAA01087;
	Thu, 11 Nov 1999 00:42:52 +0100
From: Benno Senoner <sbenno@gardena.net>
To: linux-kernel@vger.rutgers.edu,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] APM killing low-latency performance on BX mainboard (we need a method to disable it dynamically)
Date: Wed, 10 Nov 1999 23:49:41 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, faith@cs.unc.edu,
        audiality@swipnet.se, mingo@chiara.csoma.elte.hu, axboe@image.dk
MIME-Version: 1.0
Message-Id: <99111100425200.00788@localhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 7563f1bcd9b9f01ad7ac7492088a9434

Hi,
I discovered a problem of APM which can ruin the performance of low-latency
(realtime) apps.
All tests performed using Ingo's  2.2.10-lowlatency-N6 patch:

On my new dual Celeron box with  Gigabyte GA-6BX mainboard,
when enabling APM, ( Redhat comes with APM enabled by default),
there are regular IRQ losses when the APM driver polls the hardware.
( every second)

I discovered when I ran the latencytest benchmark:

With Ingo's patches, my old P133 delivered rock-solid (while stressed) 2.1ms
latencies.
While my Celeron366 (in UP mode, because SMP lowlatency performance
is not properly optimized on Ingo's patch), shows up regular 2ms peaks (at 1 sec
interval) when the box is completely idle.
With bigger audio fragment sizes the diagrams show clearly that there are losses
of IRQs when APM makes the BIOS calls.
When I disabled APM on my Celeron, the results were rock-solid without any
nasty peaks.
Note that disabling the power management in the BIOS and running an APM enabled
kernel did not help: APM remained active and the peaks at 1sec intervals were
still present. 
Note that the same happens when I'm doing high freq timing tests using RTC.
Same peaks , same problems, and disabling APM solves the RTC problems too.

Now my question: in order to achieve best low-latency performance, we
need a way to disable APM on problematic boxes, but without recompiling
the kernel.


my proposals:
make a sysctl ( or is this already implemented) to disable APM at
runtime
or: make a kernel commandline boot option which allows to disable
APM at boottime, just like when the kernel detects that it is running on
a SMP box.

now the diagrams:

APM ENABLED:

4x128 audiobuffer
http://www.gardena.net/benno/linux/audio/apm/enabled/4x128.html

note the regular peaks at exactly 1 sec interval.
I was unableto get reliable playback with this buffersize on the Celeron+APM,
while the P133 gave me no problems.

4x8192 audiobuffer:
http://www.gardena.net/benno/linux/audio/apm/enabled/4x8192.html

note that this diagram shows that some IRQs of the soundcard get lost,
causing high latencies, and therefore potentially unreliabe playback when
using small buffersizes.

APM DISABLED:  rock-solid results !
http://www.gardena.net/benno/linux/audio/apm/disabled/4x128.html

Note that in order to get really low-latencies all IDE devices must be DMA
enabled with unmaskirq and if possible 32bit access enabled:

I discovered a small (but easy to correct) problem:

by default ATAPI CDROM driver run with DMA , unmaskirq and 32bit I/O all three
disabled.
You can tune this using hdparm -d 1 -u 1 -c 1 /dev/hdc or so ,
but the problem is that you can't do this when there is no CD in the drive.

It would be nice a to add an option to hdparm and/or the ATAPI  CDROM driver,
to force the mode changes, so that the distros could do this in the initscripts
by default.

For example I have a MASHITA DVD ATAPI as hdc,
and when mounting a CDROM and cp'ing the entire CD to the harddisk,
when the DVD/CDROM drive is in untuned mode, the latencies go
up to 20-70ms , but when tuning the CDROM drive with hdparm,
the latencies go down to a rock-solid 2ms  !

comments, suggestions  ?

regards,
Benno.
sbenno@gardena.net
Linux low-latency benchmarks:
http://www.gardena.net/benno/linux/audio  

From - Thu Nov 11 14:09:27 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA05322
	for <slinkp@ulster.net>; Wed, 10 Nov 1999 18:44:21 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA17611 for linux-audio-dev-list; Wed, 10 Nov 1999 18:16:32 -0500
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id SAA17608 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 10 Nov 1999 18:16:25 -0500
From: est@hyperreal.org
Received: (qmail 27208 invoked by uid 162); 10 Nov 1999 23:00:49 -0000
Message-ID: <19991110230048.27206.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] implementing EQ
In-Reply-To: <19991110192303.19111.qmail@hyperreal.org> from "est@hyperreal.org"
 at "Nov 10, 1999 11:23:03 am"
To: est@hyperreal.org
Date: Wed, 10 Nov 1999 15:00:48 -0800 (PST)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 343ccfe941cdabca9c6d3953d38fa311

est@hyperreal.org discourseth:
> 
> I was wondering what people like to use to implement EQ.

Poking around a bit, I see that clm
(ccrma-www.stanford.edu/CCRMA/Software/clm/clm-manual/clm.html)
recommends using its `formant' operator..a little cheaper than general
biquadratic filters.  Then there's the Zolzer-Boltze filter used by gQ
(www.music.princeton.edu/%7Edan/gQpage/).

Any experience-with/opinions-on these?

Eric

From - Thu Nov 11 14:09:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA07718
	for <slinkp@ulster.net>; Wed, 10 Nov 1999 19:00:38 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA17660 for linux-audio-dev-list; Wed, 10 Nov 1999 18:35:53 -0500
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id SAA17657 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 10 Nov 1999 18:35:49 -0500
From: est@hyperreal.org
Received: (qmail 3330 invoked by uid 162); 10 Nov 1999 23:06:13 -0000
Message-ID: <19991110230612.3329.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] implementing EQ
In-Reply-To: From Eli Brandt at "Nov 10, 1999 04:36:42 pm"
To: eli+@cs.cmu.edu
Date: Wed, 10 Nov 1999 15:06:12 -0800 (PST)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2aec0d96fdc4833c86fce87d98554ceb

Eli Brandt discourseth:
> est@hyperreal.org wrote:
> > I was wondering what people like to use to implement EQ.  I've used
> > parallel biquadratic filters..low and high pass on the ends and
> > band-pass in the middle.
> 
> The standard parametric EQ filters, shelving and boost/cut, are
> familiar to people.  And they're suitable for being run in series so
> you don't have the phase cancellation hassle of parallel filter banks.

Hmm..how does the filter you showed coeficcients for compare to
butterworth filters?  Also, I don't understand how using them in
parallel can be avoided.

Thanks,

Eric

From - Thu Nov 11 14:09:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA13297
	for <slinkp@ulster.net>; Wed, 10 Nov 1999 19:36:55 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA17726 for linux-audio-dev-list; Wed, 10 Nov 1999 19:04:10 -0500
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA17723 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 10 Nov 1999 19:04:07 -0500
Received: from localhost.localdomain (d212-151-56-7.swipnet.se [212.151.56.7]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA14383; 
          Thu, 11 Nov 1999 00:59:15 +0100 (MET)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>
Subject: Re: [linux-audio-dev] Total latency measurement tool
Date: Thu, 11 Nov 1999 01:01:05 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <199911100621.BAA09859@renoir.op.net>
In-Reply-To: <199911100621.BAA09859@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99111101071301.04231@localhost.localdomain>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA13297
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 64893ed3a8c53d9838e0e54e6c6bfe68

On Wed, 10 Nov 1999, Paul Barton-Davis wrote:
> >I get 26 samples regardless of sample rate with the PCI128 and the
> >kernel driver. That is, all measurable latency seems to be in the
> >digital filters in the CODEC, and/or the driver + DMA.
> >
> >(I have a problem with ALSA and input, so I can't get reliable
> >results with it. Discovered that when running the audio input through
> >the "reverb" in my softsynth... The same full duplex code.)
> 
> what does reliable mean ? for example, is this "stable" ?
> 
> Delay: 61 samples
> Delay: 45 samples
> Delay: 49 samples
> Delay: 49 samples
> Delay: 73 samples
> Delay: 56 samples
> Delay: 72 samples
> Delay: 60 samples
> Delay: 72 samples
> Delay: 67 samples
> Delay: 76 samples
> Delay: 43 samples
> Delay: 69 samples
> Delay: 62 samples
> Delay: 80 samples
> Delay: 56 samples
> Delay: 57 samples
> Delay: 51 samples
> Delay: 48 samples
> Delay: 56 samples
> Delay: 63 samples
> Delay: 47 samples
> Delay: 56 samples
> Delay: 67 samples
> Delay: 43 samples
> Delay: 41 samples
> Delay: 56 samples
> Delay: 66 samples
> Delay: 57 samples
> Delay: 56 samples     

No, it should be +/- 1 sample worst case. You can get more jitter if
the feedback level is too low or too high, but what we see here looks
exactly like what I get.

Remove the code that analyzes the input and generates the output
signal, run some signal through it (no feedback), and I think you'll
hear the reason for the jitter...

> if not, its a bug in ALSA 0.5.0 (OSS emulation?) that needs to be fixed.

Don't know if it's my bug or in ALSA. The code works with the kernel
es1370 driver, and other full duplex code that works with ALSA's OSS
emulation.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Thu Nov 11 14:09:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA12945
	for <slinkp@ulster.net>; Wed, 10 Nov 1999 19:34:47 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA17748 for linux-audio-dev-list; Wed, 10 Nov 1999 19:07:41 -0500
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id TAA17745 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 10 Nov 1999 19:07:38 -0500
Message-Id: <199911110007.TAA17745@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] implementing EQ
To: est@hyperreal.org
Date: Wed, 10 Nov 1999 19:02:19 -0500 (EST)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
Cc: eli+@cs.cmu.edu, linux-audio-dev@ginette.musique.umontreal.ca
In-Reply-To: <19991110230612.3329.qmail@hyperreal.org> from "est@hyperreal.org" at Nov 10, 99 03:06:12 pm
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: fb64deae63f19a3ed0efbb70e7409021

est@hyperreal.org wrote:
> Hmm..how does the filter you showed coeficcients for compare to
> butterworth filters?  Also, I don't understand how using them in
> parallel can be avoided.

That code gives boost/cut filters, which have unity gain at DC and
Nyquist, and for example +6dB at 1 kHz.  It's because they're
unity-gain outside the target area that you can run them in series.
(I'm vague on what "Butterworth" means for a biquad, except that I
guess its Q would be 1/sqrt(2) or something.)

The formulas are from Robert Bristow-Johnson's article:
http://www.harmony-central.com/Effects/Articles/EQ_Coefficients/
which also has graphs of what these filters do.

Also, shelving filters, snarfed from a post of his to music-dsp:


    A = sqrt[ 10^(dBgain/20) ] = 10^(dBgain/40)

    omega = 2*PI*frequency/sample_rate

    cs = cos(omega)
    sn = sin(omega)

    Q = sn/[ ln(2)*bandwidth*omega ]    (if bandwidth is specified
        instead of Q)

    alpha = sn*sinh[ 1/(2*Q) ]

    beta = sqrt[ (A^2 + 1)/S - (A-1)^2 ]


lowShelf:       b0 =    A*[ (A+1) - (A-1)*cs + beta*sn ]
                b1 =  2*A*[ (A-1) - (A+1)*cs           ]
                b2 =    A*[ (A+1) - (A-1)*cs - beta*sn ]
                a0 =        (A+1) + (A-1)*cs + beta*sn
                a1 =   -2*[ (A-1) + (A+1)*cs           ]
                a2 =        (A+1) + (A-1)*cs - beta*sn


highShelf:      b0 =    A*[ (A+1) + (A-1)*cs + beta*sn ]
                b1 = -2*A*[ (A-1) + (A+1)*cs           ]
                b2 =    A*[ (A+1) + (A-1)*cs - beta*sn ]
                a0 =        (A+1) - (A-1)*cs + beta*sn
                a1 =    2*[ (A-1) - (A+1)*cs           ]
                a2 =        (A+1) - (A-1)*cs - beta*sn


-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Thu Nov 11 14:09:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA14518
	for <slinkp@ulster.net>; Wed, 10 Nov 1999 19:44:27 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA17769 for linux-audio-dev-list; Wed, 10 Nov 1999 19:14:46 -0500
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA17766 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 10 Nov 1999 19:14:42 -0500
Received: from localhost.localdomain (d212-151-56-7.swipnet.se [212.151.56.7]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA10978; 
          Thu, 11 Nov 1999 01:09:49 +0100 (MET)
From: David Olofson <audiality@swipnet.se>
To: Paul Barton-Davis <pbd@Op.Net>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Total latency measurement tool
Date: Thu, 11 Nov 1999 01:07:48 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199911100637.BAA10479@renoir.op.net>
In-Reply-To: <199911100637.BAA10479@renoir.op.net>
MIME-Version: 1.0
Message-Id: <99111101174802.04231@localhost.localdomain>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA14518
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5a5e4dc7159b6cd0963c704a160011b8

On Wed, 10 Nov 1999, Paul Barton-Davis wrote:
> david - can you explain why the input/output level should have such a
> pronounced effect on the test ? i understand the idea of a threshold
> for detection, but it seems that moving the input gain or pcm volume
> up and down can have quite a substantial impact on the numbers being
> displayed. this seems counter-intuitive to me. it could be a side
> effect of my current super-crappy-video card too.

It shouldn't have much effect at all. If the SNR gets too low, or the
signal clips, it will affect the result, but other than that, it's
not very sensitive. There's a peak level meter that scales the trig
level automatically.

> for my trident 4d-nx card, i can get stable readings of about 32
> samples (using ALSA-OSS-emulation) - makes sense given the PCI burst
> size, doesn't it ?

32 samples total...? What fragment size and # of fragments?

> for my tropez+ (ISA bus), the test doesn't seem to work: it complains
> about the level being too low, despite everything being turned all the
> way up.

Strange... Do you get any output, and does the program react if you
feed something else to the input? (It should trig on any transients,
and even twice every period of low frequency signals.)

> these numbers involve routing the signal through a samson 24 track
> analog mixer, but i can't imagine that this should affect them given
> the measurement being performed.

Well, if there's any measurable latency at all, it should at least be
*very* constant...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Thu Nov 11 14:28:24 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA09052
	for <slinkp@ulster.net>; Thu, 11 Nov 1999 14:17:03 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA23380 for linux-audio-dev-list; Thu, 11 Nov 1999 13:35:09 -0500
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA23377 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 11 Nov 1999 13:35:05 -0500
Received: from op.net (d-bm3-11.ppp.op.net [209.152.194.81]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id NAA22762 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 11 Nov 1999 13:30:17 -0500 (EST)
Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id NAA08428; Thu, 11 Nov 1999 13:31:31 -0500
Date: Thu, 11 Nov 1999 13:31:31 -0500
Message-Id: <199911111831.NAA08428@op.net>
From: Paul Barton-Davis <pbd@Op.Net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] (fwd) Athlon SMP availability
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: b7118f2fd62b9da774b8d8a9d3c86e70

i asked AMD about SMP support for the athlon. sigh.
---------------------------------------------------------
Date:    Thu, 11 Nov 1999 10:13:14 PST
To:      pbd@op.net
From:    "J.Taylor" <hwsupt9@brahms.amd.com>
Subject: Re: [Fwd: SMP motherboards - when?]
Reply-To: hwsupt9@brahms.amd.com

Hi Paul,

Since the Athlon processor is capable fo SMP, the limiting factor is the
availability of the chipset.  AMD along with a few other companies are
each currently working on chipsets that will support SMP.  As of right
now I do not have a date on when our chipset will be available.  All I
have at this time is that our chipset should be available some time next
year.  Hopefully this will happen in the first half of next year.  As
for the other companies (Hotrail, etc.), I don't know when their SMP
chipsets will be available.

Sorry I don't have any specifics, but it is all that I have at this
time.

Regards,
Jay

From - Sat Nov 13 13:17:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA27159
	for <slinkp@ulster.net>; Fri, 12 Nov 1999 12:26:22 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA29122 for linux-audio-dev-list; Fri, 12 Nov 1999 11:42:15 -0500
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA29119 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 12 Nov 1999 11:42:11 -0500
Received: from ulster.net (port93.ts2.ulster.net [208.242.164.93])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id LAA20911
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 12 Nov 1999 11:44:04 -0500
Message-ID: <382C4479.33B4D9B9@ulster.net>
Date: Fri, 12 Nov 1999 11:46:49 -0500
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] MIDI reset?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 11374c4ff358cb90fea463a8c4106e29

Hi,

I'm monkeying around with little python scripts that write to
/dev/midi
(I have a soundcard with a wavetable synth, and it's possible to
play it this way). (In fact, I have sometimes had some perverse fun
by doing cat "foo" > /dev/midi, where "foo" is anything -- a binary,
a soundfile, picture, core, etc...)

Trouble is, since I don't really know what I'm doing :), I
frequently get the soundcard "stuck"-- it won't respond to any more
midi commands, and
I can't even unload the driver (OSS-Linux 3.9.h-something-- running
"soundoff" just gives a bunch of "device or resource in use"
messages; likewise for trying to do rmmod by hand). This seems to
happen with a large number of note-ons without specific note-offs,
e.g. when doing fast percussion stuff.

I've tried writing a "reset" (first byte is 0xFF) to the soundcard,
but that doesn't seem to help. I'm not sure if anything is getting
through. The only solution at the moment is to reboot-- yuck.

Any ideas, anyone? I haven't used ALSA in a while -- is the midi
interface useable yet? Would ALSA have the same problem, or is it
more likely hardware?

BTW, here's an example of what I've been doing today-- trivial and
goofy, but fun:

import time
import whrandom
import struct

def drumbug(tempo, dur):
    s = 60.0 / tempo
    hits = dur / s
    possibles = range(0, 128)
    while hits > 0:
        note = whrandom.choice(possibles)
        vel = whrandom.choice(range(80, 128))
        ## print note, vel
	# I got using struct.pack this way from eric s. t.
        sys.stdout.write(struct.pack('BBB', 0x99, note, vel))
        sys.stdout.flush()
        time.sleep(s)
        hits = hits - 1

# end

-- PW

----------------     paul winkler     ------------------
slinkP arts:    music, sound, illustration, design, etc.
A member of ARMS:
www.reacharms.com - www.mp3.com/arms - www.amp3.com/arms
personal page: www.ulster.net/~abigoo

From - Sat Nov 13 13:17:35 1999
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA01201
	for <slinkp@ulster.net>; Fri, 12 Nov 1999 13:14:16 -0500
From: est@hyperreal.org
Received: (qmail 9908 invoked by uid 162); 12 Nov 1999 18:05:14 -0000
Message-ID: <19991112180514.9906.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] MIDI reset?
In-Reply-To: <382C4479.33B4D9B9@ulster.net> from Paul Winkler at "Nov 12, 1999
 11:46:49 am"
To: Paul Winkler <slinkp@ulster.net>
Date: Fri, 12 Nov 1999 10:05:14 -0800 (PST)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 28dd88f89d21d6c3af4ec30a7fe405da

Paul Winkler discourseth:
> 
> Trouble is, since I don't really know what I'm doing :), I
> frequently get the soundcard "stuck"-- it won't respond to any more
> midi commands, and
> I can't even unload the driver (OSS-Linux 3.9.h-something-- running
> "soundoff" just gives a bunch of "device or resource in use"
> messages; likewise for trying to do rmmod by hand). This seems to
> happen with a large number of note-ons without specific note-offs,
> e.g. when doing fast percussion stuff.

Have you tried adding note-offs?

> I've tried writing a "reset" (first byte is 0xFF) to the soundcard,
> but that doesn't seem to help. I'm not sure if anything is getting
> through. The only solution at the moment is to reboot-- yuck.

Yuck indeed.  There are some other messages you could try ("stop",
"all sound off", "all notes off"), but the standard is pretty
insistent that none of them is a substitute for note-offs.  Still,
they might be worth a try.

Eric

From - Sat Nov 13 13:17:36 1999
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id NAA01766
	for <slinkp@ulster.net>; Fri, 12 Nov 1999 13:18:50 -0500
Received: from someip.ppp.op.net (d-bm3-14.ppp.op.net [209.152.194.84]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id NAA04862; Fri, 12 Nov 1999 13:11:55 -0500 (EST)
Message-Id: <199911121811.NAA04862@renoir.op.net>
To: Paul Winkler <slinkp@ulster.net>
cc: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] MIDI reset? 
In-reply-to: Your message of "Fri, 12 Nov 1999 11:46:49 EST."
             <382C4479.33B4D9B9@ulster.net> 
Date: Fri, 12 Nov 1999 13:13:23 -0500
From: Paul Barton-Davis <pbd@Op.Net>
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: f94ba7ccfea63d6c3ca255e87101310b

>Any ideas, anyone? I haven't used ALSA in a while -- is the midi
>interface useable yet? Would ALSA have the same problem, or is it
>more likely hardware?

in your case, you're not actually using raw MIDI output on its own:
you're using a device driver that attempts to parse MIDI data and turn
it into commands to control the wavetable synth. i don't believe that
the OSS code to do this is particularly robust in the face of bizarre
sequences of MIDI data. OTOH, neither is the implementation of the
same functionality on my Oberheim Matrix 6, or my Kawai K5000S or my
retrofitted Prophet 5. So OSS is not entirely alone in this.

if you were just using the raw ALSA MIDI code is not only usable, its
faster than OSS and supports a nice library interface in alsa-lib if
you wanted to get stats from the port. most code that works for OSS
raw midi will work without any changes if you just direct it to the
relevant MIDI port, which if you use ALSA with OSS emulation, is no
change at all :)

however, you aren't using raw MIDI per se, but require a wavetable
synth driver that can convert MIDI data and drive the soundcard
hardware. i don't think that many of these ("sequencer kernel
clients") have been written yet.

--p

From - Sat Nov 13 18:27:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA08088
	for <slinkp@ulster.net>; Sat, 13 Nov 1999 18:24:46 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA03646 for linux-audio-dev-list; Sat, 13 Nov 1999 17:35:24 -0500
Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA03643 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 13 Nov 1999 17:35:09 -0500
Received: from d1o43.telia.com (d1o43.telia.com [194.22.195.241])
	by mailg.telia.com (8.9.3/8.9.3) with ESMTP id XAA24771
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 13 Nov 1999 23:04:05 +0100 (CET)
Received: from norran.net (roger@t8o43p58.telia.com [194.237.168.238])
	by d1o43.telia.com (8.8.8/8.8.8) with ESMTP id XAA04108
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 13 Nov 1999 23:04:03 +0100 (CET)
Message-ID: <382DE98D.3C1F2E15@norran.net>
Date: Sat, 13 Nov 1999 23:43:26 +0100
From: Roger Larsson <roger.larsson@norran.net>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] [PATCH] latency-profiling-2.2.13-r7
References: <199911121811.NAA04862@renoir.op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 589f049598ac1ecce20483570aa15f3d

Hi all,

Since Ingo Molnar has released a 2.2.13 version of his
lowlatency patch.
  http://www.redhat.com/~mingo/lowlatency-2.2.13-A1
  (Note: fails on tty_io.c ...)


I decided to make a new release myself. I will place
further releases and info of this patch on:
   http://www.norran.net/nra02596/

(Benno can you make a link from your lowlatency page?)

This patch should be easy to move to any other kernel.

/RogerL

From - Sun Nov 14 17:52:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id FAA19708
	for <slinkp@ulster.net>; Sun, 14 Nov 1999 05:46:48 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA08184 for linux-audio-dev-list; Sun, 14 Nov 1999 05:19:23 -0500
Received: from sculpcave (adm-3.wakkanet.fi [194.157.35.121]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA08181 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 14 Nov 1999 05:19:17 -0500
Received: from localhost (localhost [127.0.0.1])
	by sculpcave (Postfix) with ESMTP
	id A626B34D7A; Sun, 14 Nov 1999 04:59:45 +0200 (EET)
Date: Sun, 14 Nov 1999 04:59:44 +0200 (EET)
From: Kai Vehmanen <kaiv@wakkanet.fi>
X-Sender: root@sculpcave.localdomain
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Creative and open-source
Message-ID: <Pine.LNX.4.10.9911140449270.11089-100000@sculpcave.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: df70d6676f4b65f37a18c70f34af8c49

Whoa! Just saw a news item about "Creative going open-source" on 
Harmony Central's front page! I've been visiting Harmony Central 
for years and this is the first time they mention anything 
about open-source. Creative just might have brought more publicity 
to Linux/open-source audio world than we expected, or at least more
than I expected. Oh well, I still want get rid of my AWE64. ;)
HC's pages are at http://www.harmony-central.com/ ...

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav
 . http://www.wakkanet.fi/kerttulin_listat/ - music&movies (in Finnish)

From - Sun Nov 14 17:52:43 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id FAA19756
	for <slinkp@ulster.net>; Sun, 14 Nov 1999 05:48:39 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA08193 for linux-audio-dev-list; Sun, 14 Nov 1999 05:27:59 -0500
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA08190 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 14 Nov 1999 05:27:56 -0500
Received: from ulster.net (port245.ts2.ulster.net [208.242.164.245])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id FAA19189;
	Sun, 14 Nov 1999 05:30:00 -0500
Message-ID: <382E8FC5.7D64ABDD@ulster.net>
Date: Sun, 14 Nov 1999 05:32:37 -0500
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: est@hyperreal.org
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MIDI reset?
References: <19991112180514.9906.qmail@hyperreal.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: fc01099cb8b58473ba0bf437723b52d1

est@hyperreal.org wrote:

> Have you tried adding note-offs?

Yes, doesn't seem to help.
Am I correct in understanding that a note-off looks just like a
note-on, except you subtract 16 from the channel number? (e.g. 0x99
becomes 0x89)

> 
> > I've tried writing a "reset" (first byte is 0xFF) to the soundcard,
> > but that doesn't seem to help. I'm not sure if anything is getting
> > through. The only solution at the moment is to reboot-- yuck.
> 
> Yuck indeed.  There are some other messages you could try ("stop",
> "all sound off", "all notes off"), but the standard is pretty
> insistent that none of them is a substitute for note-offs.  Still,
> they might be worth a try.

Hm, I'll have a look at the midi spec and see what those are...
thanks.

-PW
 
> Eric

-- 
................    paul winkler    ..................
slinkP arts:   music, sound, illustration, design, etc.
A member of ARMS    ----->    http://www.reacharms.com
or http://www.mp3.com/arms or http://www.amp3.com/arms
personal page   ---->    http://www.ulster.net/~abigoo

From - Sun Nov 14 17:52:44 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id FAA19819
	for <slinkp@ulster.net>; Sun, 14 Nov 1999 05:50:05 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA08204 for linux-audio-dev-list; Sun, 14 Nov 1999 05:29:40 -0500
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA08200 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 14 Nov 1999 05:29:36 -0500
Received: from ulster.net (port245.ts2.ulster.net [208.242.164.245])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id FAA19238;
	Sun, 14 Nov 1999 05:31:37 -0500
Message-ID: <382E9027.A84651D8@ulster.net>
Date: Sun, 14 Nov 1999 05:34:15 -0500
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Barton-Davis <pbd@Op.Net>
CC: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] MIDI reset?
References: <199911121811.NAA04862@renoir.op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 90f58d6817662c0e11944aa156457c07

Paul Barton-Davis wrote:
> however, you aren't using raw MIDI per se, but require a wavetable
> synth driver that can convert MIDI data and drive the soundcard
> hardware. i don't think that many of these ("sequencer kernel
> clients") have been written yet.

I think you're right -- I just had another look at Alsa website, and
it looks like very few cards have internal synth support... not the
malibu.
-- 
................    paul winkler    ..................
slinkP arts:   music, sound, illustration, design, etc.
A member of ARMS    ----->    http://www.reacharms.com
or http://www.mp3.com/arms or http://www.amp3.com/arms
personal page   ---->    http://www.ulster.net/~abigoo

From - Sun Nov 14 17:52:38 1999
Received: from gate.suse.cz (perex@perex.cb.cesnet.cz [194.212.165.105])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id FAA19601
	for <slinkp@ulster.net>; Sun, 14 Nov 1999 05:43:08 -0500
Received: from localhost (perex@localhost)
	by gate.suse.cz (8.8.8/8.8.8) with ESMTP id MAA31930;
	Sun, 14 Nov 1999 12:27:48 +0100
X-Authentication-Warning: gate.suse.cz: perex owned process doing -bs
Date: Sun, 14 Nov 1999 12:27:48 +0100 (MET)
From: Jaroslav Kysela <perex@suse.cz>
To: Paul Winkler <slinkp@ulster.net>
cc: Paul Barton-Davis <pbd@Op.Net>,
        "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] MIDI reset?
In-Reply-To: <382E9027.A84651D8@ulster.net>
Message-ID: <Pine.LNX.4.05.9911141226100.31774-100000@gate.suse.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: ee9adfe1df2bb4f8a5e5b06b3c2b8a55

On Sun, 14 Nov 1999, Paul Winkler wrote:

> Paul Barton-Davis wrote:
> > however, you aren't using raw MIDI per se, but require a wavetable
> > synth driver that can convert MIDI data and drive the soundcard
> > hardware. i don't think that many of these ("sequencer kernel
> > clients") have been written yet.
> 
> I think you're right -- I just had another look at Alsa website, and
> it looks like very few cards have internal synth support... not the
> malibu.

Malibu seems to have the internal synthesizer connected to the MPU401
port, but I don't know, how to initialize this connection :-((
If you get specs from Turtle Beach, I'll enable it..

							Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA project  http://www.alsa-project.org

From - Sun Nov 14 17:52:48 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA18019
	for <slinkp@ulster.net>; Sun, 14 Nov 1999 11:15:02 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA08435 for linux-audio-dev-list; Sun, 14 Nov 1999 10:06:18 -0500
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA08432 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 14 Nov 1999 10:06:10 -0500
Received: from op.net (d-bm2-18.ppp.op.net [209.152.194.56]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id KAA21119 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 14 Nov 1999 10:01:22 -0500 (EST)
Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id KAA01529; Sun, 14 Nov 1999 10:02:12 -0500
Date: Sun, 14 Nov 1999 10:02:12 -0500
Message-Id: <199911141502.KAA01529@op.net>
From: Paul Barton-Davis <pbd@Op.Net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] hyper shamanic loop constructing
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 7e7e6ac37198a6338190165363c794ff

does anyone know of any (linux) programs that can be used for
real-time loop creation ? i'm thinking of something like the old jam
man hardware, which came with a foot switch - you clicked it, then
recorded up to 30 secs of sound, then clicked it again, and if you
then did some other click or something, it would start looping what
you just recorded

clearly, this is heading toward acid territory, but for now, i would
like to be able to just do the loop real time loop creation. it seems
like a simple program to write, so if nobody has a lead to follow, off
i go again ...

--p

From - Sun Nov 14 17:52:46 1999
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id KAA12513
	for <slinkp@ulster.net>; Sun, 14 Nov 1999 10:15:39 -0500
Received: from someip.ppp.op.net (d-bm2-18.ppp.op.net [209.152.194.56]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id KAA21464 for <slinkp@ulster.net>; Sun, 14 Nov 1999 10:08:37 -0500 (EST)
Message-Id: <199911141508.KAA21464@renoir.op.net>
To: Paul Winkler <slinkp@ulster.net>
Subject: Re: [linux-audio-dev] MIDI reset? 
In-reply-to: Your message of "Sun, 14 Nov 1999 05:32:37 EST."
             <382E8FC5.7D64ABDD@ulster.net> 
Date: Sun, 14 Nov 1999 10:09:28 -0500
From: Paul Barton-Davis <pbd@Op.Net>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 079608cb42180ce499789b6e0dd8710a

>Am I correct in understanding that a note-off looks just like a
>note-on, except you subtract 16 from the channel number? (e.g. 0x99
>becomes 0x89)

it might look like that, but thats how it works at all. note on and
note off are both 3 byte messages. the first one encodes the channel
and the msg type, 0x80 being note off and 0x90 being note on. the two
values are OR-ed together, so for channel 9 (based at zero), you see
0x89 for a note off, 0x99 for a note on.

note: many MIDI implementations also use a note on with velocity = 0
as a note off, which is allowed in the MIDI spec.

From - Sun Nov 14 17:52:51 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA23598
	for <slinkp@ulster.net>; Sun, 14 Nov 1999 12:12:59 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA08538 for linux-audio-dev-list; Sun, 14 Nov 1999 11:41:28 -0500
Received: from hme0.smtp04.sprint.ca (hme0.smtp04.sprint.ca [207.107.250.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA08535 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 14 Nov 1999 11:41:25 -0500
Received: from vektor.div8.net (root@spc-isp-ktc-uas-07-94.sprint.ca [209.148.133.41])
	by hme0.smtp04.sprint.ca (8.8.8/8.8.8) with ESMTP id LAA00822;
	Sun, 14 Nov 1999 11:36:35 -0500 (EST)
Received: from localhost by div8.net
	via sendmail with smtp
	id <m11n2gN-00094qC@vektor.div8.net> (Debian Smail3.2.0.102)
	for <pbd@Op.Net>; Sun, 14 Nov 1999 11:39:15 -0500 (EST) 
Date: Sun, 14 Nov 1999 11:39:15 -0500 (EST)
From: Billy Biggs <vektor@DIV8.NET>
To: Paul Barton-Davis <pbd@Op.Net>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] hyper shamanic loop constructing
In-Reply-To: <199911141502.KAA01529@op.net>
Message-ID: <Pine.LNX.3.96.991114113653.29971A-100000@vektor.div8.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 97ae26474e4343e1a2b1bf2af257a5d4

> clearly, this is heading toward acid territory, but for now, i would
> like to be able to just do the loop real time loop creation. it seems
> like a simple program to write, so if nobody has a lead to follow, off
> i go again ...

  You can take a look at thud, http://www.div8.net/thud.  The web page is
getting very stale, and I still haven't released the new version (with
lots of fixes), but it's the beginnings of what you're looking for.

  Like, it says it's a drum machine, but really the point is to make a
loop (usually a drum loop, but whatever), and export it to WAV file.  ttrk
is my sequencer which is also supposed to be an ACID clone.  At least,
that's the final intent.

  You want to see record functions, obviously, but what other sort of
features do you see important in a 'hyper shamanic loop construction' kit?

--
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

From - Sun Nov 14 17:52:52 1999
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA26698
	for <slinkp@ulster.net>; Sun, 14 Nov 1999 12:43:38 -0500
From: est@hyperreal.org
Received: (qmail 791 invoked by uid 162); 14 Nov 1999 17:36:36 -0000
Message-ID: <19991114173636.790.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] MIDI reset?
In-Reply-To: <382E8FC5.7D64ABDD@ulster.net> from Paul Winkler at "Nov 14, 1999
 05:32:37 am"
To: Paul Winkler <slinkp@ulster.net>
Date: Sun, 14 Nov 1999 09:36:36 -0800 (PST)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f39c818ff196ade4f161ce814fa079b0

Paul Winkler discourseth:
> 
> Am I correct in understanding that a note-off looks just like a
> note-on, except you subtract 16 from the channel number? (e.g. 0x99
> becomes 0x89)

Yup.

> > Yuck indeed.  There are some other messages you could try ("stop",
> > "all sound off", "all notes off"), but the standard is pretty
> > insistent that none of them is a substitute for note-offs.  Still,
> > they might be worth a try.
> 
> Hm, I'll have a look at the midi spec and see what those are...
> thanks.

stop = 0xFC
all sound off = 0xB0 | basic_channel, 120
all notes off = 0xB0 | basic_channel, 123

Where basic_channel is the `instrument's `basic channel'. :)

Eric

From - Sun Nov 14 17:52:55 1999
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id PAA11624
	for <slinkp@ulster.net>; Sun, 14 Nov 1999 15:42:58 -0500
Received: from bright.net (find-cas1-cs-37.dial.bright.net [209.143.26.140])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id PAA01141;
	Sun, 14 Nov 1999 15:35:27 -0500 (EST)
Sender: root@sparticus.bright.net
Message-ID: <382F2242.160B933C@bright.net>
Date: Sun, 14 Nov 1999 15:57:38 -0500
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: est@hyperreal.org
CC: Paul Winkler <slinkp@ulster.net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MIDI reset?
References: <19991114173636.790.qmail@hyperreal.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 833cc3e207bcec295083947d0f4c6c5c

est@hyperreal.org wrote:

> > Am I correct in understanding that a note-off looks just like a
> > note-on, except you subtract 16 from the channel number? (e.g. 0x99
> > becomes 0x89)
> 
> Yup.
> 
> > > Yuck indeed.  There are some other messages you could try ("stop",
> > > "all sound off", "all notes off"), but the standard is pretty
> > > insistent that none of them is a substitute for note-offs.  Still,
> > > they might be worth a try.

Just curious here. Wasn't/Isn't it also a widespread practice that a
MIDI note-on with a velocity of 0 was/is used to terminate a note-on ?

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
       http://www.bright.net/~dlphilp/linuxsound/

From - Sun Nov 14 18:42:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA29798
	for <slinkp@ulster.net>; Sun, 14 Nov 1999 18:34:27 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA08950 for linux-audio-dev-list; Sun, 14 Nov 1999 18:10:31 -0500
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA08947 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 14 Nov 1999 18:10:27 -0500
Received: from bright.net (find-cas1-cs-37.dial.bright.net [209.143.26.140])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id PAA01141;
	Sun, 14 Nov 1999 15:35:27 -0500 (EST)
Message-ID: <382F2242.160B933C@bright.net>
Date: Sun, 14 Nov 1999 15:57:38 -0500
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: est@hyperreal.org
CC: Paul Winkler <slinkp@ulster.net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MIDI reset?
References: <19991114173636.790.qmail@hyperreal.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f12df77aee299fb72e5e053fe5854da3

est@hyperreal.org wrote:

> > Am I correct in understanding that a note-off looks just like a
> > note-on, except you subtract 16 from the channel number? (e.g. 0x99
> > becomes 0x89)
> 
> Yup.
> 
> > > Yuck indeed.  There are some other messages you could try ("stop",
> > > "all sound off", "all notes off"), but the standard is pretty
> > > insistent that none of them is a substitute for note-offs.  Still,
> > > they might be worth a try.

Just curious here. Wasn't/Isn't it also a widespread practice that a
MIDI note-on with a velocity of 0 was/is used to terminate a note-on ?

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
       http://www.bright.net/~dlphilp/linuxsound/

From - Sun Nov 14 18:32:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA28863
	for <slinkp@ulster.net>; Sun, 14 Nov 1999 18:26:21 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA08910 for linux-audio-dev-list; Sun, 14 Nov 1999 17:59:59 -0500
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id RAA08907 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 14 Nov 1999 17:59:55 -0500
From: est@hyperreal.org
Received: (qmail 1101 invoked by uid 162); 14 Nov 1999 21:08:28 -0000
Message-ID: <19991114210828.1100.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] MIDI reset?
In-Reply-To: <382F2242.160B933C@bright.net> from Dave Phillips at "Nov 14, 1999
 03:57:38 pm"
To: Dave Phillips <dlphilp@bright.net>
Date: Sun, 14 Nov 1999 13:08:28 -0800 (PST)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 70ea01574cb685fadf9820e692587be2

Dave Phillips discourseth:
> 
> Just curious here. Wasn't/Isn't it also a widespread practice that a
> MIDI note-on with a velocity of 0 was/is used to terminate a note-on ?

More than that..it's synonymous (according to the standard) to a
note-off with release velocity 64.  Running status often makes it
shorter too.

Eric

From - Sun Nov 14 18:22:31 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA28013
	for <slinkp@ulster.net>; Sun, 14 Nov 1999 18:18:57 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA08898 for linux-audio-dev-list; Sun, 14 Nov 1999 17:51:51 -0500
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA08895 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 14 Nov 1999 17:51:48 -0500
Received: from bright.net (find-cas1-cs-44.dial.bright.net [209.143.26.147])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id QAA00986;
	Sun, 14 Nov 1999 16:25:36 -0500 (EST)
Message-ID: <382F2E03.9B87EB62@bright.net>
Date: Sun, 14 Nov 1999 16:47:47 -0500
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: est@hyperreal.org
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MIDI reset?
References: <19991114210828.1100.qmail@hyperreal.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f00bf4debb9b835c393eab420b01da01

est@hyperreal.org wrote:

> > Just curious here. Wasn't/Isn't it also a widespread practice that a
> > MIDI note-on with a velocity of 0 was/is used to terminate a note-on ?
> 
> More than that..it's synonymous (according to the standard) to a
> note-off with release velocity 64.  Running status often makes it
> shorter too.

I think that very few synths in the 80s recognized note-off. Do any
current MIDI synths recognize it ?

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
       http://www.bright.net/~dlphilp/linuxsound/

From - Sun Nov 14 19:32:34 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA03471
	for <slinkp@ulster.net>; Sun, 14 Nov 1999 19:25:10 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA09012 for linux-audio-dev-list; Sun, 14 Nov 1999 18:58:51 -0500
Received: from hme0.smtp04.sprint.ca (hme0.smtp04.sprint.ca [207.107.250.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA09009 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 14 Nov 1999 18:58:48 -0500
Received: from vektor.div8.net (root@spc-isp-ktc-uas-07-18.sprint.ca [209.148.132.219])
	by hme0.smtp04.sprint.ca (8.8.8/8.8.8) with ESMTP id SAA27159;
	Sun, 14 Nov 1999 18:53:55 -0500 (EST)
Received: from localhost by div8.net
	via sendmail with smtp
	id <m11n9Vc-00094mC@vektor.div8.net> (Debian Smail3.2.0.102)
	for <dlphilp@bright.net>; Sun, 14 Nov 1999 18:56:36 -0500 (EST) 
Date: Sun, 14 Nov 1999 18:56:35 -0500 (EST)
From: Billy Biggs <vektor@DIV8.NET>
To: Dave Phillips <dlphilp@bright.net>
cc: est@hyperreal.org, linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MIDI reset?
In-Reply-To: <382F2E03.9B87EB62@bright.net>
Message-ID: <Pine.LNX.3.96.991114185503.3671A-100000@vektor.div8.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f26ace4952553ae35b7a75accfa63004

On Sun, 14 Nov 1999, Dave Phillips wrote:

> est@hyperreal.org wrote:
> > 
> > More than that..it's synonymous (according to the standard) to a
> > note-off with release velocity 64.  Running status often makes it
> > shorter too.
> 
> I think that very few synths in the 80s recognized note-off. Do any
> current MIDI synths recognize it ?

  My sequencer sends out note-offs just fine to all my gear, the oldest
being a DX7.  Seems to work fine.

  Should I rather be sending the ugly 0-velocity note-on?

--
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

From - Sun Nov 14 21:41:15 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA05557
	for <slinkp@ulster.net>; Sun, 14 Nov 1999 19:43:06 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA09051 for linux-audio-dev-list; Sun, 14 Nov 1999 19:19:16 -0500
Received: from hme0.smtp04.sprint.ca (hme0.smtp04.sprint.ca [207.107.250.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA09048 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 14 Nov 1999 19:19:13 -0500
Received: from vektor.div8.net (root@spc-isp-ktc-uas-07-18.sprint.ca [209.148.132.219])
	by hme0.smtp04.sprint.ca (8.8.8/8.8.8) with ESMTP id TAA22055;
	Sun, 14 Nov 1999 19:14:24 -0500 (EST)
Received: from localhost by div8.net
	via sendmail with smtp
	id <m11n9pR-00094mC@vektor.div8.net> (Debian Smail3.2.0.102)
	for <dlphilp@bright.net>; Sun, 14 Nov 1999 19:17:05 -0500 (EST) 
Date: Sun, 14 Nov 1999 19:17:05 -0500 (EST)
From: Billy Biggs <vektor@DIV8.NET>
To: Dave Phillips <dlphilp@bright.net>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MIDI reset?
In-Reply-To: <382F53DD.A14579E0@bright.net>
Message-ID: <Pine.LNX.3.96.991114191600.3700B-100000@vektor.div8.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d3177394da26a6130d522a4040599c62

On Sun, 14 Nov 1999, Dave Phillips wrote:

> > Should I rather be sending the ugly 0-velocity note-on?
> 
> Sorry, sorry: I should have written "note-off velocity". I think all
> synths recognize the note-off event, but ignore the velocity value.

  Ok, that makes _alot_ more sense.  :)  I thought there might be some
strange MIDI quirk I'd never known about.

  I always send 0 for a note-off velocity, and stuff seems to work ok.

--
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

From - Sun Nov 14 21:41:13 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA05532
	for <slinkp@ulster.net>; Sun, 14 Nov 1999 19:42:55 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA09057 for linux-audio-dev-list; Sun, 14 Nov 1999 19:20:00 -0500
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA09054 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 14 Nov 1999 19:19:57 -0500
Received: from angelfire.com (port145.ts2.ulster.net [208.242.164.145])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id TAA03115
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 14 Nov 1999 19:22:01 -0500
Message-ID: <382F52BB.3ED3928B@angelfire.com>
Date: Sun, 14 Nov 1999 19:24:27 -0500
From: Paul Winkler <slinkp@angelfire.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] MIDI reset?
References: <19991112180514.9906.qmail@hyperreal.org> <382E8FC5.7D64ABDD@ulster.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e839b4ca319318238a5af95c714d36d1

I wrote:
> 
> est@hyperreal.org wrote:
> 
> > Have you tried adding note-offs?
> 
> Yes, doesn't seem to help.

Duh, I forgot to flush the output after the note-offs.
Seems good now! haven't hung the driver for a while now.
Thanks!!
- 
................    paul winkler    ..................
slinkP arts:   music, sound, illustration, design, etc.
A member of ARMS    ----->    http://www.reacharms.com
or http://www.mp3.com/arms or http://www.amp3.com/arms
personal page   ---->    http://www.ulster.net/~abigoo

From - Sun Nov 14 19:42:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA04665
	for <slinkp@ulster.net>; Sun, 14 Nov 1999 19:35:27 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA09033 for linux-audio-dev-list; Sun, 14 Nov 1999 19:12:05 -0500
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA09030 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 14 Nov 1999 19:12:02 -0500
Received: from bright.net (find-cas1-cs-17.dial.bright.net [209.143.26.120])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id TAA19125;
	Sun, 14 Nov 1999 19:07:04 -0500 (EST)
Message-ID: <382F53DD.A14579E0@bright.net>
Date: Sun, 14 Nov 1999 19:29:17 -0500
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Billy Biggs <vektor@DIV8.NET>
CC: est@hyperreal.org, linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] MIDI reset?
References: <Pine.LNX.3.96.991114185503.3671A-100000@vektor.div8.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 9a06ffd1777fb6f5b66f6b6ea4584104

Billy Biggs wrote:

> My sequencer sends out note-offs just fine to all my gear, the oldest
> being a DX7.  Seems to work fine.
> 
> Should I rather be sending the ugly 0-velocity note-on?

Sorry, sorry: I should have written "note-off velocity". I think all
synths recognize the note-off event, but ignore the velocity value.

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
       http://www.bright.net/~dlphilp/linuxsound/

From - Sun Nov 14 21:41:16 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA08048
	for <slinkp@ulster.net>; Sun, 14 Nov 1999 20:04:06 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA09116 for linux-audio-dev-list; Sun, 14 Nov 1999 19:38:51 -0500
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA09113 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 14 Nov 1999 19:38:48 -0500
Received: from angelfire.com (port145.ts2.ulster.net [208.242.164.145])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id TAA05306;
	Sun, 14 Nov 1999 19:40:54 -0500
Message-ID: <382F5724.B3BA9075@angelfire.com>
Date: Sun, 14 Nov 1999 19:43:16 -0500
From: Paul Winkler <slinkp@angelfire.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jaroslav Kysela <perex@suse.cz>
CC: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] MIDI reset?
References: <Pine.LNX.4.05.9911141226100.31774-100000@gate.suse.cz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 3ced23e0bc974b229ca02257baf11cd2

Jaroslav Kysela wrote:

> Malibu seems to have the internal synthesizer connected to the MPU401
> port, but I don't know, how to initialize this connection :-((
> If you get specs from Turtle Beach, I'll enable it..

I've just written to them... we'll see if they bite.
If not, maybe I'll resort to scare tactics -- tell them they are
going to lose sales to Trident, SBLive, etc. Maybe that'll work. :)

................    paul winkler    ..................
slinkP arts:   music, sound, illustration, design, etc.
A member of ARMS    ----->    http://www.reacharms.com
or http://www.mp3.com/arms or http://www.amp3.com/arms
personal page   ---->    http://www.ulster.net/~abigoo

From - Tue Nov 16 03:08:02 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA06742
	for <slinkp@ulster.net>; Mon, 15 Nov 1999 13:02:55 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA14345 for linux-audio-dev-list; Mon, 15 Nov 1999 12:03:33 -0500
Received: from upf.es (newton.upf.es [193.145.54.60]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA14342 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 15 Nov 1999 12:03:11 -0500
Received: from mtg150.upf.es (mtg150.upf.es [193.145.44.150])
	by upf.es (8.9.0/8.9.0) with SMTP id RAA17057;
	Mon, 15 Nov 1999 17:58:05 +0100 (MET)
From: maarten de boer <maarten.deboer@iua.upf.es>
Reply-To: maarten.deboer@iua.upf.es
Organization: IUA
To: pbd@Op.Net, linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] hyper shamanic loop constructing
Date: Mon, 15 Nov 1999 17:55:00 +0100
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <199911141502.KAA01529@op.net>
MIME-Version: 1.0
Message-Id: <99111518072204.01959@mtg150.upf.es>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 054a4a1cabdcbcf92fde6c15750dee9d

Hi,

> does anyone know of any (linux) programs that can be used for
> real-time loop creation ? [...]

We're talking frippertronics here!

You might want to have a look at a program I wrote, called tapiir,

http://www.things.nl/~maarten/fltk/tapiir

It is actually a multi tap delay, but with a little bit of tweaking
- it actually is a planned feature - it can do the task you mentioned, 
6 times even and with optional cross talking between the loops.
The thing would be to set or mute the left/right input volumes when
a footswitch is pressed. Ideal would be a footswitch with 6 switches
(plenty of these around). Or just put your midi-keyboard on the floor
:-)
It is very easy to add the needed code: in the synthesis thread, just
do a non-blocking read of the midi device (or even better, add an 
extra thread), and set the apropriate gains (yes, the code needs soms
comments+docu... but if you look at the gui code, you will surely see
what values I mean.) Updating the sliders would require some flag that
the GUI thread checks.

I actually plan full control of all the parameters through midi, so
it can be controlled by a sequencer, but I think for now you can
get what you want quickly and easily. 

Let me know what you think of tapiir, and please send me any modifications
you make!

Maarten



From - Tue Nov 16 03:08:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA10169
	for <slinkp@ulster.net>; Mon, 15 Nov 1999 13:25:35 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA14391 for linux-audio-dev-list; Mon, 15 Nov 1999 12:33:34 -0500
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA14388 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 15 Nov 1999 12:33:30 -0500
Received: from someip.ppp.op.net (d-bm2-09.ppp.op.net [209.152.194.41]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id MAA22494; Mon, 15 Nov 1999 12:27:48 -0500 (EST)
Message-Id: <199911151727.MAA22494@renoir.op.net>
To: maarten.deboer@iua.upf.es
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] hyper shamanic loop constructing 
In-reply-to: Your message of "Mon, 15 Nov 1999 17:55:00 +0100."
             <99111518072204.01959@mtg150.upf.es> 
Date: Mon, 15 Nov 1999 12:28:54 -0500
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b71ddc1e8fcaf3f67a8de73533474b31

thanks for the link.

someone else asked me why i didn't just write it as a module for
quasimodo. they were right. its working today :) this way, i get to
plug it into all the other goodies we have there (noise gates, delay
units, etc.)

--p

ps. the module was already named "Fripp" before i got your mail :)

From - Tue Nov 16 03:08:11 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA04594
	for <slinkp@ulster.net>; Mon, 15 Nov 1999 23:04:06 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA15349 for linux-audio-dev-list; Mon, 15 Nov 1999 22:31:18 -0500
Received: from hme0.smtp04.sprint.ca (hme0.smtp04.sprint.ca [207.107.250.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA15346 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 15 Nov 1999 22:31:14 -0500
Received: from vektor.div8.net (root@spc-isp-ktc-uas-04-31.sprint.ca [209.103.20.182])
	by hme0.smtp04.sprint.ca (8.8.8/8.8.8) with ESMTP id WAA00908
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 15 Nov 1999 22:26:25 -0500 (EST)
Received: from localhost by div8.net
	via sendmail with smtp
	id <m11nZIq-00094mC@vektor.div8.net> (Debian Smail3.2.0.102)
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 15 Nov 1999 22:29:08 -0500 (EST) 
Date: Mon, 15 Nov 1999 22:29:07 -0500 (EST)
From: Billy Biggs <vektor@DIV8.NET>
To: Linux Audio Dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] O_NONBLOCK in OSS
Message-ID: <Pine.LNX.3.96.991115222428.5532A-100000@vektor.div8.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: cb6efb71c3b6b5a2d703e9d28b1a3db8

Hey,

  I'm having an extremely annoying problem.  I just re-wrote my dspout
class, and it's exhibiting some strange behavior I haven't seen before.

  Simple audio app, nothing fancy, outputing some data to the dsp device.
es1370 card running on 2.2.7.

  If I open the device O_NONBLOCK, my app skips alot, with lots of 
annoying clicks happening every buffer.  Shortening the buffer size
increases the annoying click factor.

  If I remove O_NONBLOCK from the open call, the app doesn't skip at all,
and sounds perfect.

  Is this expected behavior?  I do NOT like apps blocking when, say, my
mp3 player is running.  I'd like to know how to get my app to work when
it's in O_NONBLOCK mode.  This doesn't seem to make much sense to me at
all.

  Advice?  And quick, I want to release this app tonight! ;-)

--
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

From - Tue Nov 16 03:08:16 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id CAA22649
	for <slinkp@ulster.net>; Tue, 16 Nov 1999 02:31:42 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA15428 for linux-audio-dev-list; Mon, 15 Nov 1999 23:42:24 -0500
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA15425 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 15 Nov 1999 23:42:20 -0500
Received: from someip.ppp.op.net (d-bm3-02.ppp.op.net [209.152.194.66]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id XAA29559; Mon, 15 Nov 1999 23:37:19 -0500 (EST)
Message-Id: <199911160437.XAA29559@renoir.op.net>
To: Billy Biggs <vektor@DIV8.NET>
cc: Linux Audio Dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] O_NONBLOCK in OSS 
In-reply-to: Your message of "Mon, 15 Nov 1999 22:29:07 EST."
             <Pine.LNX.3.96.991115222428.5532A-100000@vektor.div8.net> 
Date: Mon, 15 Nov 1999 23:38:08 -0500
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1f153e8f6f20eff903e16f0a43f98dd4

>  If I open the device O_NONBLOCK, my app skips alot, with lots of 
>annoying clicks happening every buffer.  Shortening the buffer size
>increases the annoying click factor.
>
>  If I remove O_NONBLOCK from the open call, the app doesn't skip at all,
>and sounds perfect.
>
>  Is this expected behavior?  I do NOT like apps blocking when, say, my
>mp3 player is running.  I'd like to know how to get my app to work when
>it's in O_NONBLOCK mode.  This doesn't seem to make much sense to me at
>all.
>
>  Advice?  And quick, I want to release this app tonight! ;-)

for quickest service: send me your code. are you doing things
differently in non-blocking mode ? i *hope* so - doing the same thing
will indicate to the driver that you don't care if your write failed
because there wasn't enough space in the h/w buffer.

--p

From - Tue Nov 16 03:08:12 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA19051
	for <slinkp@ulster.net>; Tue, 16 Nov 1999 01:25:41 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA15489 for linux-audio-dev-list; Tue, 16 Nov 1999 00:20:01 -0500
Received: from hme0.smtp04.sprint.ca (hme0.smtp04.sprint.ca [207.107.250.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA15486 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 16 Nov 1999 00:19:58 -0500
Received: from vektor.div8.net (root@spc-isp-ktc-uas-06-41.sprint.ca [209.103.18.242])
	by hme0.smtp04.sprint.ca (8.8.8/8.8.8) with ESMTP id AAA07015;
	Tue, 16 Nov 1999 00:15:07 -0500 (EST)
Received: from localhost by div8.net
	via sendmail with smtp
	id <m11nb08-00094mC@vektor.div8.net> (Debian Smail3.2.0.102)
	for <pbd@Op.Net>; Tue, 16 Nov 1999 00:17:56 -0500 (EST) 
Date: Tue, 16 Nov 1999 00:17:56 -0500 (EST)
From: Billy Biggs <vektor@DIV8.NET>
To: Paul Barton-Davis <pbd@Op.Net>
cc: Linux Audio Dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] O_NONBLOCK in OSS 
In-Reply-To: <199911160437.XAA29559@renoir.op.net>
Message-ID: <Pine.LNX.3.96.991116001614.5932C-100000@vektor.div8.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 963f4cec07779a41e608428e91158a6e

On Mon, 15 Nov 1999, Paul Barton-Davis wrote:

> >  If I open the device O_NONBLOCK, my app skips alot, with lots of 
> >annoying clicks happening every buffer.  Shortening the buffer size
> >increases the annoying click factor.
> >  If I remove O_NONBLOCK from the open call, the app doesn't skip at all,
> >and sounds perfect.
> 
> for quickest service: send me your code. are you doing things
> differently in non-blocking mode ? i *hope* so - doing the same thing
> will indicate to the driver that you don't care if your write failed
> because there wasn't enough space in the h/w buffer.

  Well, okay, so I'm doing the same code for both.  If I'm in nonblocking
mode, what do I need to do to ensure that sound goes okay?

  The real issue is that I cannot have the app block if the soundcard
cannot be opened immediately.  That's the point of the O_NONBLOCK flag.
OSS shouldn't give it any more meaning than that.

--
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

From - Tue Nov 16 03:08:17 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id CAA22849
	for <slinkp@ulster.net>; Tue, 16 Nov 1999 02:35:25 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id CAA19504 for linux-audio-dev-list; Tue, 16 Nov 1999 02:03:29 -0500
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA19501 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 16 Nov 1999 02:03:26 -0500
Received: from someip.ppp.op.net (d-bm3-02.ppp.op.net [209.152.194.66]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id AAA03403; Tue, 16 Nov 1999 00:29:20 -0500 (EST)
Message-Id: <199911160529.AAA03403@renoir.op.net>
To: Billy Biggs <vektor@DIV8.NET>
cc: Linux Audio Dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] O_NONBLOCK in OSS 
In-reply-to: Your message of "Tue, 16 Nov 1999 00:17:56 EST."
             <Pine.LNX.3.96.991116001614.5932C-100000@vektor.div8.net> 
Date: Tue, 16 Nov 1999 00:30:09 -0500
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e513cf7203b9fa029b862a943da9b7a0

>  The real issue is that I cannot have the app block if the soundcard
>cannot be opened immediately.  That's the point of the O_NONBLOCK flag.
>OSS shouldn't give it any more meaning than that.

thats not what O_NONBLOCK means. it means "do not block if read or
write cannot be satisfied without blocking". it has little or no
impact on the open(2) implementation for most drivers of any kind. by
using it, you are telling the driver to return zero if it has no space
available to put the data you are write(2)-ing or no data to return if
you are read(2)-ing. thats all.

--p

From - Tue Nov 16 03:08:15 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id CAA21169
	for <slinkp@ulster.net>; Tue, 16 Nov 1999 02:02:20 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id BAA19477 for linux-audio-dev-list; Tue, 16 Nov 1999 01:33:38 -0500
Received: from shell.dhp.com (shell.dhp.com [199.245.105.1]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA19474 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 16 Nov 1999 01:33:34 -0500
Received: by shell.dhp.com (Postfix, from userid 668)
	id EF4A71ABEE; Tue, 16 Nov 1999 00:34:43 -0500 (EST)
Date: Tue, 16 Nov 1999 00:34:43 -0500 (EST)
From: Billy Biggs <vektor@DIV8.NET>
To: Paul Barton-Davis <pbd@Op.Net>
Cc: Linux Audio Dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] O_NONBLOCK in OSS 
In-Reply-To: <199911160529.AAA03403@renoir.op.net>
Message-ID: <Pine.LNX.4.04.9911160032270.22058-100000@shell.dhp.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5510503693401eb89e172a88ddc1ef34

On Tue, 16 Nov 1999, Paul Barton-Davis wrote:

> >  The real issue is that I cannot have the app block if the soundcard
> >cannot be opened immediately.  That's the point of the O_NONBLOCK flag.
> >OSS shouldn't give it any more meaning than that.
> 
> thats not what O_NONBLOCK means. it means "do not block if read or
> write cannot be satisfied without blocking". it has little or no
> impact on the open(2) implementation for most drivers of any kind. by
> using it, you are telling the driver to return zero if it has no space
> available to put the data you are write(2)-ing or no data to return if
> you are read(2)-ing. thats all.

  We're both wrong, I think:

       O_NONBLOCK or O_NDELAY
               The file is opened in non-blocking  mode.  Neither
               the open nor any subsequent operations on the file
               descriptor which is returned will cause the  call
               ing  process  to  wait.  For the handling of FIFOs
               (named pipes), see also fifo(4).

  So basically, I don't want my app to sit there waiting if someone else
is using the soundcard.  That's what happens if I take out the O_NONBLOCK
flag to the call to open.  The only hack I can think of would be to try to
open it NONBLOCK, and if that works, re-open it without the flag.  Ugly
ugly ugly.

  I don't think I (or anybody else, if they want to make a user-friendly
program) has any choice but to buffer audio ourselves.

--
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

From - Wed Nov 17 23:05:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id FAA31801
	for <slinkp@ulster.net>; Tue, 16 Nov 1999 05:59:16 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA19915 for linux-audio-dev-list; Tue, 16 Nov 1999 05:27:39 -0500
Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA19912 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 16 Nov 1999 05:27:32 -0500
Received: from parabola.demon.co.uk ([212.228.182.246] helo=ariel.sr.home)
	by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1)
	id 11nfl0-000HrG-0B; Tue, 16 Nov 1999 10:22:38 +0000
Received: (from steve@localhost)
	by ariel.sr.home (8.9.3/8.9.3) id JAA27184;
	Tue, 16 Nov 1999 09:51:35 GMT
Date: Tue, 16 Nov 1999 09:51:35 +0000
From: Steve Ratcliffe <steve@parabola.demon.co.uk>
To: Billy Biggs <vektor@DIV8.NET>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] O_NONBLOCK in OSS
Message-ID: <19991116095135.A26875@parabola.demon.co.uk>
Mail-Followup-To: Billy Biggs <vektor@DIV8.NET>,
	linux-audio-dev@ginette.musique.umontreal.ca
References: <199911160529.AAA03403@renoir.op.net> <Pine.LNX.4.04.9911160032270.22058-100000@shell.dhp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <Pine.LNX.4.04.9911160032270.22058-100000@shell.dhp.com>; from vektor@DIV8.NET on Tue, Nov 16, 1999 at 12:34:43AM -0500
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: baed150179c75a827b27765eefc4d76e

On Tue, Nov 16, 1999 at 12:34:43AM -0500, Billy Biggs wrote:
> flag to the call to open.  The only hack I can think of would be to try to
> open it NONBLOCK, and if that works, re-open it without the flag.  Ugly
> ugly ugly.

You should be able to open it NONBLOCK and then use fcntl() to
remove that flag.

..Steve

From - Wed Nov 17 23:05:02 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA00395
	for <slinkp@ulster.net>; Tue, 16 Nov 1999 06:19:18 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA19943 for linux-audio-dev-list; Tue, 16 Nov 1999 05:52:12 -0500
Received: from rztsun.rz.tu-harburg.de (rztsun.rz.tu-harburg.de [134.28.200.14]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA19940 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 16 Nov 1999 05:52:09 -0500
Received: from the-box.tu-harburg.de (x209.dialin.tu-harburg.de [134.28.9.209])
	by rztsun.rz.tu-harburg.de (8.9.0/8.8.8) with ESMTP id LAA09768
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 16 Nov 1999 11:47:14 +0100 (MET)
Received: from localhost ([127.0.0.1])
	by the-box.tu-harburg.de with esmtp (Exim 3.01 #1)
	id 11nfRx-00009e-00
	for linux-audio-dev@ginette.musique.umontreal.ca; Tue, 16 Nov 1999 11:02:57 +0100
Date: Tue, 16 Nov 1999 11:02:57 +0100 (CET)
From: Michael Krause <m.krause@tu-harburg.de>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] O_NONBLOCK in OSS 
In-Reply-To: <Pine.LNX.4.04.9911160032270.22058-100000@shell.dhp.com>
Message-ID: <Pine.LNX.4.10.9911161101380.584-100000@the-box.tu-harburg.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e8af254473126c919b3aa01ee1ccfbd3

On Tue, 16 Nov 1999, Billy Biggs wrote:

>   So basically, I don't want my app to sit there waiting if someone else
> is using the soundcard.  That's what happens if I take out the O_NONBLOCK
> flag to the call to open.  The only hack I can think of would be to try to
> open it NONBLOCK, and if that works, re-open it without the flag.  Ugly
> ugly ugly.

No, open /dev/dsp with O_NONBLOCK, and if it succeeds, do a fcntl(fd,
F_SETFL, 0) to clear O_NONBLOCK.

-- 
michael krause [aka raw style / lego] - www.tu-harburg.de/~semk2104/

From - Wed Nov 17 23:05:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA29558
	for <slinkp@ulster.net>; Tue, 16 Nov 1999 10:43:10 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA20307 for linux-audio-dev-list; Tue, 16 Nov 1999 10:07:23 -0500
Received: from shell.dhp.com (shell.dhp.com [199.245.105.1]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA20304 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 16 Nov 1999 10:07:19 -0500
Received: by shell.dhp.com (Postfix, from userid 668)
	id F122C1AC00; Tue, 16 Nov 1999 10:02:28 -0500 (EST)
Date: Tue, 16 Nov 1999 10:02:28 -0500 (EST)
From: Billy Biggs <vektor@DIV8.NET>
To: Steve Ratcliffe <steve@parabola.demon.co.uk>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] O_NONBLOCK in OSS
In-Reply-To: <19991116095135.A26875@parabola.demon.co.uk>
Message-ID: <Pine.LNX.4.04.9911161001250.32508-100000@shell.dhp.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: dc4c34a978096e25cfc1259e6c21b64d

On Tue, 16 Nov 1999, Steve Ratcliffe wrote:

> On Tue, Nov 16, 1999 at 12:34:43AM -0500, Billy Biggs wrote:
> > flag to the call to open.  The only hack I can think of would be to try to
> > open it NONBLOCK, and if that works, re-open it without the flag.  Ugly
> > ugly ugly.
> 
> You should be able to open it NONBLOCK and then use fcntl() to
> remove that flag.

  Yep, pbd suggested this first, and I'm pretty much a moron for not
thinking of it that way.

  The app is working well now.  It's pretty silly though.  I just posted
it on freshmeat - KRad, a tone dialer for KDE2.

--
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

From - Wed Nov 17 23:05:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA29721
	for <slinkp@ulster.net>; Tue, 16 Nov 1999 10:44:24 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA20253 for linux-audio-dev-list; Tue, 16 Nov 1999 09:51:02 -0500
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA20250 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 16 Nov 1999 09:50:59 -0500
Received: from bright.net (find-cas1-cs-28.dial.bright.net [209.143.26.131])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id JAA12321;
	Tue, 16 Nov 1999 09:46:09 -0500 (EST)
Message-ID: <3831747E.D017331B@bright.net>
Date: Tue, 16 Nov 1999 10:13:02 -0500
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] need help with SLab
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 68c271649a577f404ef6f29b90319d3a

Greetings:

  I'm profiling SLab for my book, but I've run into a problem unique to
this program. I can record fine with my SB PCI128, but on playback an
annoying ticking can be heard throughout the recording. It's actually
ticking at a rate that "accompanies" the signal, either in triplets or
16ths. I've contacted the author, he's pretty sure it's an internal
problem, but I wondered if anyone else here has tried SLab and
encountered this problem. Or, have any of you developers encountered
such a problem in your own work, and if so, what did you do about it ?
TIA !

  My system:
	P166 w. 128 megs RAM
	kernel 2.0.36 (RH 5.2 recompiled)
	OSS/Linux driver 3.9.2m
	Sound Blaster PCI128

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
       http://www.bright.net/~dlphilp/linuxsound/

From - Wed Nov 17 23:05:21 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA18004
	for <slinkp@ulster.net>; Tue, 16 Nov 1999 19:56:23 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA21445 for linux-audio-dev-list; Tue, 16 Nov 1999 19:01:33 -0500
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA21442 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 16 Nov 1999 19:01:29 -0500
Received: from localhost.localdomain (d212-151-85-74.swipnet.se [212.151.85.74]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA29970; 
          Wed, 17 Nov 1999 00:56:21 +0100 (MET)
From: David Olofson <audiality@swipnet.se>
To: Billy Biggs <vektor@DIV8.NET>, Dave Phillips <dlphilp@bright.net>
Subject: Re: [linux-audio-dev] MIDI reset?
Date: Wed, 17 Nov 1999 00:57:15 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <Pine.LNX.3.96.991114191600.3700B-100000@vektor.div8.net>
In-Reply-To: <Pine.LNX.3.96.991114191600.3700B-100000@vektor.div8.net>
MIME-Version: 1.0
Message-Id: <99111701044301.00509@localhost.localdomain>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA18004
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 57834ab4e145a750fc5f964ffaeed192

On Mon, 15 Nov 1999, Billy Biggs wrote:
> On Sun, 14 Nov 1999, Dave Phillips wrote:
> 
> > > Should I rather be sending the ugly 0-velocity note-on?
> > 
> > Sorry, sorry: I should have written "note-off velocity". I think all
> > synths recognize the note-off event, but ignore the velocity value.
> 
>   Ok, that makes _alot_ more sense.  :)  I thought there might be some
> strange MIDI quirk I'd never known about.
> 
>   I always send 0 for a note-off velocity, and stuff seems to work ok.

Don't. Do it right, or you'll have a bad surprize sooner or later.
There are synths that use the note-off velocity. The "studio
standard" Roland JV-1080 and relatives do, for example. (Which makes
the fact that Cakewalk can't control note-off velocity very annoying.
I have to reprogram the synth to get around that. And CW's MIDI
through does *not* add this flaw, so the synth responds differently
to MIDI thru and sequencer playback! :-( )


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Nov 19 02:15:36 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA03797
	for <slinkp@ulster.net>; Thu, 18 Nov 1999 19:18:55 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA03277 for linux-audio-dev-list; Thu, 18 Nov 1999 18:47:35 -0500
Received: from mail.virginia.edu (mail.Virginia.EDU [128.143.2.9]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id SAA03274 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 18 Nov 1999 18:47:31 -0500
Received: from neon.mail.virginia.edu by mail.virginia.edu id aa24719;
          18 Nov 99 18:42 EST
Received: from virginia.edu (topper@equinox.music.Virginia.EDU [128.143.140.112])
	by neon.mail.Virginia.EDU (8.8.7/8.8.7) with ESMTP id SAA21542;
	Thu, 18 Nov 1999 18:42:23 -0500 (EST)
Message-ID: <38320CD0.E73E549B@virginia.edu>
Date: Tue, 16 Nov 1999 21:02:56 -0500
From: David Topper <topper@virginia.edu>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.6 i686)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: comp.os.linux.portable,comp.music.midi
To: gary@ccrma.Stanford.EDU, prc@cs.princeton.edu,
        brad@woof.music.columbia.edu, jgg9c@virginia.edu, tpg@this.is,
        topper@virginia.edu, linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Linux laptop MIDI attempt #1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 9fd96290031e9652e08f46472cb39ff7

Hi folks,

I'm stabbing a bit in the dark here because I'm not all that savvy with
serial port issues.  But I am happy to report *something* which is more
than I could previously.

Bascially, I have one of those SGI "Unwinder" serial MIDI (model UW-3)
adapters.  My hunch is that they do precisely what Perry was suggesting
vis-a-vis baud rate (serial_port = 38400, MIDI = 31.250) conversion.  So
I've got it plugged into my laptop and am trying to read byte triplets.
I do get data, but it seems heavily buffered.  I tried using setserial
to change the baud rate of my serial port to various settings, but
anything below 38400 does not seem to work.

So I hit keys on my keyboard, then data scrolls by every couple of
seconds.  When I try to hit only 1 key (eg., middle C) I don't get
anything at all.  But if I do start to hit "random" keys or do an
arpeggio (eg., middle C, E, G, C) then I do get data.  Here's a sample,
using the arpeggio.

count:  0
[0]:ff
[1]:ff
[2]:ff
count:  1
[0]:ff
[1]:ff
[2]:ff
count:  2
[0]:ff
[1]:ff
[2]:ff
count:  3
[0]:ff
[1]:ff
[2]:ff
count:  4
[0]:ff
[1]:e2
[2]:22
count:  5
[0]:ff
[1]:82
[2]:2
count:  6
[0]:ff
[1]:c4
[2]:ff
count:  7
[0]:c8
[1]:48
[2]:ff
count:  8
[0]:c4
[1]:44
[2]:ff
count:  9
[0]:c0
[1]:0
[2]:ff
count:  10
[0]:42
[1]:0
[2]:ff
count:  11
[0]:e2
[1]:0
[2]:ff

It spurts out bytes in somewhat random fashion.  I would have been
happier if it somehow spit stuff out every 64 bytes or whatnot.

If anyone has ideas/comments/ANYTHING I'd love to hear them.

---- here's the code I'm using to generate the above output ----

#include <stdio.h>
#include <linux/ioctl.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/soundcard.h>
#include <unistd.h>
#include <sys/types.h>
#include <errno.h>

main(int argc, char* argv[])
{
  /* Misc stuff */
  float start;
  int count;
  int debug;
  char *cp;

  /* MIDI stuff */
  int i,midi_fd,len,midiChan,oct,pitch;
  unsigned char datum[3];
  unsigned char note_val;
  unsigned char note_vel;
  unsigned char note_on;
  unsigned char note_off;
  float opc;

  /* Open the MIDI port */
  if ((midi_fd = open("/dev/cua0", O_RDONLY, 0)) == -1) {
    perror("/dev/cua0");
    exit(1);
  }

  count = 0;
  debug = 0;
  while(1) {

    printf("count:  %d\n",count);
    for(i=0;i<3;i++) {
      datum[i] = 0;
    }

    if ((len = read(midi_fd, &datum[0], 1)) == -1) {
     perror("MIDI read");
      exit(1);
    }

    if ((len = read(midi_fd, &datum[1], 1)) == -1) {
     perror("MIDI read");
      exit(1);
    }

    if ((len = read(midi_fd, &datum[2], 1)) == -1) {
     perror("MIDI read");
      exit(1);
    }

    for(i=0;i<3;i++) {
      printf("[%d]:%x\n",i,datum[i]);
    }

    if (datum[0] == 0x90) {
      note_val = datum[1];
      note_vel = datum[2];
      printf("note_on:  %d - %d\n",note_val,note_vel);
    }
    else if (datum[0] == 0x80) {
      note_val = datum[1];
      note_vel = datum[2];
      printf("note_off:  %d - %d\n",note_val,note_vel);
    }

    fflush(stdout);
    count++;
  }
  close(midi_fd);
}

DT
--
Technical Director - Virginia Center for Computer Music
http://www.people.virginia.edu/~djt7p


From - Wed Nov 17 23:14:58 1999
Received: from mc-qout4.whowhere.com (mc-qout4.whowhere.com [209.185.123.18])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA25875
	for <slinkp@ulster.net>; Wed, 17 Nov 1999 23:07:34 -0500
Received: from Unknown/Local ([?.?.?.?]) by angelfire.com; Wed Nov 17 19:59:29 1999
To: slinkp@ulster.net
Date: Wed, 17 Nov 1999 22:59:29 -0500
From: "Paul Winkler" <slinkp@angelfire.com>
Message-ID: <CPFPPCNAOFELCAAA@angelfire.com>
Mime-Version: 1.0
Cc: 
X-Sent-Mail: off
Reply-To: 
X-Mailer: MailCity Service
Subject: Fwd: Re: Malibu kurzweil synth documentation?
X-Sender-Ip: 208.242.164.163
Organization: Angelfire  (http://email.angelfire.com:80)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 50e1b2425b79cb9a8dc992953e70a842

 
--

--------- Forwarded Message ---------

DATE: Tue, 16 Nov 1999 12:49:44
From: tbtech@voyetra.com
To: "Paul Winkler" <slinkp@angelfire.com>

Paul,
	We will take your email into consideration.  In the mean time, 
however, Linux is not supported by us.  Thank you.

Regards,

Dan
Turtle Beach Tech Support
Voyetra Turtle Beach, Inc. 
Ph. 914-966-2150  
Fax.914-966-1093
tech@tbeach.com 
www.voyetra.com  www.tbeach.com

------ Original Message -----
To:             	tbtech@voyetra.com
Date sent:      	Tue, 16 Nov 1999 02:57:43 -0500
From:           	"Paul Winkler" <slinkp@angelfire.com>
Copies to:      	Send reply to:  	Subject:        	Re: Malibu kurzweil synth documentation?
Organization:   	Angelfire  (http://email.angelfire.com:80)

> Dan,
> 
> Thanks for the quick reply.
> 
> You wrote:
> >Paul,
> >	While we at Voyetra Turtle Beach understand the growing 
> >alternative OS market( Linux, BeOS,etc), currently we do not offer 
> >drivers or support for these OSes.
> 
> I certainly understand that-- every company works with limited resources
> and the Linux community is not yet a large market. However, I can't help
> pointing out that I am not asking for either drivers or support. The ALSA
> team has already written a driver that works very well for all features of
> the Malibu _except_ the Kurzweil synth.
> 
> All we would need is access to one document, which I assume already exists
> for your developers' internal use, that contains information on
> controlling the malibu's internal kurzweil synth.
> 
> Once such information became available to the ALSA team, we would have no
> further need of any assistance from Turtle Beach.
> 
> If you would prefer not to release such a document on the grounds of
> protecting trade secrets, I would like to point out:
> 
> 1) There's not much to protect -- everything about the Malibu except the
> Kurzweil chip is covered in Crystal's CS4237B data sheets.
> 
> 2) Being protective about the Malibu doesn't give you any competitive edge
> at this point-- I don't see the Malibu listed as a currently available
> soundcard on the Turtle Beach web page.
> 
> 3) Some of your competitors are already being very cooperative to the open
> source community. You may have heard the announcement that Creative Labs
> has released source code for a driver for the Soundblaster Live. Earlier,
> Trident was developing a driver for Linux for their 4D card and decided to
> turn the driver over to the ALSA team; as a result, they have
> simultaneously increased their market share and decreased their workload,
> since one advantage of releasing source code and / or documentation is
> that you can let the open source community do all the driver development
> for you.
> 
> I sincerely hope that you will reconsider releasing the documentation on
> the Kurzweil synth.
> 
> Thanks for your time,
> 
> PW
> 
> 
> Angelfire for your free web-based e-mail. http://www.angelfire.com


*******************************************************

Please check the VTB Tech Support Knowledge Base / FAQ: 
http://www.voyetra-turtle-beach.com/site/kb_ftp/kb.asp
Most of the questions asked by customers are covered here. 

The VTB KB/FAQ is open at all hours and regularly 
updated for your convenience - no waiting for a 
technician to take your call or return your e-mail, 
and no long-distance phone fees! 

*******************************************************
Please include your Product Id in the subject line of 
all email and include all previous correspondence in 
the body of the message.
*******************************************************
 
Turtle Beach Systems
Technical support (914)966-2150
Fax number (914)966-1093
Web URL:  http://www.tbeach.com
5 Odell Plaza, Yonkers, NY 10701-1406 USA

--------- End Forwarded Message ---------



Angelfire for your free web-based e-mail. http://www.angelfire.com

From - Wed Nov 17 23:55:30 1999
Received: from mc-qout4.whowhere.com (mc-qout4.whowhere.com [209.185.123.18])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA30374
	for <slinkp@ulster.net>; Wed, 17 Nov 1999 23:44:32 -0500
Received: from Unknown/Local ([?.?.?.?]) by angelfire.com; Wed Nov 17 20:36:23 1999
To: slinkp@ulster.net
Date: Wed, 17 Nov 1999 23:36:23 -0500
From: "Paul Winkler" <slinkp@angelfire.com>
Message-ID: <BAHNPMLIBGGLCAAA@angelfire.com>
Mime-Version: 1.0
Cc: 
X-Sent-Mail: off
Reply-To: 
X-Mailer: MailCity Service
Subject: Fwd: Re: Malibu kurzweil synth documentation?
X-Sender-Ip: 208.242.164.163
Organization: Angelfire  (http://email.angelfire.com:80)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 8c79824fd2df9958f2b10e0712e2c875

 
--

--------- Forwarded Message ---------

DATE: Mon, 15 Nov 1999 12:40:16
From: tbtech@voyetra.com
To: Paul Winkler <slinkp@angelfire.com>

Paul,
	While we at Voyetra Turtle Beach understand the growing 
alternative OS market( Linux, BeOS,etc), currently we do not offer 
drivers or support for these OSes.  This could change in the future.  
Please periodically visit our website for updated information about 
future support for non- Microsoft OSes.  Thank you for your 
understanding.


Regards,

Dan
Turtle Beach Tech Support
Voyetra Turtle Beach, Inc. 
Ph. 914-966-2150  
Fax.914-966-1093
tech@tbeach.com 
www.voyetra.com  www.tbeach.com

----- Original Message -----
Date sent:      	Sun, 14 Nov 1999 19:41:32 -0500
From:           	Paul Winkler <slinkp@angelfire.com>
To:             	tech@tbeach.com
Subject:        	Malibu kurzweil synth documentation?

> Hi Turtle Beach,
> 
> I've been using a TB Malibu quite happily for almost 2 years. I'm a
> Linux user and have found that the OSS drivers (from www.4front.com)
> support the Malibu pretty well; so do the free ALSA
> (www.alsa-project.org) drivers.
> 
> However, I'm now in a bit of a fix. I'm running up against some
> limitations of the OSS midi driver, and I would love to switch to
> the ALSA driver, which is developing a greatly improved linux MIDI
> driver. The only trouble is that ALSA  is so far unable to support
> the Malibu's onboard Kurzweil synth, which I need to use.
> 
> To quote ALSA project organizer Jaroslav Kysela:
> Jaroslav Kysela <perex@suse.cz> wrote:
> > Malibu seems to have the internal synthesizer connected to the MPU401
> > port, but I don't know how to initialize this connection :-(( If you get
> > specs from Turtle Beach, I'll enable it..
> 
> I hope you will consider releasing these specs. It seems to me that
> Turtle Beach has nothing to lose by doing this, and much good will
> to gain from the Open Source community. The ALSA project has not
> hesitated to recommend that their users buy products from companies
> that have cooperated with them. Most of the documentation for the
> Malibu is already available, since it uses the CS4237B chipset which
> Crystal Semi has released documents for. I am hoping Turtle Beach
> will acknowledge their Linux-using customers by releasing the
> documentation for the Kurzweil synth.
> 
> For more information on why releasing technical docs is a good idea,
> read:
> http://www.alsa-project.org/~cdavid/vendorinfo/call.html
> 
> Thanks very much,
> 
> PW
> 
> ................    paul winkler    ..................
> slinkP arts:   music, sound, illustration, design, etc.
> A member of ARMS    ----->    http://www.reacharms.com
> or http://www.mp3.com/arms or http://www.amp3.com/arms
> personal page   ---->    http://www.ulster.net/~abigoo


*******************************************************

Please check the VTB Tech Support Knowledge Base / FAQ: 
http://www.voyetra-turtle-beach.com/site/kb_ftp/kb.asp
Most of the questions asked by customers are covered here. 

The VTB KB/FAQ is open at all hours and regularly 
updated for your convenience - no waiting for a 
technician to take your call or return your e-mail, 
and no long-distance phone fees! 

*******************************************************
Please include your Product Id in the subject line of 
all email and include all previous correspondence in 
the body of the message.
*******************************************************
 
Turtle Beach Systems
Technical support (914)966-2150
Fax number (914)966-1093
Web URL:  http://www.tbeach.com
5 Odell Plaza, Yonkers, NY 10701-1406 USA

--------- End Forwarded Message ---------



Angelfire for your free web-based e-mail. http://www.angelfire.com

From - Thu Nov 18 00:30:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA02620
	for <slinkp@ulster.net>; Thu, 18 Nov 1999 00:27:42 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA27618 for linux-audio-dev-list; Wed, 17 Nov 1999 23:58:59 -0500
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA27615 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 17 Nov 1999 23:58:55 -0500
Received: from ulster.net (port163.ts2.ulster.net [208.242.164.163])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id AAA32246;
	Thu, 18 Nov 1999 00:01:15 -0500
Message-ID: <3833889D.547AFDC0@ulster.net>
Date: Thu, 18 Nov 1999 00:03:25 -0500
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jaroslav Kysela <perex@suse.cz>
CC: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Malibu, was Re: MIDI reset?
References: <Pine.LNX.4.05.9911141226100.31774-100000@gate.suse.cz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: a135a94a8c99fd3e513f0a64cbb69461

Jaroslav Kysela wrote:

> Malibu seems to have the internal synthesizer connected to the MPU401
> port, but I don't know, how to initialize this connection :-((
> If you get specs from Turtle Beach, I'll enable it..
>

No joy. They are doing the old song and dance:

me: "hi, can you release a document?"
them: "we do not support linux at this time"
me: "yes, but I don't need support, I just need one document"
them: "we'll think about it, but we do not support linux at this
time"

aaargh.

-- 
................    paul winkler    ..................
slinkP arts:   music, sound, illustration, design, etc.
A member of ARMS    ----->    http://www.reacharms.com
or http://www.mp3.com/arms or http://www.amp3.com/arms
personal page   ---->    http://www.ulster.net/~abigoo

From - Fri Nov 19 02:15:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA00523
	for <slinkp@ulster.net>; Thu, 18 Nov 1999 15:27:09 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA02958 for linux-audio-dev-list; Thu, 18 Nov 1999 14:45:52 -0500
Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA02955 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 18 Nov 1999 14:45:45 -0500
Received: from op.net (d-bm2-15.ppp.op.net [209.152.194.53]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id OAA06143 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 18 Nov 1999 14:40:31 -0500 (EST)
Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id OAA16648; Thu, 18 Nov 1999 14:41:25 -0500
Date: Thu, 18 Nov 1999 14:41:25 -0500
Message-Id: <199911181941.OAA16648@op.net>
From: Paul Barton-Davis <pbd@Op.Net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] nice sound for a metronome ?
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: ea858eabf1d1897f4f35cbec37c8ec4d

any suggestions on a good signal for a the sound of a metronome tick ?

i'd like something with a "thud"-ish feel, rather than a
scratch/click/pop kind of thing. it would be ideal if it was very
short (say, 16 frames) and/or could easily be scaled to fit various
numbers of frames. samples are not viable.

--regards,
--p

From - Fri Nov 19 02:15:31 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA08932
	for <slinkp@ulster.net>; Thu, 18 Nov 1999 16:23:12 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA03055 for linux-audio-dev-list; Thu, 18 Nov 1999 15:48:19 -0500
Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA03052 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 18 Nov 1999 15:48:15 -0500
Received: from d1o43.telia.com (d1o43.telia.com [194.22.195.241])
	by mailf.telia.com (8.9.3/8.9.3) with ESMTP id VAA24892;
	Thu, 18 Nov 1999 21:43:06 +0100 (CET)
Received: from norran.net (roger@t2o43p55.telia.com [194.22.195.115])
	by d1o43.telia.com (8.8.8/8.8.8) with ESMTP id VAA00377;
	Thu, 18 Nov 1999 21:43:05 +0100 (CET)
Message-ID: <38346DEF.9D482EC1@norran.net>
Date: Thu, 18 Nov 1999 22:21:51 +0100
From: Roger Larsson <roger.larsson@norran.net>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Ingo Molnar <mingo@chiara.csoma.elte.hu>
CC: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] FS "corruption" with 2.2.13 + lowlat-2.2.13-A1.txt + 
 latency-profiling-2.2.13-r7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: fe7c4ae1642c045f9baf49e21b01e536

Hi all (and especially Ingo),


I recenty compiled 2.2.13 with Ingos 'lowlat' and mine
'latency-profiling'.

Since then I have had several freezes...

This is a little strange since both 'lowlat' and 'latency-profiling'
works
well under 2.2.10.

Let me describe the last situation (not a complete freeze but scary!)

* Running Netscape
* Netscape stops updating its windows
* ps auxc shows no sign of Netscape (I can't kill it)
* X crashes...
* Impossible to restart X, shared libraries missing
* Investigating... at one points tries a 'man mem' it fails due to a
  shared library missing (now it is really scary)
* Reboots on a 2.2.5 boot disk - no FS corruption detected.
* Everything back to normal...

Could this be a case of memory full - lets kill some apps?

/RogerL

From - Fri Nov 19 02:15:34 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA03739
	for <slinkp@ulster.net>; Thu, 18 Nov 1999 19:18:22 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA03282 for linux-audio-dev-list; Thu, 18 Nov 1999 18:48:12 -0500
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA03279 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 18 Nov 1999 18:48:09 -0500
Received: from bright.net (find-cas1-cs-49.dial.bright.net [209.143.26.152])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id SAA05253;
	Thu, 18 Nov 1999 18:43:06 -0500 (EST)
Message-ID: <3834957B.8340166A@bright.net>
Date: Thu, 18 Nov 1999 19:10:35 -0500
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] [Fwd: MidiShare for Linux]
Content-Type: multipart/mixed;
 boundary="------------7CDD9F9865B207522BD6BDB9"
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 8f7a14da2ffd7a80ae5f5393258af74a

This is a multi-part message in MIME format.
--------------7CDD9F9865B207522BD6BDB9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Greetings:

  I thought this might be of interest to some of you...

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
       http://www.bright.net/~dlphilp/linuxsound/
--------------7CDD9F9865B207522BD6BDB9
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Received: by  (mbox dlphilp)
 (with Cubic Circle's cucipop (v1.31 1998/05/13) Thu Nov 18 10:25:47 1999)
X-From_: letz@rd.grame.fr  Thu Nov 18 10:21:55 1999
Return-Path: <letz@rd.grame.fr>
Received: from ccpntc5.in2p3.fr (ccpntc5.in2p3.fr [134.158.69.177])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id KAA25247
	for <dlphilp@bright.net>; Thu, 18 Nov 1999 10:21:54 -0500 (EST)
Received: from rd.grame.fr (rd.grame.fr [194.5.49.4])
	by ccpntc5.in2p3.fr (8.9.3/8.9.3) with SMTP id QAA53700
	for <dlphilp@bright.net>; Thu, 18 Nov 1999 16:21:51 +0100
Received: from macsteph.grame.fr by rd.grame.fr (NX5.67c/NX3.0S)
	id AA02499; Thu, 18 Nov 99 17:17:45 +0100
Message-Id: <v03007801b459c96852a4@[194.5.49.5]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 18 Nov 1999 16:21:15 +0100
To: dlphilp@bright.net
From: Stephane Letz <letz@rd.grame.fr>
Subject: MidiShare for Linux
X-Mozilla-Status2: 00000000

The MidiShare source code for Linux is available on the Grame CVS server.

MidiShare on Linux is separated in a kernel module and a shared library.
The kernel module contains the code used with kernel privilege : scheduler,
Midi drivers,Inter Application Communication...
The shared library contains code used by MidiShare client applications. The
library and kernel communicate using the standard ioctl mechanisms. A
device named /dev/midishare is defined.

There are two possible compilation targets :

- one without drivers which allows to test MidiShare applications, Inter
Application Communication..
- one with Midi drivers buit using ALSA (http://www.alsa-project.org)

To access the anonymous CVS, set your CVSROOT environment variable to:

CVSROOT=:pserver:anonymous@cvs.grame.fr:/src/midishare

Next, use the "cvs login" command to connect to the server. The password is
"anonymous". Then you can use "cvs checkout linux" to get the Linux module.

Look at the README.txt for more information.


The MidiShare home page is at :
http://www.grame.fr/MidiShare/

The web interface for the CVS code is at :
http://cvs.grame.fr/cgi-bin/midishare-cvs

We plan to publish soon a developer kit with example of applications,
documentation and libraries.

Comments and bug report are welcome! Please mail to MidiShare@rd.grame.fr


Stephane Letz


Grame: Centre National de creation musicale
9, Rue du Garet
69001 Lyon
Tel: 04-72-07-37-00
Fax: 04-72-07-37-01
Web: www.grame.fr



--------------7CDD9F9865B207522BD6BDB9--

From - Fri Nov 19 02:15:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA30734
	for <slinkp@ulster.net>; Thu, 18 Nov 1999 22:27:43 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA03440 for linux-audio-dev-list; Thu, 18 Nov 1999 21:03:44 -0500
Received: from mail.virginia.edu (mail.Virginia.EDU [128.143.2.9]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id VAA03437 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 18 Nov 1999 21:03:40 -0500
Received: from neon.mail.virginia.edu by mail.virginia.edu id aa20939;
          18 Nov 99 20:58 EST
Received: from virginia.edu (bootp-141-105.bootp.Virginia.EDU [128.143.141.105])
	by neon.mail.Virginia.EDU (8.8.7/8.8.7) with ESMTP id UAA13419
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 18 Nov 1999 20:58:38 -0500 (EST)
Message-ID: <3834B1B3.4E122B99@virginia.edu>
Date: Thu, 18 Nov 1999 21:10:59 -0500
From: "David J. Topper" <topper@virginia.edu>
Organization: University of Virginia
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
CC: "linux-audio-dev@ginette.musique.umontreal.ca" <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Laptop MIDI?
References: <199910290135.VAA13675@renoir.op.net> <38193984.3F7622D4@mindless.com> <3819D6D7.C32B8E7D@ulster.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 4ac3799142dd66db29cab13b93d0293c

Hi folks,

Anyone out there using a serial or parallel port MIDI device on a
laptop?  I'm imagining that pretty much any Windoze compatible device
should work as they too have to deal with the baud rate discrepancy.

Thanks,

DT
--
David Topper
Technical Director - Virginia Center for Computer Music
Programmer Analyst - School of Arts and Sciences
http://www.people.virginia.edu/~djt7p
(804) 924-6887


From - Mon Nov 22 11:43:46 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id EAA28136
	for <slinkp@ulster.net>; Fri, 19 Nov 1999 04:56:56 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id EAA07833 for linux-audio-dev-list; Fri, 19 Nov 1999 04:23:55 -0500
Received: from upf.es (newton.upf.es [193.145.54.60]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA07830 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 19 Nov 1999 04:23:46 -0500
Received: from mtg150.upf.es (mtg150.upf.es [193.145.44.150])
	by upf.es (8.9.0/8.9.0) with SMTP id KAA04669
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 19 Nov 1999 10:18:28 +0100 (MET)
From: maarten de boer <maarten.deboer@iua.upf.es>
Reply-To: maarten.deboer@iua.upf.es
Organization: IUA
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] FS "corruption" with 2.2.13 + lowlat-2.2.13-A1.txt + latency-profiling-2.2.13-r7
Date: Fri, 19 Nov 1999 10:23:55 +0100
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <38346DEF.9D482EC1@norran.net>
MIME-Version: 1.0
Message-Id: <99111910275203.00989@mtg150.upf.es>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 11b26153524c9a50c609aab5ed251dd6

On Thu, 18 Nov 1999, roger.larsson@norran.net wrote:
> Hi all (and especially Ingo),
> 
> 
> I recenty compiled 2.2.13 with Ingos 'lowlat' and mine
> 'latency-profiling'.
> 
> Since then I have had several freezes...
> 
> This is a little strange since both 'lowlat' and 'latency-profiling'
> works
> well under 2.2.10.

Hm. I had a lot of freezes with 2.2.10 + lowlat, and less with 2.2.13 +
lowlat. I use a SMP machine. On neither Benno's /proc stresstest
does not give the desired results.

Maarten

From - Mon Nov 22 11:43:50 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA27836
	for <slinkp@ulster.net>; Fri, 19 Nov 1999 10:22:03 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA08164 for linux-audio-dev-list; Fri, 19 Nov 1999 09:37:33 -0500
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA08161 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 19 Nov 1999 09:37:26 -0500
Received: from smp.localnet.it (IDENT:root@[194.242.217.4])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id PAA00807;
	Fri, 19 Nov 1999 15:32:09 +0100
Received: from smp.localnet.it (IDENT:benno@localhost [127.0.0.1])
	by smp.localnet.it (8.9.3/8.9.3) with SMTP id PAA01148;
	Fri, 19 Nov 1999 15:33:37 +0100
From: Benno Senoner <sbenno@gardena.net>
To: maarten.deboer@iua.upf.es, maarten de boer <maarten.deboer@iua.upf.es>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] FS "corruption" with 2.2.13 + lowlat-2.2.13-A1.txt + latency-profiling-2.2.13-r7
Date: Fri, 19 Nov 1999 15:28:06 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <38346DEF.9D482EC1@norran.net> <99111910275203.00989@mtg150.upf.es>
In-Reply-To: <99111910275203.00989@mtg150.upf.es>
Cc: Ingo Molnar <mingo@chiara.csoma.elte.hu>
MIME-Version: 1.0
Message-Id: <99111915333600.01082@smp.localnet.it>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f8c5857259198e3043cae546a9213c55

On Fri, 19 Nov 1999, maarten de boer wrote:
> On Thu, 18 Nov 1999, roger.larsson@norran.net wrote:
> > Hi all (and especially Ingo),
> > 
> > 
> > I recenty compiled 2.2.13 with Ingos 'lowlat' and mine
> > 'latency-profiling'.
> > 
> > Since then I have had several freezes...
> > 
> > This is a little strange since both 'lowlat' and 'latency-profiling'
> > works
> > well under 2.2.10.
> 
> Hm. I had a lot of freezes with 2.2.10 + lowlat, and less with 2.2.13 +
> lowlat. I use a SMP machine. On neither Benno's /proc stresstest
> does not give the desired results.
> 
> Maarten


On my dual Celeron box, while running the UP version of 2.2.10-lowlatency-N6,
I experienced big latency problems:
the cause was APM, which seems to freeze IRQs on my mainboard Gigabyte SMP BX
(on an UP Asus P2B APM doesn't ruin latencies)
After disabling APM the results on my  celeron were ok)
I did not try with the 2.2.10-lowlatency-N6 in SMP mode, because Ingo said
that his 2.2.10 patch doesn't perform optimally on SMP since the kernel-lock
parts needs to be changes to exploit full performance.

Hmm I'm not aware of the 2.2.13-lowlat-A1 ?
Where can I get it , what is the difference between 2.2.10-N6 and this patch ?
(except that it works with kernel 2.2.13 ?)

regards,
Benno.

From - Mon Nov 22 11:44:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA30466
	for <slinkp@ulster.net>; Fri, 19 Nov 1999 14:16:32 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA08538 for linux-audio-dev-list; Fri, 19 Nov 1999 13:49:42 -0500
Received: from iona.abel.net.uk (iona.abel.net.uk [212.1.130.142]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA08535 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 19 Nov 1999 13:49:38 -0500
Message-Id: <199911191849.NAA08535@ginette.musique.umontreal.ca>
Received: (qmail 9263 invoked from network); 19 Nov 1999 18:44:32 -0000
Received: from ppp-1-138.cvx5.telinco.net (HELO default) (212.1.149.138)
  by iona.abel.net.uk with SMTP; 19 Nov 1999 18:44:32 -0000
From: "Paul Kellett" <paul.kellett@maxim.abel.co.uk>
To: <linux-audio-dev@ginette.musique.umontreal.ca>
Cc: "Paul Barton-Davis" <pbd@Op.Net>
Subject: Re: [linux-audio-dev] nice sound for a metronome ?
Date: Fri, 19 Nov 1999 18:30:16 -0000
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4859480568abb478f2106756b6de2e3c

> any suggestions on a good signal for a the sound of a metronome tick ?
> 
> i'd like something with a "thud"-ish feel, rather than a
> scratch/click/pop kind of thing. it would be ideal if it was very
> short (say, 16 frames) 

The simplest way to do it is just a trangular pulse of dc.  You can adjust
the clickiness with the overall length - I found the total length needs to be
3ms before you get a "thud" sound. The problem with this is it contains very
little energy so is quiet.

For a more "wooden" sound you could clip the output of a resonant band-pass
filter fed with a noise pulse, but this is getting more complex.


Paul.

-- 
paul.kellett@maxim.abel.co.uk
http://www.abel.co.uk/~maxim/



From - Mon Nov 22 11:43:57 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA30120
	for <slinkp@ulster.net>; Fri, 19 Nov 1999 14:13:55 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA08533 for linux-audio-dev-list; Fri, 19 Nov 1999 13:48:23 -0500
Received: from smtp.mail.yahoo.com (smtp.mail.yahoo.com [128.11.68.32]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA08530 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 19 Nov 1999 13:48:20 -0500
Received: from modem26-cisco7.sinectis.com.ar (HELO yahoo.com) (200.41.200.26)
  by smtp.mail.yahoo.com with SMTP; 19 Nov 1999 10:43:14 -0800
X-Apparently-From: <luispagasparotto@yahoo.com>
Message-ID: <383598F8.24A75AE7@yahoo.com>
Date: Fri, 19 Nov 1999 15:37:45 -0300
From: Luis Pablo Gasparotto <luispagasparotto@yahoo.com>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Linux Audio Devices Mail <linux-audio-dev@ginette.musique.umontreal.ca>,
        Multisound Mailing List <MULTISOUND@MAILLIST.VOYETRA.COM>,
        Red Hat List <redhat-list@redhat.com>
Subject: [linux-audio-dev] Fiji errors under Linux
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: ed7df89b418abf616bfac44a2116577b

Hi all!

Ive recently compiled the 2.2.12 Kernel with Loadable Module Support
and the following modules:
    soundcore
    msnd
    msnd_pinnacle
 to use my Fiji under Linux.

I can install soundcore and msnd modules with no problem. But when I try
to install
the msnd_pinnacle module this happens:

insmod msnd_pinnacle cfg=0x260 io=0x290 irq=11 mem=0xd8000

msnd_pinnacle : DSP reset failed
msnd_pinnacle : Attach failed
/lib/modules/2.2.12/misc/msnd_pinnacle.o : init_module : Device or
resource busy.

Windows Fiji settings are:

irq=11
io=290-297
io=260-262
mem=d8000-dffff

Thank you very much.

Luis Pablo.





__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

From - Mon Nov 22 11:43:59 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA30139
	for <slinkp@ulster.net>; Fri, 19 Nov 1999 14:14:06 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA08508 for linux-audio-dev-list; Fri, 19 Nov 1999 13:44:31 -0500
Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA08505 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 19 Nov 1999 13:44:27 -0500
Received: from d1o43.telia.com (d1o43.telia.com [194.22.195.241])
	by mailf.telia.com (8.9.3/8.9.3) with ESMTP id TAA19678;
	Fri, 19 Nov 1999 19:39:17 +0100 (CET)
Received: from norran.net (roger@t2o43p11.telia.com [194.22.195.71])
	by d1o43.telia.com (8.8.8/8.8.8) with ESMTP id TAA14467;
	Fri, 19 Nov 1999 19:39:14 +0100 (CET)
Message-ID: <3835A267.3B901821@norran.net>
Date: Fri, 19 Nov 1999 20:17:59 +0100
From: Roger Larsson <roger.larsson@norran.net>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Benno Senoner <sbenno@gardena.net>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] lowlat-2.2.13-A1
References: <38346DEF.9D482EC1@norran.net> <99111910275203.00989@mtg150.upf.es> <99111915333600.01082@smp.localnet.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: b115e07ff89b9dafc034ae18f92050e1

Hi,

Info about this patch was posted by Ingo on linux-kernel.
This part is from my announcement of latency-profiling posted
earlier on linux-audio-dev.

--
Since Ingo Molnar has released a 2.2.13 version of his
lowlatency patch.
  http://www.redhat.com/~mingo/lowlatency-2.2.13-A1
  (Note: fails on tty_io.c ...)
--


/RogerL

From - Wed Nov 24 02:21:53 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA19076
	for <slinkp@ulster.net>; Tue, 23 Nov 1999 15:44:51 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA07235 for linux-audio-dev-list; Tue, 23 Nov 1999 15:11:54 -0500
Received: from smtp.tiscalinet.it (fornax.tiscalinet.it [195.130.224.67]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA07232 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 23 Nov 1999 15:11:52 -0500
Received: (qmail 27430 invoked by uid 7770); 23 Nov 1999 18:49:27 -0000
Received: from mi2-356.tiscalinet.it (HELO tiscalinet.it) (212.123.69.230)
  by fornax.tiscalinet.it with SMTP; 23 Nov 1999 18:49:27 -0000
Message-ID: <3839CDA3.AC250B5@tiscalinet.it>
Date: Tue, 23 Nov 1999 00:11:31 +0100
From: cafu <gabriele.cafu@tiscalinet.it>
X-Mailer: Mozilla 4.6 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: lad <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Newby(t)e
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 8a0d0fad63c7e1e789d24b7bece84866

hi all.
I'm new to this list, and, after a couple of weeks of lurking I'm ready
for a couple of questions...
ready, set, go!
BTW (sorry for my english, but, you can see... i'm from Italia...)

1) were can I find FAQ for this list?
2) Since I'm starting a new project in C, i wanted to know wich type are
best suited for audio DSP under linux ... longint, float ??? wich one do
U use for your project???
3) I'm gonna to implement a DirecX-like plugins system on a Audio App...
is already something like this out there ?? I haven't still  see
anything but if I'm really the first one thinking about it.... i would
really need your help...
let me know
TIA
gabriele

PS.
few notes 'bout me:
I live in milano, Italy
Student of Telecomunications Ing. at Politecnico di Milano
Now working at Telecom Italia (always looking for a better job ;) )
In my free time I play with my Linuxstation (RH 6.1 on a 200MMX 64MB
soon will become a dualCelly@550 with 160 Meg)

-- 
----------------------------+     scafuz!        [-]
Pensavo...  bello che dove +----------------ooO-  v  -Ooo-+ 
finiscono le mie dita debba in qualche            (;)      |
modo cominciare una chitarra (F.de Andr)                  |

From - Mon Nov 29 01:10:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA29056
	for <slinkp@ulster.net>; Wed, 24 Nov 1999 15:30:18 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA13370 for linux-audio-dev-list; Wed, 24 Nov 1999 14:56:41 -0500
Received: from smtp.tiscalinet.it (fornax.tiscalinet.it [195.130.224.67]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id OAA13367 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 24 Nov 1999 14:56:37 -0500
Received: (qmail 4650 invoked by uid 7770); 24 Nov 1999 19:51:16 -0000
Received: from unknown (HELO tiscalinet.it) (62.11.56.93)
  by fornax.tiscalinet.it with SMTP; 24 Nov 1999 19:51:16 -0000
Message-ID: <3839CDA3.AC250B5@tiscalinet.it>
Date: Tue, 23 Nov 1999 00:11:31 +0100
From: cafu <gabriele.cafu@tiscalinet.it>
X-Mailer: Mozilla 4.6 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: lad <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Newby(t)e
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 25561300ec52a3e531ab2357f25a2288

hi all.
I'm new to this list, and, after a couple of weeks of lurking I'm ready
for a couple of questions...
ready, set, go!
BTW (sorry for my english, but, you can see... i'm from Italia...)

1) were can I find FAQ for this list?
2) Since I'm starting a new project in C, i wanted to know wich type are
best suited for audio DSP under linux ... longint, float ??? wich one do
U use for your project???
3) I'm gonna to implement a DirecX-like plugins system on a Audio App...
is already something like this out there ?? I haven't still  see
anything but if I'm really the first one thinking about it.... i would
really need your help...
let me know
TIA
gabriele

PS.
few notes 'bout me:
I live in milano, Italy
Student of Telecomunications Ing. at Politecnico di Milano
Now working at Telecom Italia (always looking for a better job ;) )
In my free time I play with my Linuxstation (RH 6.1 on a 200MMX 64MB
soon will become a dualCelly@550 with 160 Meg)

-- 
----------------------------+     scafuz!        [-]
Pensavo...  bello che dove +----------------ooO-  v  -Ooo-+ 
finiscono le mie dita debba in qualche            (;)      |
modo cominciare una chitarra (F.de Andr)                  |

From - Wed Nov 24 02:21:58 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA05064
	for <slinkp@ulster.net>; Tue, 23 Nov 1999 20:58:53 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA07616 for linux-audio-dev-list; Tue, 23 Nov 1999 20:33:52 -0500
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA07613 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 23 Nov 1999 20:33:49 -0500
Received: from localhost.localdomain (d212-151-100-124.swipnet.se [212.151.100.124]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id CAA02214; 
          Wed, 24 Nov 1999 02:28:08 +0100 (MET)
From: David Olofson <audiality@swipnet.se>
To: cafu <gabriele.cafu@tiscalinet.it>,
        lad <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Newby(t)e
Date: Wed, 24 Nov 1999 02:12:28 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <3839CDA3.AC250B5@tiscalinet.it>
In-Reply-To: <3839CDA3.AC250B5@tiscalinet.it>
MIME-Version: 1.0
Message-Id: <99112402365500.00544@localhost.localdomain>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA05064
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1e5f75ec36035e4f30795b079f52833c

On Tue, 23 Nov 1999, cafu wrote:
> 1) were can I find FAQ for this list?

Um, is there one, actually?

> 2) Since I'm starting a new project in C, i wanted to know wich type are
> best suited for audio DSP under linux ... longint, float ??? wich one do
> U use for your project???

Float for the intermediate buffers and double for the internal
calculations in plugins is more or less standard for native
processing these days. You don't want to mess with integer/fixed
point processing unless you have no alternative. Also, FPUs are
very fast already, and then there are the new SIMD instruction
sets... (KNI, 3DNow!,...)

> 3) I'm gonna to implement a DirecX-like plugins system on a Audio App...
> is already something like this out there ?? I haven't still  see
> anything but if I'm really the first one thinking about it.... i would
> really need your help...

We're working on it! :-)

It's called MuCoS (the Multimedia Communication System) until we find
a better name, and I was supposed to have had the site up already.
However, everything got in the way as usual...

Basically, it's a plugin API similar to VST, but cleaner, and built
around an event system (timestamped events, somewhat similar to those
of VST 2.0). Large parts of that API will also be used for an
interprocess communication system, allowing applications to connect
to each other and to dedicated engine daemons, and even to plugins
inside other applications.

The API itself will not depend on any existing standards or OS
subsystems, so it'll be no problem building plugin hosts for other
environments, or even as a Linux kernel module - perhaps using
RTLinux for timing in the s range. (That's where I started, before
the excellent lowlatency patch by Ingo Molnar... :-)

Working on MuCoS:

  Paul Barton-Davis <pbd@op.net>
	* An engine implementation, doubling as plugin API testbed.
	* Quasimodo and some other applications.

  David Olofson <audiality@swipnet.se> (Me, that is.)
	* Another engine; a softsynth with some effects,
	  meant primarily as a prototype.
	* The MuCoS web site and documentation.

  Benno Senoner <sbenno@gardena.net>
	* Client/server implementation and API.
	* Various performance testing tools.
	* Some demonstration/proof-of-concept programs.

  Anyone else? (No specs released yet...)


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Wed Nov 24 02:22:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA17943
	for <slinkp@ulster.net>; Tue, 23 Nov 1999 22:23:28 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA07758 for linux-audio-dev-list; Tue, 23 Nov 1999 22:01:30 -0500
Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA07755 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 23 Nov 1999 22:01:26 -0500
Received: from muse.demon.co.uk ([158.152.21.220] helo=bartman.plc.psion.com)
	by finch-post-11.mail.demon.net with smtp (Exim 2.12 #1)
	id 11qSbL-000Cnb-0B; Wed, 24 Nov 1999 02:56:11 +0000
Received: by bartman.plc.psion.com with Microsoft Mail
	id <01BF3626.C13CAEE0@bartman.plc.psion.com>; Wed, 24 Nov 1999 02:51:06 -0000
Message-ID: <01BF3626.C13CAEE0@bartman.plc.psion.com>
From: "Richard W.E. Furse" <richard@muse.demon.co.uk>
To: "'David Olofson'" <audiality@swipnet.se>,
        cafu
	 <gabriele.cafu@tiscalinet.it>,
        lad
	 <linux-audio-dev@ginette.musique.umontreal.ca>,
        "'pbd@op.net'"
	 <pbd@Op.Net>
Subject: MNLib, RE: [linux-audio-dev] Newby(t)e
Date: Wed, 24 Nov 1999 02:49:51 -0000
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 57220711ce7ef3ee1ac4c01da5a3c802

Hmm. Time I spoke up and made myself and an audio processing library 
(MNLib) a little more visible among the Linux audio community. Also, if 
people are agreeing a way of interfacing audio programs with one another 
I'd be VERY interested in contributing to the discussion because of my own 
developments.

Maybe I should release some of the internal specs for MNLib soon - there's 
some background at http://www.muse.demon.co.uk/mn_index.html and a number 
of programs built with it, but the library itself is still rather concealed 
from view. Internally there are echoes of systems like Csound or Max but 
with a more generalised but potentially more efficient approach. Ideas 
currently implemented include latency, feedback, configurability, grouping, 
modularity, persistence, a number of mechanisms for automated data exchange 
and much more. The engine is built to run real-time and some aspects of the 
optimisation approach taken can only be described as brutal. Next step is 
to write a generic server wrapper and a small GUI (probably Java) to allow 
a Max-like interface to the system.

I've not written too many processing classes for the system yet and about 
half of these relate to acoustic space modelling, though there are some 
nice Z-plane sidelines. FFT is probably next - it's taken me a while to 
find a model that feels right but I think I'm there. It would probably not 
be hard to convert Max patches and packages for MNLib too - that could be 
fun. Eventually writing audio/MIDI sequencers shouldn't be too hard working 
with a Java applet (or suchlike) linking to a MNLib server. I'm hanging on 
to the source code for the moment as I'd like at least to get a paper or 
two out of the years of work I've put into this, but there will probably be 
enough of a public API to write client apps for the server.

I've not publicised MNLib much before because I'm not into pushing 
vapourware, however I've been on a 'sabbatical' from work for the past 
seven months and a lot of that time has been spent composing and sorting 
out issues with MNLib. Over the past couple of weeks there have been some 
fundamental breakthroughs (internal and quite separate from my work with 
Ambisonics) so the whole project is suddenly very real.

Ideas & thoughts more than welcome,

(Oh incidentally, I'm using single precision floats except for sensitive 
calculations such as matrix maths. I'd have thought use of doubles for 
general signal processing would be rather costly?)

-- Richard

-----Original Message-----
From:	David Olofson [SMTP:audiality@swipnet.se]
Sent:	Wednesday, November 24, 1999 1:12 AM
To:	cafu; lad
Subject:	Re: [linux-audio-dev] Newby(t)e

On Tue, 23 Nov 1999, cafu wrote:
> 1) were can I find FAQ for this list?

Um, is there one, actually?

> 2) Since I'm starting a new project in C, i wanted to know wich type are
> best suited for audio DSP under linux ... longint, float ??? wich one do
> U use for your project???

Float for the intermediate buffers and double for the internal
calculations in plugins is more or less standard for native
processing these days. You don't want to mess with integer/fixed
point processing unless you have no alternative. Also, FPUs are
very fast already, and then there are the new SIMD instruction
sets... (KNI, 3DNow!,...)

> 3) I'm gonna to implement a DirecX-like plugins system on a Audio App...
> is already something like this out there ?? I haven't still  see
> anything but if I'm really the first one thinking about it.... i would
> really need your help...

We're working on it! :-)

It's called MuCoS (the Multimedia Communication System) until we find
a better name, and I was supposed to have had the site up already.
However, everything got in the way as usual...

Basically, it's a plugin API similar to VST, but cleaner, and built
around an event system (timestamped events, somewhat similar to those
of VST 2.0). Large parts of that API will also be used for an
interprocess communication system, allowing applications to connect
to each other and to dedicated engine daemons, and even to plugins
inside other applications.

The API itself will not depend on any existing standards or OS
subsystems, so it'll be no problem building plugin hosts for other
environments, or even as a Linux kernel module - perhaps using
RTLinux for timing in the ?s range. (That's where I started, before
the excellent lowlatency patch by Ingo Molnar... :-)

Working on MuCoS:

  Paul Barton-Davis <pbd@op.net>
	* An engine implementation, doubling as plugin API testbed.
	* Quasimodo and some other applications.

  David Olofson <audiality@swipnet.se> (Me, that is.)
	* Another engine; a softsynth with some effects,
	  meant primarily as a prototype.
	* The MuCoS web site and documentation.

  Benno Senoner <sbenno@gardena.net>
	* Client/server implementation and API.
	* Various performance testing tools.
	* Some demonstration/proof-of-concept programs.

  Anyone else? (No specs released yet...)


//David


 .A.U.D.I.A.L.I.T.Y.   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    .Rock Solid                                      David Olofson:
    .Low Latency    www.angelfire.com/or/audiality   .Audio Hacker
    .Plug-Ins            audiality@swipnet.se        .Linux Advocate
    .Open Source                                     .Singer/Composer

From - Mon Nov 29 01:10:22 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA10532
	for <slinkp@ulster.net>; Wed, 24 Nov 1999 09:56:00 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA12804 for linux-audio-dev-list; Wed, 24 Nov 1999 09:22:05 -0500
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA12801 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 24 Nov 1999 09:21:59 -0500
Received: (from sbenno@localhost)
	by em.gardena.net (8.9.1/8.9.0) id PAA04179;
	Wed, 24 Nov 1999 15:15:22 +0100
From: Benno Senoner <sbenno@em.gardena.net>
Message-Id: <199911241415.PAA04179@em.gardena.net>
Subject: Re: [linux-audio-dev] Newby(t)e
To: audiality@swipnet.se (David Olofson)
Date: Wed, 24 Nov 1999 15:15:22 +0100 (MET)
Cc: gabriele.cafu@tiscalinet.it, linux-audio-dev@ginette.musique.umontreal.ca
In-Reply-To: <99112402365500.00544@localhost.localdomain> from "David Olofson" at Nov 24, 99 02:12:28 am
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 89718886b79ddf23702c0640021a4d48

> 
>   Benno Senoner <sbenno@gardena.net>
> 	* Client/server implementation and API.
> 	* Various performance testing tools.
> 	* Some demonstration/proof-of-concept programs.
> 

I got a client/server implementation hack running,
using sharedmem +SYS V sempaphores:
(semop)
but still many problems:
on my celeron box, when running on an idle system,
I get no droputs using a 2.8ms audio buffer with server
and clients exchanging 128bytes at time.
But when I put some load on the box there are audible dropouts.

Using 2 clients the semaphores deadlock after a while with the server waiting
for the clients and the clients waiting for servers.

I will try to do some tests using threads instead of processes
and pthread_mutex instead of semaphores, lewt's see if this 
gets better.
But as far I know there should not be much
difference since threads and processes are almost the same on
linux.

When I will get all the testing stuff togheter  I will do
a detailed explanation of the test.
I'm not sure if this semaphore deadlock is really my
own fault (programming mistake) or a kernel bug ...
we will see. (I will CC linux-kernel as well ..)
As for the latency in semaphore code I'm confident that Ingo will
find the place where to add the scheduler hookup,
in order to get down to our 2ms standard.

Benno.

From - Mon Nov 29 01:10:25 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA21016
	for <slinkp@ulster.net>; Wed, 24 Nov 1999 11:04:54 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA12942 for linux-audio-dev-list; Wed, 24 Nov 1999 10:32:19 -0500
Received: from alsa.alsa-project.org (alsa.jcu.cz [160.217.1.49]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA12939 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 24 Nov 1999 10:32:15 -0500
Received: from localhost (andy@localhost)
	by alsa.alsa-project.org (8.8.8/8.8.8) with ESMTP id QAA19574;
	Wed, 24 Nov 1999 16:26:31 +0100
Date: Wed, 24 Nov 1999 16:26:31 +0100 (MET)
From: Andy Lo A Foe <andy@alsa-project.org>
To: Benno Senoner <sbenno@em.gardena.net>
cc: David Olofson <audiality@swipnet.se>, gabriele.cafu@tiscalinet.it,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Newby(t)e
In-Reply-To: <199911241415.PAA04179@em.gardena.net>
Message-ID: <Pine.LNX.4.05.9911241624130.18756-100000@alsa.alsa-project.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5bc2d1dd828e495f698af23f0f39067d

On Wed, 24 Nov 1999, Benno Senoner wrote:

> I'm not sure if this semaphore deadlock is really my
> own fault (programming mistake) or a kernel bug ...

In experimental threading code that deadlocks the last place you should
look for bugs is in the kernel. I've had many occasions where I'd just say
that the kernel semaphore implementation is buggy only to find out it was
yet another loophole in my own code. Just a suggestion :)

Andy
--
AlsaPlayer, http://www.alsa-project.org/~andy/

From - Mon Nov 29 01:11:57 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA17604
	for <slinkp@ulster.net>; Sat, 27 Nov 1999 10:32:10 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA00874 for linux-audio-dev-list; Sat, 27 Nov 1999 10:07:34 -0500
Received: from www.tomy.net (www.tomy.net [209.186.149.104]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA00871 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 27 Nov 1999 10:07:28 -0500
Received: from cygnus.com (IDENT:thudson@jimi.tomy.net [192.168.1.2])
	by www.tomy.net (8.9.3/8.9.3) with ESMTP id DAA03312;
	Sat, 27 Nov 1999 03:49:57 -0500
Message-ID: <383FAC0E.8B8B8FA5@cygnus.com>
Date: Sat, 27 Nov 1999 05:01:50 -0500
From: Thomas Hudson <thudson@cygnus.com>
Organization: Cygnus Solutions
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: lad <linux-audio-dev@ginette.musique.umontreal.ca>,
        "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Subject: [linux-audio-dev] [Fwd: Fw:  Save OMS! Sauvez OMS! [ot]]
Content-Type: multipart/mixed;
 boundary="------------4C3889114916A853C804BB7C"
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 3383eb3c6f1eb644b32bb45cd8636ee8

This is a multi-part message in MIME format.
--------------4C3889114916A853C804BB7C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

 
--------------4C3889114916A853C804BB7C
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Return-Path: <owner-music-dsp@shoko.calarts.edu>
Received: from localhost (IDENT:thudson@localhost [127.0.0.1])
	by www.tomy.net (8.9.3/8.9.3) with ESMTP id SAA02978
	for <thudson@localhost>; Fri, 26 Nov 1999 18:45:53 -0500
Received: from mailhost.cygnus.com
	by localhost with POP3 (fetchmail-5.0.0)
	for thudson@localhost (single-drop); Fri, 26 Nov 1999 18:45:53 -0500 (EST)
Received: from shoko.calarts.edu (shoko.calarts.edu [156.3.140.104])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id VAA15539
	for <thudson@cygnus.com>; Fri, 26 Nov 1999 21:54:38 -0800 (PST)
Received: (from majordom@localhost)
	by shoko.calarts.edu (8.9.3/8.9.3) id VAA12341
	for music-dsp-outgoing; Fri, 26 Nov 1999 21:52:03 -0800 (PST)
Received: from 3deeptech.it-au.com (www.3deep.com.au [202.3.41.130])
	by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id VAA12337
	for <music-dsp@shoko.calarts.edu>; Fri, 26 Nov 1999 21:51:59 -0800 (PST)
Received: from rossbenc (unverified [203.152.255.41]) by 3deeptech.it-au.com
 (Rockliffe SMTPRA 3.4.2) with SMTP id <B0000050489@3deeptech.it-au.com>;
 Sat, 27 Nov 1999 17:08:31 +1100
X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f
Message-ID: <006801bf389b$0625f360$29ff98cb@rossbenc>
From: "Ross Bencina" <rossb@audiomulch.com>
To: "Music Dsp List" <music-dsp@shoko.calarts.edu>, <cecdiscuss@concordia.ca>
Subject: Fw:  Save OMS! Sauvez OMS! [ot]
Date: Sat, 27 Nov 1999 16:18:24 +1030
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-music-dsp@shoko.calarts.edu
Precedence: bulk
Reply-To: music-dsp@shoko.calarts.edu
Content-Type: text/plain;
	charset="iso-8859-1"

>Date:    Fri, 26 Nov 1999 18:40:36 +0000
>From:    Roald Baudoux <roald.baudoux@BRUTELE.BE>
>Subject: Save OMS! Sauvez OMS!
>
>On the following website is a petition to save OMS from Opcode's wreck
>which asks Gibson to release the source code to the public domain under a
>license such as the GNU Public License.
>
>Il y a sur ce site une p=E9tition pour sauver OMS du naufrage d'Opcode,
>p=E9tition qui propose =E0 Gibson de faire passer le code source dans le
>domaine public sous licence de type GNU.
>
>http://sonosphere.dyndns.org/Petition
>
>Roald Baudoux



dupswapdrop -- the music-dsp mailing list and website: subscription info,
FAQ, source code archive, list archive, book reviews, dsp links
http://shoko.calarts.edu/musicdsp/


--------------4C3889114916A853C804BB7C--

From - Mon Nov 29 01:11:59 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA23629
	for <slinkp@ulster.net>; Sat, 27 Nov 1999 11:37:26 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA00977 for linux-audio-dev-list; Sat, 27 Nov 1999 11:09:45 -0500
Received: from maelzel.ircam.fr (maelzel.ircam.fr [129.102.1.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA00974 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 27 Nov 1999 11:09:42 -0500
Received: from ircam.fr (ppp-port2.ircam.fr [129.102.49.102])
Message-ID: <38400122.F396733A@ircam.fr>
Date: Sat, 27 Nov 1999 17:04:50 +0100
From: Francois Dechelle <Francois.Dechelle@ircam.fr>
Reply-To: Francois.Dechelle@ircam.fr
Organization: IRCAM
X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686)
MIME-Version: 1.0
To: MAX@LISTS.MCGILL.CA
CC: lad <linux-audio-dev@ginette.musique.umontreal.ca>,
        "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Subject: Re: [linux-audio-dev] [Fwd: Fw:  Save OMS! Sauvez OMS! [ot]]
References: <383FAC0E.8B8B8FA5@cygnus.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: de40cd9a76226e8a69c3f6877b3af3c0

Thomas Hudson wrote:
> >Date:    Fri, 26 Nov 1999 18:40:36 +0000
> >From:    Roald Baudoux <roald.baudoux@BRUTELE.BE>
> >Subject: Save OMS! Sauvez OMS!
> >
> >On the following website is a petition to save OMS from Opcode's wreck
> >which asks Gibson to release the source code to the public domain under a
> >license such as the GNU Public License.
> >
> >Il y a sur ce site une p=E9tition pour sauver OMS du naufrage d'Opcode,
> >p=E9tition qui propose =E0 Gibson de faire passer le code source dans le
> >domaine public sous licence de type GNU.
> >
> >http://sonosphere.dyndns.org/Petition
> >
> >Roald Baudoux

Dear all,

There is already a software that does more or less what OMS 
does and that is free software, distributed under GNU Lesser 
General Public License. It is MidiShare, by Grame. See 
http://www.grame.fr/MidiShare/MidiShare.html for further
information.

Francois

From - Mon Nov 29 01:12:01 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA26508
	for <slinkp@ulster.net>; Sat, 27 Nov 1999 18:12:49 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA01554 for linux-audio-dev-list; Sat, 27 Nov 1999 17:44:48 -0500
Received: from gauss.deltav.hu (gauss.deltav.hu [194.9.64.225]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA01551 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 27 Nov 1999 17:44:45 -0500
Received: from boksi (70.dial02.deltav.hu [194.9.64.70]) by gauss.deltav.hu
          (Netscape Messaging Server 3.6)  with ESMTP id AAA28D9
          for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Sat, 27 Nov 1999 23:43:18 +0100
Received: from reactor by boksi with local (Exim 1.92 #1 (Debian))
	id 11rqcD-00003O-00; Sat, 27 Nov 1999 23:46:49 +0100
Message-ID: <19991127234649.A201@boksi>
Date: Sat, 27 Nov 1999 23:46:49 +0100
From: reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] sblive + alsa
Reply-To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91.2
Organization: CTP media laboratories
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 2c2cee69962920d15073cd6bbfd8d29f

yo!

when will ALSA dudez import the sblive stuff into ALSA?
it's opensource, isn't it?

bye!

-- 

(reactor/CTPmedia) (http://linux.gyakg.u-szeged.hu/~reactor/index.html)
(linux audiowarez) (http://www.bright.net/~dlphilp/linuxsound/toc.html)

From - Mon Nov 29 01:12:06 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA02981
	for <slinkp@ulster.net>; Sat, 27 Nov 1999 19:52:30 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA01685 for linux-audio-dev-list; Sat, 27 Nov 1999 19:32:47 -0500
Received: from anime.net (anime.net [205.139.105.150]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA01682 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 27 Nov 1999 19:32:44 -0500
Received: from localhost (goemon@localhost)
	by anime.net (8.9.3/8.9.3) with ESMTP id QAA12659;
	Sat, 27 Nov 1999 16:27:12 -0800
Date: Sat, 27 Nov 1999 16:27:12 -0800 (PST)
From: Dan Hollis <goemon@sasami.anime.net>
X-Sender: goemon@anime.net
To: reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>
cc: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] sblive + alsa
In-Reply-To: <19991127234649.A201@boksi>
Message-ID: <Pine.LNX.4.10.9911271626020.12413-100000@anime.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: a750c55a6e7226bd23b78d5ed0a741dd

On Sat, 27 Nov 1999, reactor/CTPmedia wrote:
> when will ALSA dudez import the sblive stuff into ALSA?
> it's opensource, isn't it?

ALSA has had an sblive driver since 11-18-99. You could have bothered
looking at http://www.alsa-project.org/

-Dan

From - Mon Nov 29 01:12:12 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA30010
	for <slinkp@ulster.net>; Sun, 28 Nov 1999 11:04:16 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA06387 for linux-audio-dev-list; Sun, 28 Nov 1999 10:40:59 -0500
Received: from www.tomy.net (www.tomy.net [209.186.149.104]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA06384 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 28 Nov 1999 10:40:56 -0500
Received: from cygnus.com (IDENT:thudson@jimi.tomy.net [192.168.1.2])
	by www.tomy.net (8.9.3/8.9.3) with ESMTP id EAA04605;
	Sun, 28 Nov 1999 04:21:39 -0500
Message-ID: <38410503.F9EACB43@cygnus.com>
Date: Sun, 28 Nov 1999 05:33:39 -0500
From: Thomas Hudson <thudson@cygnus.com>
Organization: Cygnus Solutions
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Francois.Dechelle@ircam.fr
CC: MAX@LISTS.MCGILL.CA, lad <linux-audio-dev@ginette.musique.umontreal.ca>,
        "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Subject: Re: [linux-audio-dev] [Fwd: Fw:  Save OMS! Sauvez OMS! [ot]]
References: <383FAC0E.8B8B8FA5@cygnus.com> <38400122.F396733A@ircam.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0b8099064831d06d71ffcba3a196aea9

Francois Dechelle wrote:
>
> There is already a software that does more or less what OMS
> does and that is free software, distributed under GNU Lesser
> General Public License. It is MidiShare, by Grame. See
> http://www.grame.fr/MidiShare/MidiShare.html for further
> information.
> 
I didn't know that midishare implemented all the functionality
of OMS. One of the pieces that I thought OMS implemented that
is missing from the linux world is the ability of the user to
describe his setup of connected midi devices. It would be nice
if every application could present input and output choices
as real devices rather than card/port/channel numbers. 

If OMS were open-sourced, the good parts could be integrated
with other projects like MidiShare.

Thomas

From - Mon Nov 29 01:12:09 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id IAA17404
	for <slinkp@ulster.net>; Sun, 28 Nov 1999 08:12:19 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id HAA06218 for linux-audio-dev-list; Sun, 28 Nov 1999 07:47:13 -0500
Received: from gauss.deltav.hu (gauss.deltav.hu [194.9.64.225]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA06215 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 28 Nov 1999 07:47:09 -0500
Received: from boksi (68.dial02.deltav.hu [194.9.64.68]) by gauss.deltav.hu
          (Netscape Messaging Server 3.6)  with ESMTP id AAA2E79
          for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Sun, 28 Nov 1999 13:45:47 +0100
Received: from reactor by boksi with local (Exim 1.92 #1 (Debian))
	id 11s3lb-0000I7-00; Sun, 28 Nov 1999 13:49:23 +0100
Message-ID: <19991128134923.A1101@boksi>
Date: Sun, 28 Nov 1999 13:49:23 +0100
From: reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] sblive + alsa
Reply-To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91.2
Organization: CTP media laboratories
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 06e32b9dc24d9e4d9b967568dad2f5e3

 >% ALSA has had an sblive driver since 11-18-99. You could have bothered
 >% looking at http://www.alsa-project.org/

ok.
i always watch the new announcements on Freshmeat, but none of them
mentioned sblive, so i asked here. sorry.

-- 

(reactor/CTPmedia) (http://linux.gyakg.u-szeged.hu/~reactor/index.html)
(linux audiowarez) (http://www.bright.net/~dlphilp/linuxsound/toc.html)

From - Mon Nov 29 01:12:14 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA05843
	for <slinkp@ulster.net>; Sun, 28 Nov 1999 17:34:46 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA06779 for linux-audio-dev-list; Sun, 28 Nov 1999 17:11:20 -0500
Received: from www.tomy.net (www.tomy.net [209.186.149.104]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA06776 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 28 Nov 1999 17:11:17 -0500
Received: from tomy.net (IDENT:thudson@jimi.tomy.net [192.168.1.2])
	by www.tomy.net (8.9.3/8.9.3) with ESMTP id KAA05026;
	Sun, 28 Nov 1999 10:53:37 -0500
Message-ID: <384160D2.92979FB0@tomy.net>
Date: Sun, 28 Nov 1999 12:05:22 -0500
From: Thomas Hudson <thudson@tomy.net>
Organization: Cygnus Solutions
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: alsa-devel@alsa-project.org
CC: lad <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [alsa-devel] Re: [linux-audio-dev] [Fwd: Fw:  Save OMS! Sauvez OMS! 
 [ot]]
References: <383FAC0E.8B8B8FA5@cygnus.com> <38400122.F396733A@ircam.fr> <38410503.F9EACB43@cygnus.com> <38416859.81636A62@ircam.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1d26344c3b656fbbcfab3b01f5e5a9dd

Francois Dechelle wrote:
>
> But there may be a good joke to do: building an emulation
> of the OMS API using MidiShare (or another free MIDI
> framework). This way, applications do not have to be modified
> (which will anyway not happen because they are proprietary),
> we don't care about Gibson and the MIDI framework is free.
> 
> What do you think of this ?
>
This would probably be worth doing. Considering what
I know about Gibson's reputation,  it is highly unlikely
that they would open OMS. It would be nice to see the
API completely reimplemented as a result of their decision.

I'm sure most ISV's would jump at the chance to move to
a truly "open" OMS. 

Is it possible to get API specs?

Thomas

From - Mon Nov 29 01:12:13 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA10654
	for <slinkp@ulster.net>; Sun, 28 Nov 1999 13:14:42 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA06511 for linux-audio-dev-list; Sun, 28 Nov 1999 12:42:35 -0500
Received: from maelzel.ircam.fr (maelzel.ircam.fr [129.102.1.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA06508 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 28 Nov 1999 12:42:32 -0500
Received: from ircam.fr (ppp-port2.ircam.fr [129.102.49.102])
Message-ID: <38416859.81636A62@ircam.fr>
Date: Sun, 28 Nov 1999 18:37:29 +0100
From: Francois Dechelle <Francois.Dechelle@ircam.fr>
Reply-To: Francois.Dechelle@ircam.fr
Organization: IRCAM
X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686)
MIME-Version: 1.0
To: Thomas Hudson <thudson@cygnus.com>
CC: MAX@LISTS.MCGILL.CA, lad <linux-audio-dev@ginette.musique.umontreal.ca>,
        "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Subject: Re: [linux-audio-dev] [Fwd: Fw:  Save OMS! Sauvez OMS! [ot]]
References: <383FAC0E.8B8B8FA5@cygnus.com> <38400122.F396733A@ircam.fr> <38410503.F9EACB43@cygnus.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7ffca461ee019d722a7e799ecac85bb4

Thomas Hudson wrote:
> 
> Francois Dechelle wrote:
> >
> > There is already a software that does more or less what OMS
> > does and that is free software, distributed under GNU Lesser
> > General Public License. It is MidiShare, by Grame. See
> > http://www.grame.fr/MidiShare/MidiShare.html for further
> > information.
> >
> I didn't know that midishare implemented all the functionality
> of OMS. One of the pieces that I thought OMS implemented that
> is missing from the linux world is the ability of the user to
> describe his setup of connected midi devices. It would be nice
> if every application could present input and output choices
> as real devices rather than card/port/channel numbers.
> 
> If OMS were open-sourced, the good parts could be integrated
> with other projects like MidiShare.
> 
> Thomas

Hi,

This feature is present in midishare, and midishare exists
now on linux.

However, MidiShare simply cannot replace OMS and vice/versa, 
mainly because of applications that are build using the OMS 
API. 

But there may be a good joke to do: building an emulation
of the OMS API using MidiShare (or another free MIDI 
framework). This way, applications do not have to be modified
(which will anyway not happen because they are proprietary),
we don't care about Gibson and the MIDI framework is free.

What do you think of this ?

Francois

From - Mon Nov 29 16:17:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id EAA30605
	for <slinkp@ulster.net>; Mon, 29 Nov 1999 04:19:55 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id DAA11288 for linux-audio-dev-list; Mon, 29 Nov 1999 03:38:30 -0500
Received: from maelzel.ircam.fr (maelzel.ircam.fr [129.102.1.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA11285 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 29 Nov 1999 03:38:23 -0500
Received: from ircam.fr (ppp-port2.ircam.fr [129.102.49.102])
Message-ID: <38423A4A.EA3E7255@ircam.fr>
Date: Mon, 29 Nov 1999 09:33:14 +0100
From: Francois Dechelle <Francois.Dechelle@ircam.fr>
Reply-To: Francois.Dechelle@ircam.fr
Organization: IRCAM
X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686)
MIME-Version: 1.0
To: Thomas Hudson <thudson@tomy.net>
CC: alsa-devel@alsa-project.org,
        lad <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [alsa-devel] Re: [linux-audio-dev] [Fwd: Fw:  Save OMS! Sauvez OMS!  [ot]]
References: <383FAC0E.8B8B8FA5@cygnus.com> <38400122.F396733A@ircam.fr> <38410503.F9EACB43@cygnus.com> <38416859.81636A62@ircam.fr> <384160D2.92979FB0@tomy.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 66ec91d1ef1a5d408f511e72b4d789f5

Thomas Hudson wrote:
> 
> Francois Dechelle wrote:
> >
> > But there may be a good joke to do: building an emulation
> > of the OMS API using MidiShare (or another free MIDI
> > framework). This way, applications do not have to be modified
> > (which will anyway not happen because they are proprietary),
> > we don't care about Gibson and the MIDI framework is free.
> >
> > What do you think of this ?
> >
> This would probably be worth doing. Considering what
> I know about Gibson's reputation,  it is highly unlikely
> that they would open OMS. It would be nice to see the
> API completely reimplemented as a result of their decision.
> 
> I'm sure most ISV's would jump at the chance to move to
> a truly "open" OMS.
> 
> Is it possible to get API specs?
> 
> Thomas

About Gibson, it is quite sure that OMS will be killed.
So probably thinking of an open solution is safe.

I don't know about the OMS API specs, and there may be
problems here (like API license or NDA), but I'll ask
here if anyone has it. May be the API was public, after
all it is a kind of system library.

Francois

From - Mon Nov 29 16:17:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA23938
	for <slinkp@ulster.net>; Mon, 29 Nov 1999 13:17:53 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA12177 for linux-audio-dev-list; Mon, 29 Nov 1999 12:38:03 -0500
Received: from mx2.imaginet.fr (artemis.imaginet.fr [195.68.75.24]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA12174 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 29 Nov 1999 12:37:57 -0500
Received: from alliance.mandrakesoft.com ([195.68.114.34])
	by mx2.imaginet.fr (8.9.3/8.8.8) with ESMTP id SAA07499;
	Mon, 29 Nov 1999 18:27:49 +0100 (MET)
Received: from ewok.mandrakesoft.com (IDENT:root@ewok.mandrakesoft.com [192.168.1.16])
	by alliance.mandrakesoft.com (8.9.3/8.9.3) with ESMTP id SAA12540;
	Mon, 29 Nov 1999 18:29:10 +0100
Received: (from maurizio@localhost)
	by ewok.mandrakesoft.com (8.9.3/8.9.3) id SAA23247;
	Mon, 29 Nov 1999 18:42:13 +0100
To: linux-audio-dev@ginette.musique.umontreal.ca, jmax@ircam.fr
Subject: [linux-audio-dev] Searching for ...
From: Maurizio DE CECCO <maurizio@mandrakesoft.com>
Date: 29 Nov 1999 18:42:12 +0100
Message-ID: <lg7lj1ry8b.fsf@ewok.mandrakesoft.com>
Lines: 20
X-Mailer: Gnus v5.7/Emacs 20.4
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: c7c60a55e281b92c06dc01c9e8a476db


Sorry for this slightly off-topic question, but i think
these lists are the places where it is more likely to find
an answer.

I am looking for some artists, doing some kind of audio-visual
plastic/installation work, using a complete free software platform.

The ideal case would be some kind of work where there is a tight
integration between the creation itself and the free software
developer community, and a highly visual component of some kind.

Thanks for any help you can give,

       Maurizio


-- 
Maurizio De Cecco
MandrakeSoft 		http://www.mandrakesoft.com/

From - Mon Nov 29 16:17:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA26709
	for <slinkp@ulster.net>; Mon, 29 Nov 1999 13:34:20 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA12241 for linux-audio-dev-list; Mon, 29 Nov 1999 13:08:04 -0500
Received: from altos.deev.com (altos.deev.com [207.253.70.2]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA12238 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 29 Nov 1999 13:08:02 -0500
Received: from [192.168.1.30] (HSE-MTL-ppp30657.qc.sympatico.ca [216.208.236.187]) by altos.deev.com (8.9.3/8.7.3) with ESMTP id NAA20140; Mon, 29 Nov 1999 13:02:23 -0500 (EST)
X-Sender: burtonraw@deev.com
Message-Id: <v04003a08b4686eba46ad@[192.168.1.30]>
In-Reply-To: <lg7lj1ry8b.fsf@ewok.mandrakesoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 29 Nov 1999 13:02:21 -0500
To: Maurizio DE CECCO <maurizio@mandrakesoft.com>,
        linux-audio-dev@ginette.musique.umontreal.ca, jmax@ircam.fr
From: Alex Burton <burton-raw@zeep.com>
Subject: Re: [linux-audio-dev] Searching for ...
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: eac5ec7ed2e41e659089207fc9c7c28f


 Try this: http://www.visualmusic.org/gvm.htm

 all the software (pd/gem) is "free" and open-source, but am not sure about
the actual copyrights.


					Alex.


At 6:42 PM +0100 11/29/99, Maurizio DE CECCO wrote:
>Sorry for this slightly off-topic question, but i think
>these lists are the places where it is more likely to find
>an answer.
>
>I am looking for some artists, doing some kind of audio-visual
>plastic/installation work, using a complete free software platform.
>
>The ideal case would be some kind of work where there is a tight
>integration between the creation itself and the free software
>developer community, and a highly visual component of some kind.
>
>Thanks for any help you can give,
>
>       Maurizio
>
>
>--
>Maurizio De Cecco
>MandrakeSoft 		http://www.mandrakesoft.com/



From - Tue Nov 30 11:35:34 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA00707
	for <slinkp@ulster.net>; Mon, 29 Nov 1999 17:36:32 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA12642 for linux-audio-dev-list; Mon, 29 Nov 1999 17:12:06 -0500
Received: from renoir.op.net (renoir.op.net [207.29.195.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA12639 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 29 Nov 1999 17:11:59 -0500
Received: from op.net (d-bm2-00.ppp.op.net [209.152.194.32]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id RAA03756 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 29 Nov 1999 17:06:20 -0500 (EST)
Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id RAA13691; Mon, 29 Nov 1999 17:07:34 -0500
Date: Mon, 29 Nov 1999 17:07:34 -0500
Message-Id: <199911292207.RAA13691@op.net>
From: Paul Barton-Davis <pbd@Op.Net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] new system - what to buy ?
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: bff20ba629ac48f184e926ecf4c93629

ok, its time for me to order the new machine for the all-or-mostly
linux powered section of my friend's pro-studio. and its *hard*. here
are the contenders, with some notes:

* dual Pentium something-or-other (custom built)
  -------------------------------  

  Pros: like the system i have at home (self-built)
        can use OEM rack-mount case
	nobody was ever fired for buying Intel
	fast enough
	SMP

  Cons: not *that* fast
	can't run commercial audio apps without windows

* single Athlon 700/750 (custom built)
  ---------------------

  Pros: faster than anything from Intel
        a little cheaper too

  Cons: no SMP motherboards (till at least Q3 2000)
        no motherboards with builtin SCSI controllers
	hard to get the processors on their own
	hard to get the motherboards on their own
	can't run commercial audio apps without windows

* Apple G4
  --------

  Pros: possibly faster than anything else
	cheap
	you can get one of Apple's new digital monitors
	you can run commercial apps without running windows

  Cons: linux-ppc is still "unstable"
        full speed needs a new version of gcc
	no SPECfp benchmarks available yet, so we don't know how
		  it is without the Altivec
	hard to buy with custom specs
	no rack-mount options
  
So, does anyone have any opinions on what *they* would do ? I have a
strong preference for an SMP system, but is that the most significant
thing ? Thanks for any feedback. A year ago, this was an easy choice:
the dual Pentium II 450 won easily. This time, it seems much more of a
trade-off.

--p

From - Tue Nov 30 11:35:43 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA00361
	for <slinkp@ulster.net>; Tue, 30 Nov 1999 01:27:55 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id BAA13309 for linux-audio-dev-list; Tue, 30 Nov 1999 01:03:13 -0500
Received: from smtp.mail.yahoo.com (smtp.mail.yahoo.com [128.11.68.32]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id BAA13305 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 30 Nov 1999 01:03:10 -0500
Received: from modem85-cisco14.sinectis.com.ar (HELO yahoo.com) (200.16.128.205)
  by smtp.mail.yahoo.com with SMTP; 29 Nov 1999 21:57:31 -0800
X-Apparently-From: <luispagasparotto@yahoo.com>
Message-ID: <3843670B.77AD356A@yahoo.com>
Date: Tue, 30 Nov 1999 02:56:28 -0300
From: Luis Pablo Gasparotto <luispagasparotto@yahoo.com>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Linux Art <Majordomo@li.org>,
        Linux Audio Devices Mail 
 <linux-audio-dev@ginette.musique.umontreal.ca>,
        Red Hat List <redhat-list@redhat.com>
Subject: [linux-audio-dev] Some questions about timidity and SLab
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: c8c1c8c62a235d1b2485420864dbc3b2

Hi all,

Ive and Pentium 200 MMX with Linux 2.2.12 and TB Fiji soundcard.

Recently I tried to install and use Timidity and it wasnt succesful.

First I configured the source, running configure.bin, then I ran make
and then I ran make install without errors. But when I run timidity.bin
nothing happens.

What did I wrong? Did I forget some step?

Otherwise, I can run SLab with an only problem "Failed to open
dev/audio"
The soundcard works fine with others programs.

What could be the cause?

Thank you very much.

Luis Pablo Gasparotto



__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one place.
Yahoo! Shopping: http://shopping.yahoo.com

From - Tue Nov 30 11:35:46 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id EAA08992
	for <slinkp@ulster.net>; Tue, 30 Nov 1999 04:24:34 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id DAA17285 for linux-audio-dev-list; Tue, 30 Nov 1999 03:49:14 -0500
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA17282 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 30 Nov 1999 03:49:09 -0500
Received: (from sbenno@localhost)
	by em.gardena.net (8.9.1/8.9.0) id JAA21266;
	Tue, 30 Nov 1999 09:43:20 +0100
From: Benno Senoner <sbenno@em.gardena.net>
Message-Id: <199911300843.JAA21266@em.gardena.net>
Subject: Re: [linux-audio-dev] new system - what to buy ?
To: pbd@Op.Net (Paul Barton-Davis)
Date: Tue, 30 Nov 1999 09:43:20 +0100 (MET)
Cc: linux-audio-dev@ginette.musique.umontreal.ca
In-Reply-To: <199911292207.RAA13691@op.net> from "Paul Barton-Davis" at Nov 29, 99 05:07:34 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f0275a157f8451d6612085f08fb2e03f

[ INtel vs AMD vs PPC CPUs ... ]

Paul, I agree on almost all points.

I am looking to the K7 too, but it is still too early
for getting stable , well tested SMP mainboards
for this CPU/BUS.

As you pointed out linux on the PPC is not so well tested
as on x86 hardware, and especially when it comes to audio hardware support.
(Is ALSA working on PPC ?)

The Apple platformm is too closed IMHO, I would prefer
a more open PPC platform (the IBM ones ?).
The main point is that you should concentrate on the audio software issues, 
rather than dealing with problems like hardware support , compiler problems,
sound card support etc.

If I were you , I would buy a well tested SMP dual PIII box, with
onboard UW2 SCSI.
If I had to make this decision 6-9months later , I'd buy an
SMP K7 (perhaps 4way).

The 4way Xeon is to exclude IMHO because the price/performance ratio
simply sucks.

Alpha: powerful platform , but Compaq do not give us full specs,
like optimized compiler techniques , math libs etc.

PPC: powerful too, especially with the new Altivec instruction,
but apple is too closed for my taste, the don't want Linux replacing MacOS.
Other PPC platforms are not widespread enough, that means you
could run into big troubles and no one will be able to help you.
:-)

PS: I really hate x86 assembly , all the x86 baggage,
even the Motorola680x0 (Amiga :-) ) was a dream to program
compared to x86 CPUs.

But actually it's very hard to beat the price/performance ratio of
x86.

Just my two cents. (Or better 36 lire :-) )

Benno.


From - Tue Nov 30 12:15:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA25238
	for <slinkp@ulster.net>; Tue, 30 Nov 1999 12:11:13 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA17988 for linux-audio-dev-list; Tue, 30 Nov 1999 11:41:21 -0500
Received: from durham1-220.dsl.gtei.net (durham1-220.dsl.gtei.net [4.3.1.220]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA17985 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 30 Nov 1999 11:41:17 -0500
Received: from kate.private.net (kate.private.net [192.168.1.2])
	by durham1-220.dsl.gtei.net (Postfix) with ESMTP
	id 4283A2B0EA; Tue, 30 Nov 1999 11:35:12 -0500 (EST)
Received: by kate.private.net (Postfix, from userid 1000)
	id 026A857D48; Tue, 30 Nov 1999 11:35:05 -0500 (EST)
To: Benno Senoner <sbenno@em.gardena.net>
Cc: pbd@Op.Net (Paul Barton-Davis),
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] new system - what to buy ?
References: <199911300843.JAA21266@em.gardena.net>
From: Michael Alan Dorman <mdorman@debian.org>
Date: 30 Nov 1999 11:35:05 -0500
In-Reply-To: Benno Senoner's message of "Tue, 30 Nov 1999 09:43:20 +0100 (MET)"
Message-ID: <87bt8caqfa.fsf@kate.private.net>
Lines: 27
User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1e41650a97ed5c5e9279efb6b67c1c5a

Benno Senoner <sbenno@em.gardena.net> writes:
> If I were you , I would buy a well tested SMP dual PIII box, with
> onboard UW2 SCSI.

Does the desire to have on-board SCSI simply stem from wanting to
conserve slots?

I ask because I've been consistently disappointed with on-board
controllers---they never seem to get firmware updates in a timely
fashion (and I've found firmsare updates to occasionally be important
to correct operation), connector space is often crowded, etc.

I, personally, would rather spec a motherboard with more PCI slots,
and perhaps a multi-channel SCSI card. INITIO makes them, as do
Adaptec and someone's got to have a board based on LSI's 53c896 (I
think it is).

Perhaps my experience is just biased, since I mostly build boxes with
high-end hardware for server situations where I want multipe SCSI
busses (usually multiple cards) for duplexing drives, etc.

Oh, and just an unsolicited plug for California PC Products
(http://www.calpc.com) rack-mount cases---again, I've used them mostly
for server installations, but they've got great cooling, and their
13-bay 8-space case can hold storage for days.

Mike.

From - Tue Nov 30 11:35:38 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA28083
	for <slinkp@ulster.net>; Mon, 29 Nov 1999 20:32:56 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA12968 for linux-audio-dev-list; Mon, 29 Nov 1999 20:09:07 -0500
Received: from zhora.replicant.apana.org.au (replicant.apana.org.au [203.12.238.34]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA12961 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 29 Nov 1999 20:07:43 -0500
Received: (from smap@localhost)
	by zhora.replicant.apana.org.au (8.8.5/8.8.5) id MAA12611;
	Tue, 30 Nov 1999 12:01:14 +1100
Received: from hexdance.replicant.apana.org.au(192.168.200.126) by zhora.replicant.apana.org.au via smap (V1.3)
	id xmac12598; Tue, 30 Nov 99 12:00:48 +1100
Received: (from jlittler@localhost)
	by localhost.localdomain (8.9.3/8.9.3) id EAA00667;
	Wed, 1 Dec 1999 04:35:22 +1100
From: John Littler <linuxmusic@crosswinds.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14404.2758.642143.903323@localhost.localdomain>
Date: Wed, 1 Dec 1999 04:35:02 +1100 (EST)
To: Maurizio DE CECCO <maurizio@mandrakesoft.com>
Cc: linux-audio-dev@ginette.musique.umontreal.ca, jmax@ircam.fr
Subject: [linux-audio-dev] Searching for ...
In-Reply-To: <lg7lj1ry8b.fsf@ewok.mandrakesoft.com>
References: <lg7lj1ry8b.fsf@ewok.mandrakesoft.com>
X-Mailer: VM 6.72 under 21.1 (patch 3) "Acadia" XEmacs Lucid
X-Face: #ZD4&cjXdZyx/&-C!J4*7cv[N:?i}mfOI/(e7PZI_cO+g]E>4@%B]x00+OkmTRjjpINV>BP
 =8^:\{b".DGe.AJ:kx@
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 232134a176f7980758986cea60b19686

quoting Maurizio DE CECCO:

 > I am looking for some artists, doing some kind of audio-visual
 > plastic/installation work, using a complete free software platform.

Hi,
I've put up a news item on the Linux MusicStation news page
which might help.
Cheers
John

-- 

http://linuxmusic.cjb.net

From - Tue Nov 30 16:38:23 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA32654
	for <slinkp@ulster.net>; Tue, 30 Nov 1999 16:26:59 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA18349 for linux-audio-dev-list; Tue, 30 Nov 1999 15:52:36 -0500
Received: from renoir.op.net (renoir.op.net [207.29.195.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA18346 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 30 Nov 1999 15:52:24 -0500
Received: from op.net (d-bm2-15.ppp.op.net [209.152.194.53]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id PAA14023; Tue, 30 Nov 1999 15:46:41 -0500 (EST)
Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id PAA00679; Tue, 30 Nov 1999 15:47:06 -0500
Date: Tue, 30 Nov 1999 15:47:06 -0500
Message-Id: <199911302047.PAA00679@op.net>
From: Paul Barton-Davis <pbd@Op.Net>
To: sbenno@gardena.net
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] SMP low latency patch: tested - race condition
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 242eb98bf079855b8ebb80dde505f801

Benno - 

i finally got to testing out Ingo's suggestions for the SMP low
latency fix. alas, it appears to introduce a race condition. I tried 2
bootups. The first one hung during the microcode download to my
Tropez+; the second one hung during a probe for an ethernet card
(which i don't have installed). 2.2.10 with the LL patch never does
this. 

I don't have Ingo's mailing address, so perhaps you could let him
know. Enclosed below is my /usr/src/linux/include/asm/smplock.h. If I
had more time right now, I would look into it myself, but I don't.

--p

/*
 * <asm/smplock.h>
 *
 * i386 SMP lock implementation
 */
#include <linux/interrupt.h>
#include <linux/condsched.h>
#include <asm/spinlock.h>

extern spinlock_t kernel_flag;

/*
 * Release global kernel lock and global interrupt lock
 */
#define release_kernel_lock(task, cpu) \
do { \
	if (task->lock_depth >= 0) \
		spin_unlock(&kernel_flag); \
	release_irqlock(cpu); \
	__sti(); \
} while (0)

/*
 * Re-acquire the kernel lock
 */

#ifdef NOT_LOW_LATENCY

#define reacquire_kernel_lock(task) \
do { \
	if (task->lock_depth >= 0) \
		spin_lock(&kernel_flag); \
} while (0)

#else

#define reacquire_kernel_lock(task) \
do { \
	if (task->lock_depth >= 0) \
		while (!spin_trylock(&kernel_flag)) \
                        if (current->need_resched) \
                                schedule(); \
} while (0)

#endif /* NOT_LOW_LATENCY */


/*
 * Getting the big kernel lock.
 *
 * This cannot happen asynchronously,
 * so we only need to worry about other
 * CPU's.
 */
extern __inline__ void lock_kernel(void)
{

#ifdef NOT_LOW_LATENCY

	__asm__ __volatile__(
		"incl %1\n\t"
		"jne 9f"
		spin_lock_string
		"\n9:"
		:"=m" (__dummy_lock(&kernel_flag)),
		 "=m" (current->lock_depth));

#else

	if (!++current->lock_depth) {
		reacquire_kernel_lock(current);
	}

#endif /* NOT_LOW_LATENCY */
}

extern __inline__ void unlock_kernel(void)
{
	__asm__ __volatile__(
		"decl %1\n\t"
		"jns 9f\n\t"
		spin_unlock_string
		"\n9:"
		:"=m" (__dummy_lock(&kernel_flag)),
		 "=m" (current->lock_depth));
}

From - Wed Dec  1 23:41:17 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA12349
	for <slinkp@ulster.net>; Tue, 30 Nov 1999 17:40:31 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA18453 for linux-audio-dev-list; Tue, 30 Nov 1999 17:01:12 -0500
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA18450 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 30 Nov 1999 17:00:55 -0500
Received: from smp.localnet.it (IDENT:root@[194.242.217.4])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id WAA01806;
	Tue, 30 Nov 1999 22:54:51 +0100
Received: from gardena.net (IDENT:benno@localhost [127.0.0.1])
	by smp.localnet.it (8.9.3/8.9.3) with ESMTP id WAA00995;
	Tue, 30 Nov 1999 22:56:33 +0100
Message-ID: <38444810.68CADA8@gardena.net>
Date: Tue, 30 Nov 1999 22:56:33 +0100
From: Benno Senoner <benno@gardena.net>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pbd@Op.Net
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] [Fwd: lowlatency patch for 2.2.13 optimized for SMP ?]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 11ab447f01b40e543cf179a804ea1782

Hi Paul,
today, on linux-kernel I asked if Ingos new lowlatency patch inlcludes the
SMP extensions,
here his answer: (he gave an advice how to make it perform well on SMP boxes)

maybe this will work for you ? (you must  get his lowlatencycy-2.2.13 patch)

here is his post on linux-kernel:

http://kernelnotes.org/lnxlists/linux-kernel/lk_9911_02/msg00840.html

the patch is here:
http://www.redhat.com/~mingo/lowlatency-2.2.13-A1

Ingo's email address is:   mingo@chiara.csoma.elte.hu


PS: anyone experiencing lockups with the lowlatency-2.2.13 ?

Benno.


Ingo Molnar wrote:

> On Mon, 29 Nov 1999, Benno Senoner wrote:
>
> > Hi, I noticed that Ingo released a low-latency patch for the 2.2.13
> > kernel.
> >
> > 2.2.10-lowlatency was not optimized for SMP low-latency ( latencytest on
> > /proc stress gives high latencies).
> >
> > Does anyone (Ingo in particular) know if the 2.2.13 is SMP optimized ?
> > (spinlock changes)
>
> no, and i dont think it will ever be. The only and worst offender is the
> 'big kernel lock', which is much less of a problem in 2.3. We cannot
> generally reschedule at points that do a lock_kernel(). Maybe we could add
> a new lock_kernel_reschedule() function, but possibly you'll have to add
> this to gazillion places.
>
> there is a workaround: in reschedule_idle() whenever we wake up a RT
> process we could mark all running processes as 'reschedule ASAP' (set the
> need_resched flag). This guarantees that _someone_ will notice and
> reschedule eventually. (an SMP kernel is never worse than a UP kernel,
> latency-wise) This is only for RT tasks though. Do something like this at
> the beginning of reschedule_idle():
>
>         if (policy != SCHED_OTHER)
>                 for (i = 0; i < smp_num_cpus; i++) {
>                         cpu = cpu_logical_map(i);
>                         tsk = cpu_curr(cpu);
>                         tsk->need_resched = 1;
>                 }
>         /* continue doing the normal idle reschedule part */
>
> (this is of course an ugly hack, but if it makes a difference we can see
> how this could be done cleanly. It only affects RT tasks.)
>
> -- mingo

From - Wed Dec  1 23:41:31 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA11207
	for <slinkp@ulster.net>; Wed, 1 Dec 1999 09:17:20 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA23681 for linux-audio-dev-list; Wed, 1 Dec 1999 08:36:02 -0500
Received: from renoir.op.net (renoir.op.net [207.29.195.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA23678 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Dec 1999 08:35:59 -0500
Received: from op.net (d-bm3-11.ppp.op.net [209.152.194.81]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id IAA01975 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Dec 1999 08:30:13 -0500 (EST)
Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id IAA07239; Wed, 1 Dec 1999 08:30:48 -0500
Date: Wed, 1 Dec 1999 08:30:48 -0500
Message-Id: <199912011330.IAA07239@op.net>
From: Paul Barton-Davis <pbd@Op.Net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] wine, cubase etc.
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 37a6426494eadd75ada231b67246a2aa

i was just checking the Wine application database
(www.winehq.com/Apps) to follow up on the old rating of 4 given to
running cubase under wine. its a very old rating.

however, when i searched for new entries with a score of 5 (perfect),
i noticed that 2 of them had some significant audio component:
realplayer and napster. possibly significant.

is there anyone on the list who has a recent version of, say, cubase,
or something similar, and has tried to run it under a recent version
of wine ?

--p

From - Wed Dec  1 23:41:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA14007
	for <slinkp@ulster.net>; Wed, 1 Dec 1999 09:36:24 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA23738 for linux-audio-dev-list; Wed, 1 Dec 1999 09:06:12 -0500
Received: from www.tomy.net (www.tomy.net [209.186.149.104]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA23735 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Dec 1999 09:06:09 -0500
Received: from tomy.net (IDENT:thudson@jimi.tomy.net [192.168.1.2])
	by www.tomy.net (8.9.3/8.9.3) with ESMTP id JAA10004;
	Wed, 1 Dec 1999 09:00:23 -0500
Message-ID: <38452A07.268571A9@tomy.net>
Date: Wed, 01 Dec 1999 09:00:39 -0500
From: Thomas Hudson <thudson@tomy.net>
Reply-To: thudson@cygnus.com
Organization: Cygnus Solutions
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Barton-Davis <pbd@Op.Net>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] wine, cubase etc.
References: <199912011330.IAA07239@op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ba9d47c2d819210819f14616fb760d83

Paul Barton-Davis wrote:

> is there anyone on the list who has a recent version of, say, cubase,
> or something similar, and has tried to run it under a recent version
> of wine ?
> 
No. But I will probably try Acid this weekend. I haven't purchased a 
proprietary product in years, and a windows product in even longer.
But this past weekend I purchased Acid Music for $49 at Best Buy.
(Justifying in my head that if it was as good as everyone says, that
I would clone it for Linux). The only problems I ran in to have to
do with the fact that I stupidly installed SP6 for WinNT and now 
get the BSOD every fifteen minutes. 

The program is cool, and if anyone is interested in a project to
take the best ideas from it and create something improved for Linux,
let me know. This seems like one of those apps that a GPL'd version
could speed adoption of Linux.

My only concern is that some of the timestretch algorithms might
be patented.

Thomas

From - Wed Dec  1 23:41:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA20263
	for <slinkp@ulster.net>; Wed, 1 Dec 1999 10:20:13 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA23798 for linux-audio-dev-list; Wed, 1 Dec 1999 09:52:04 -0500
Received: from hotmail.com (law-f176.hotmail.com [209.185.131.239]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id JAA23795 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Dec 1999 09:52:01 -0500
Received: (qmail 77190 invoked by uid 0); 1 Dec 1999 14:46:15 -0000
Message-ID: <19991201144615.77189.qmail@hotmail.com>
Received: from 203.101.101.188 by www.hotmail.com with HTTP;
	Wed, 01 Dec 1999 06:46:15 PST
X-Originating-IP: [203.101.101.188]
From: "J Digital" <joshdigital@hotmail.com>
To: pbd@Op.Net, linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] wine, cubase etc.
Date: Wed, 01 Dec 1999 06:46:15 PST
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b542d390d8218fa0c0360427f620a31f


I used wine quite some years ago, and didnt have much luck getting anything 
beyond simple win 3.11 apps to run. but im seriously looking at getting 
vmware up and running, as i think it will really run nicely on my dual 
processor machine. check out details on www.vmware.com

josh

>From: Paul Barton-Davis <pbd@Op.Net>
>To: linux-audio-dev@ginette.musique.umontreal.ca
>Subject: [linux-audio-dev] wine, cubase etc.
>Date: Wed, 1 Dec 1999 08:30:48 -0500
>
>i was just checking the Wine application database
>(www.winehq.com/Apps) to follow up on the old rating of 4 given to
>running cubase under wine. its a very old rating.
>
>however, when i searched for new entries with a score of 5 (perfect),
>i noticed that 2 of them had some significant audio component:
>realplayer and napster. possibly significant.
>
>is there anyone on the list who has a recent version of, say, cubase,
>or something similar, and has tried to run it under a recent version
>of wine ?
>
>--p
>

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From - Wed Dec  1 23:41:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA30515
	for <slinkp@ulster.net>; Wed, 1 Dec 1999 11:25:10 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA23906 for linux-audio-dev-list; Wed, 1 Dec 1999 10:48:14 -0500
Received: from renoir.op.net (renoir.op.net [207.29.195.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA23903 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Dec 1999 10:48:11 -0500
Received: from someip.ppp.op.net (d-bm3-19.ppp.op.net [209.152.194.89]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id KAA16701 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Dec 1999 10:42:20 -0500 (EST)
Message-Id: <199912011542.KAA16701@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] wine, cubase etc. 
In-reply-to: Your message of "Wed, 01 Dec 1999 06:46:15 PST."
             <19991201144615.77189.qmail@hotmail.com> 
Date: Wed, 01 Dec 1999 10:42:58 -0500
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 5d3188a27400bc5c86787e2b7dcb04bb

>I used wine quite some years ago, and didnt have much luck getting anything 
>beyond simple win 3.11 apps to run. but im seriously looking at getting 
>vmware up and running, as i think it will really run nicely on my dual 
>processor machine. check out details on www.vmware.com

yes, vmware is great, but you are required to *have* Windows. i vowed
never to run any MS software, and as nice as vmware is, i don't want
to go back on that now, if possible.

--p

From - Wed Dec  1 23:41:37 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA30985
	for <slinkp@ulster.net>; Wed, 1 Dec 1999 11:28:10 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA23916 for linux-audio-dev-list; Wed, 1 Dec 1999 10:54:07 -0500
Received: from renoir.op.net (renoir.op.net [207.29.195.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA23913 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Dec 1999 10:54:02 -0500
Received: from someip.ppp.op.net (d-bm3-19.ppp.op.net [209.152.194.89]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id KAA17374 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Dec 1999 10:48:15 -0500 (EST)
Message-Id: <199912011548.KAA17374@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] acid, linux
In-reply-to: Your message of "Wed, 01 Dec 1999 09:00:39 EST."
             <38452A07.268571A9@tomy.net> 
Date: Wed, 01 Dec 1999 10:48:52 -0500
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 87289d4e6949110942a14742cc1c8feb

>[ Acid ] is cool, and if anyone is interested in a project to
>take the best ideas from it and create something improved for Linux,
>let me know. This seems like one of those apps that a GPL'd version
>could speed adoption of Linux.

most definitely. this program seems to have created a huge amount of
interest in the current loop-crazy music world. i talked to Sonic
Foundry when i was at WOMAD in Seattle this summer, and their sales
guy made me feel physically unsafe when i asked them if they would
port it to Linux!

>My only concern is that some of the timestretch algorithms might
>be patented.

probably, but my impression is that there are lots of reasonable ones
out there. sonorus or prosoniq or someone had a nice web page
someplace with a description of some non-patented ones.

also, i note that from my experience this last week porting softwerk
to GTK (and in some sense, softwerk is kind of like a MIDI-only
version of Acid) that the core algorithms of these programs are the
easiest part - writing good user interfaces to control all that power
is *really, really hard* (and, to be perfectly honest, pretty boring).

--p

From - Wed Dec  1 23:41:45 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA01707
	for <slinkp@ulster.net>; Wed, 1 Dec 1999 11:47:29 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA23966 for linux-audio-dev-list; Wed, 1 Dec 1999 11:20:02 -0500
Received: from gehenna0.rutgers.edu (gehenna0.rutgers.edu [165.230.116.155]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id LAA23963 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Dec 1999 11:19:59 -0500
Received: (qmail 1928 invoked by alias); 1 Dec 1999 16:14:12 -0000
Received: (qmail 1908 invoked from network); 1 Dec 1999 16:14:12 -0000
Received: from envelopegirl.rutgers.edu (HELO acm.org) (128.6.134.21)
  by gehenna0.rutgers.edu with SMTP; 1 Dec 1999 16:14:12 -0000
Message-ID: <38454973.F54CCFE9@acm.org>
Date: Wed, 01 Dec 1999 11:14:43 -0500
From: jfm3 <jfm3@acm.org>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: thudson@cygnus.com, linux-audio-dev@ginette.musique.umontreal.ca
CC: len9@mortmain.com
Subject: Re: [linux-audio-dev] wine, cubase etc.
References: <199912011330.IAA07239@op.net> <38452A07.268571A9@tomy.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 6b3783a8091ee1f34963b6854c92ae4f

Thomas Hudson wrote:

> [Acid] is cool, and if anyone is interested in a project to
> take the best ideas from it and create something improved for Linux,
> let me know. This seems like one of those apps that a GPL'd version
> could speed adoption of Linux.

"me too"

Acid is practically supernaturally inspired.  It's one of those programs
that solves just the right set of problems in just the right ways.  Just
about the only programs I need to make music that force me into Windows
any more are SoundForge and Acid, and I think that if I make a serious
commitment to learning snd/clm/cm I'll be able to eliminate SoundForge.

Acid would speed adoption of Linux too, because it is very easy for
non-musicians and non-techies to get sounding results very quickly with
it.  I've seen kids as young as 10 and as old as 56 spend hours arranging
other people's loops and tweaking the effects.  Another important "speed
adoption of Linux" music program is ReBirth, but sadly they've made their
mod format unembraceable.  Given that compatibility is impossible, I think
that a combination of phrase sequencing software (i.e., KeyKit or
SoftWerk) and Quasimodo could be ReBirth quite nicely.

Anyone who hasn't should spend a couple of hours with these programs just
to see what it's like.  It's very different from the bad old days of step
sequencing quavers into cakewalk!

(jfm3)


From - Wed Dec  1 23:41:47 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA05380
	for <slinkp@ulster.net>; Wed, 1 Dec 1999 12:11:44 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA24002 for linux-audio-dev-list; Wed, 1 Dec 1999 11:44:47 -0500
Received: from cygnus.com (runyon.cygnus.com [205.180.230.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA23999 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Dec 1999 11:44:44 -0500
Received: from cygnus.com (thudson1.cygnus.com [205.226.144.45])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id IAA14650;
	Wed, 1 Dec 1999 08:38:53 -0800 (PST)
Message-ID: <38454F1C.98FC6FF3@cygnus.com>
Date: Wed, 01 Dec 1999 11:38:52 -0500
From: Thomas Hudson <thudson@cygnus.com>
Organization: Cygnus Solutions
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Barton-Davis <pbd@Op.Net>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] acid, linux
References: <199912011548.KAA17374@renoir.op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 730bf3c40e435bc876c7071f8646cf3b

Paul Barton-Davis wrote:
>
> also, i note that from my experience this last week porting softwerk
> to GTK (and in some sense, softwerk is kind of like a MIDI-only
> version of Acid) that the core algorithms of these programs are the
> easiest part - writing good user interfaces to control all that power
> is *really, really hard* (and, to be perfectly honest, pretty boring).
> 
Yes, the ui is almost always the hardest part. I'm not a big fan
of the windows ui, but I must admit that the layout of Acid is
very workflow oriented. They integrated a file browser on a
tab at the bottom of the app that allows one to audition loops. 
The also implemented scaling for the main subwindow, which is quite 
nice.

Tomy

From - Wed Dec  1 23:41:48 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA08814
	for <slinkp@ulster.net>; Wed, 1 Dec 1999 12:30:45 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA24041 for linux-audio-dev-list; Wed, 1 Dec 1999 12:02:23 -0500
Received: from p-biset.issy.cnet.fr (p-biset.issy.cnet.fr [139.100.0.33]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id MAA24038 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Dec 1999 12:02:17 -0500
Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0)
	id <XCDL4JBB>; Wed, 1 Dec 1999 17:56:56 +0100
Message-ID: <F09BA6AD2FB2D211BFAC00805F312C89B5878F@p-heron.issy.cnet.fr>
From: MOULET Xavier CNET/DMR/ISS <xavier.moulet@cnet.francetelecom.fr>
To: "'linux-audio-dev@ginette.musique.umontreal.ca'"
	 <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: RE: [linux-audio-dev] acid, linux
Date: Wed, 1 Dec 1999 17:56:56 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id MAA08814
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: cadfa8add824500f09fda0657e70edfc

I (with the few time & knowledge I have) am trying to build such an
interface with Glade (VERY nice App) / Gtk /(gnome ?). It sure helps a lot
defining things clearly and I am trying to do an open GUI, ie quite general
and easily expandable to other functions.

The principle is the following : 
A "song" have several "Drivers" (midi, esd, oss ...?) upon which may
work some "mixers". Upon each "track" would exist some "modules" i.e. source
s defined by a position and a length, among other things. Upon these modules
can be attached some "effects".

Each of these "plugins" would have "parameters", which can be found from
many sources (read plugin, again) : midifile, step sequencer, fixed value,
sliders ...

The idea here is that fully modular apps are not that practical to work
with, ie the UI is generally confusing if you want to do some real job.

My prog would just allow you to edit the misc properties and would make it
easy to manipulate the timed information on a grid. 

Now I have quite the fundations of the Interface (though there still is a
LOT of work to be done !!!) of such a prog.

AFAI am concerned, it's the CORE engine that DEFINITELY will be the hard
part. I am wondering whether I will use this or that library for my core
engine.

Thus, I am waiting eagerly of an implementation of the API discussions (or
is there one ?), and of course, of an engine.

Is there already one or many good engines fundations for such a thing ?
Would Quasimodo (without the interface) do the job or is it too Csound
oriented ?
Raw Esd ? THE API (mucows (?)), aRts ? xmms ?

What do you think of this kind of framework ?

Your advice will be of great help. There are many ones I think , but which
one is the most versatile (streaming & FX/plugins Hooks would be GREAT),
robust, etc.. etc .. ?

thanks a lot. I know a bit about signal processing, but my prog skills are,
well, not so good, at least too bad to program such an engine, at least a
reliable, fast one.

Bye,

xavier



> -----Message d'origine-----
> De: Paul Barton-Davis [mailto:pbd@Op.Net]
> Date: mercredi 1 dcembre 1999 16:49
> : linux-audio-dev@ginette.musique.umontreal.ca
> Objet: Re: [linux-audio-dev] acid, linux
> 
> 
> >[ Acid ] is cool, and if anyone is interested in a project to
> >take the best ideas from it and create something improved for Linux,
> >let me know. This seems like one of those apps that a GPL'd version
> >could speed adoption of Linux.
> 
> most definitely. this program seems to have created a huge amount of
> interest in the current loop-crazy music world. i talked to Sonic
> Foundry when i was at WOMAD in Seattle this summer, and their sales
> guy made me feel physically unsafe when i asked them if they would
> port it to Linux!
> 
> >My only concern is that some of the timestretch algorithms might
> >be patented.
> 
> probably, but my impression is that there are lots of reasonable ones
> out there. sonorus or prosoniq or someone had a nice web page
> someplace with a description of some non-patented ones.
> 
> also, i note that from my experience this last week porting softwerk
> to GTK (and in some sense, softwerk is kind of like a MIDI-only
> version of Acid) that the core algorithms of these programs are the
> easiest part - writing good user interfaces to control all that power
> is *really, really hard* (and, to be perfectly honest, pretty boring).
> 
> --p
> 

From - Wed Dec  1 23:41:50 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA16184
	for <slinkp@ulster.net>; Wed, 1 Dec 1999 13:18:08 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA24119 for linux-audio-dev-list; Wed, 1 Dec 1999 12:52:38 -0500
Received: from renoir.op.net (renoir.op.net [207.29.195.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA24116 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Dec 1999 12:52:36 -0500
Received: from someip.ppp.op.net (d-bm3-19.ppp.op.net [209.152.194.89]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id MAA01036 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Dec 1999 12:46:49 -0500 (EST)
Message-Id: <199912011746.MAA01036@renoir.op.net>
To: "'linux-audio-dev@ginette.musique.umontreal.ca'" <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] acid, linux 
In-reply-to: Your message of "Wed, 01 Dec 1999 17:56:56 +0100."
             <F09BA6AD2FB2D211BFAC00805F312C89B5878F@p-heron.issy.cnet.fr> 
Date: Wed, 01 Dec 1999 12:47:27 -0500
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d2d8603534f0c27912b4358161a9567e

When i talk about the UI being hard, i don't only mean the layout,
though that is hard enough. companies like steinberg and sonic foundry
have years of experience doing things like:

     * draw a curve over the top of a soundfile amplitude/time graph,
       and have the core part of the program scale the volume of the soundfile
       accordingly (and change the display). allow the curve to start
       with any of 9 different basic curve types, then do bezier-like
       spline manipulation on it.
     * take an amplitude/time representation of MIDI control data, allow
       you to drag every point around, and then apply the new curve
       to some aspect of a bunch of audio samples (protools does this
       very nicely)
     * mouse-click-then-drag-beyond-current-boundary visually stretches
       a soundfile display *and* applies timestretch algorithm.

none of these are impossible or even particularly hard with, say, GTK,
but each one of them is a *lot* of work. we don't have a base of
interface details like this to work from; steinberg/sonic
foundry/cakewalk do, and they are using it.

--p

From - Wed Dec  1 23:41:51 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA16558
	for <slinkp@ulster.net>; Wed, 1 Dec 1999 13:20:50 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA24125 for linux-audio-dev-list; Wed, 1 Dec 1999 12:54:04 -0500
Received: from servidor.unam.mx (servidor.unam.mx [132.248.10.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA24122 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Dec 1999 12:54:01 -0500
Received: from servidor.unam.mx ([132.248.111.91])
	by servidor.unam.mx (8.9.3/8.9.3) with ESMTP id LAA05053
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Dec 1999 11:48:16 -0600 (CST)
Message-ID: <38455F5F.8DFD53CB@servidor.unam.mx>
Date: Wed, 01 Dec 1999 11:48:40 -0600
From: Pablo Silva <hpsilva@servidor.unam.mx>
X-Mailer: Mozilla 4.5 (Macintosh; I; PPC)
X-Accept-Language: en,es-MX
MIME-Version: 1.0
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Building a computer for Linux
References: <lg7lj1ry8b.fsf@ewok.mandrakesoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: d137fef03542fe9f9bc0639663b5833b

Hello!

I'm considering builing a new x86 computer from scratch, to be able to
run Linux and Windows NT on it, specifically for music applications. I
want it to be a PIII running as fast as I can afford, and would like to
know what to consider in terms of hardware components to be able to run
as effortlessly as possible. I'm especially concerned in regards to
soundcard support...

Thanks for your suggestions.

Pablo Silva

From - Wed Dec  1 23:41:52 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA20774
	for <slinkp@ulster.net>; Wed, 1 Dec 1999 13:47:27 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA24182 for linux-audio-dev-list; Wed, 1 Dec 1999 13:20:55 -0500
Received: from upf.es (newton.upf.es [193.145.54.60]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA24179 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Dec 1999 13:20:51 -0500
Received: from mtg150.upf.es (mtg150.upf.es [193.145.44.150])
	by upf.es (8.9.0/8.9.0) with SMTP id TAA00842;
	Wed, 1 Dec 1999 19:14:25 +0100 (MET)
From: maarten de boer <maarten.deboer@iua.upf.es>
Reply-To: maarten.deboer@iua.upf.es
Organization: IUA
To: hpsilva@servidor.unam.mx
Subject: Re: [linux-audio-dev] Building a computer for Linux
Date: Wed, 1 Dec 1999 19:19:57 +0100
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <38455F5F.8DFD53CB@servidor.unam.mx>
MIME-Version: 1.0
Message-Id: <99120119241400.01068@mtg150.upf.es>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: bc0a3a2d2161d5c796465bd1fc52a491

On Wed, 01 Dec 1999, hpsilva@servidor.unam.mx wrote:
> Hello!
> 
> I'm considering builing a new x86 computer from scratch, to be able to
> run Linux and Windows NT on it, specifically for music applications. I
> want it to be a PIII running as fast as I can afford, and would like to
> know what to consider in terms of hardware components to be able to run
> as effortlessly as possible. I'm especially concerned in regards to
> soundcard support...
> 
> Thanks for your suggestions.
> 

Hi Pablo,

For Linux, the Hoontech sound cards seem to be an excellent choice.
I don't have one, but people on the alsa list are very enthousiastic
about it. Also, Trident has make the specs completely open. The Hoontech
cards have SPDIF as well. You might want to check the ALSA mailing list
archives. www.alsa-project.org

I use a AWE64PCI myself, which worked also pretty effortless, though I
have been reading things about creative using different chipsets and
cards with the same name, so you might want to check that.

Maarten

From - Wed Dec  1 23:41:53 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA23729
	for <slinkp@ulster.net>; Wed, 1 Dec 1999 14:07:32 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA24201 for linux-audio-dev-list; Wed, 1 Dec 1999 13:35:59 -0500
Received: from gw.aurora-linux.com (mailhub.aurora-linux.com [212.81.103.10]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA24198 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Dec 1999 13:35:54 -0500
Received: from aurora-linux.com (ns1.aurora-linux.com [212.81.103.2])
	by gw.aurora-linux.com (8.9.3/8.8.7) with ESMTP id TAA09186;
	Wed, 1 Dec 1999 19:31:51 +0100
Message-ID: <38456968.9EB7D2B4@aurora-linux.com>
Date: Wed, 01 Dec 1999 18:31:04 +0000
From: Administrateur <admin@aurora-linux.com>
Organization: Aurora
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: fr, en
MIME-Version: 1.0
To: Dave Phillips <dlphilp@bright.net>
CC: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] need help with SLab
References: <3831747E.D017331B@bright.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f4098bc188ab3d196d28c86815256b2f

Dave Phillips wrote:

> Greetings:
> 
>   I'm profiling SLab for my book, but I've run into a problem unique to
> this program. I can record fine with my SB PCI128, but on playback an
> annoying ticking can be heard throughout the recording. It's actually
> ticking at a rate that "accompanies" the signal, either in triplets or
> 16ths. I've contacted the author, he's pretty sure it's an internal
> problem, but I wondered if anyone else here has tried SLab and
> encountered this problem. Or, have any of you developers encountered
> such a problem in your own work, and if so, what did you do about it ?
> TIA !
> 
>   My system:
>         P166 w. 128 megs RAM
>         kernel 2.0.36 (RH 5.2 recompiled)
>         OSS/Linux driver 3.9.2m
>         Sound Blaster PCI128

I had this problem when I tried to use SLab with my old AWE 64 Gold on
an old Cyrix P200+
The problem disapeared when I upgraded the hardware for a faster PII
300.
Sounds SLab is a very nice piece of software, but a real hog on CPU and
system resources.

Jean-Claude


-- 
Aurora - 69-71 Avenue Pierre Grenier - F92100 Boulogne - France
Phone: +33 (0)1 58 17 03 20          Fax : +33 (0)1 58 17 03 21

From - Wed Dec  1 23:42:07 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA19257
	for <slinkp@ulster.net>; Wed, 1 Dec 1999 19:46:33 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA24812 for linux-audio-dev-list; Wed, 1 Dec 1999 19:20:08 -0500
Received: from sculpcave (ppp-11.wakkanet.fi [194.157.35.219]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA24809 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Dec 1999 19:20:03 -0500
Received: from localhost (localhost [127.0.0.1])
	by sculpcave (Postfix) with ESMTP
	id AC62B34D9D; Thu,  2 Dec 1999 02:11:49 +0200 (EET)
Date: Thu, 2 Dec 1999 02:11:48 +0200 (EET)
From: Kai Vehmanen <kaiv@wakkanet.fi>
X-Sender: root@sculpcave.localdomain
To: Paul Barton-Davis <pbd@Op.Net>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] acid, linux
In-Reply-To: <199912011548.KAA17374@renoir.op.net>
Message-ID: <Pine.LNX.4.10.9912020102190.3156-100000@sculpcave.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0f520d76c90857418a2b84a54dbd2162

On Wed, 1 Dec 1999, Paul Barton-Davis wrote:

> also, i note that from my experience this last week porting softwerk
> to GTK (and in some sense, softwerk is kind of like a MIDI-only
> version of Acid) that the core algorithms of these programs are the
> easiest part - writing good user interfaces to control all that power
> is *really, really hard* (and, to be perfectly honest, pretty
> boring).

Couldn't agree more! ;) I just finished recording&mixing
two new songs using the latest stable version of ecasound (v1.6.7r7).
I didn't use GUI (qtecasound) for anything - all was done using 
the console-mode interface. Now, I admit that there are some things
that are better done with a GUI. There might even be some odd people
that like GUI better than console-mode. :) But it seems that many 
people (=usually non-coders) don't really understand how much work
you need to do before you have a usable GUI, let alone a good one!

Currently qtecasound already has over 5000 lines of code, but still
it offers only the most basic features of ecasound libraries.
Console-UI (under 500 lines of C++ code) supports *all* features.

But what's even worse (as you mentioned), writing GUI code is just 
*really* boring. You spend most of the time moving widgets from 
position to another, making layout changes, wondering what the user 
might do (and in what order), etc etc... I guess GUI-design programs 
like Glade, QtEz, Qtarch make it more bearable, but they have their 
own problems (writing HTML w/ emacs is a bit painful, but it's still
a joy compared to FrontPage :)).

It would be great if we could combine our efforts (OAWL = Open Audio
Widget Library), but I guess this would be a pretty hopeless project.

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav

From - Wed Dec  1 23:42:10 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA19279
	for <slinkp@ulster.net>; Wed, 1 Dec 1999 19:46:41 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA24817 for linux-audio-dev-list; Wed, 1 Dec 1999 19:20:58 -0500
Received: from zapfhahn.bone.twc.de (zapfhahn.bone.twc.de [193.158.34.194]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA24814 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Dec 1999 19:20:55 -0500
Received: from space.twc.de (IDENT:stefan@space.twc.de [193.158.34.195])
	by zapfhahn.bone.twc.de (8.9.3/8.9.3) with ESMTP id CAA24797;
	Thu, 2 Dec 1999 02:14:10 +0100
Received: (from stefan@localhost)
	by space.twc.de (8.8.7/8.8.7) id CAA14639;
	Thu, 2 Dec 1999 02:18:31 +0100
Message-ID: <19991202021830.45633@space.twc.de>
Date: Thu, 2 Dec 1999 02:18:30 +0100
From: Stefan Westerfeld <stefan@space.twc.de>
To: MOULET Xavier CNET/DMR/ISS <xavier.moulet@cnet.francetelecom.fr>
Cc: "'linux-audio-dev@ginette.musique.umontreal.ca'" <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] acid, linux
References: <F09BA6AD2FB2D211BFAC00805F312C89B5878F@p-heron.issy.cnet.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.85e
In-Reply-To: <F09BA6AD2FB2D211BFAC00805F312C89B5878F@p-heron.issy.cnet.fr>; from MOULET Xavier CNET/DMR/ISS on Wed, Dec 01, 1999 at 05:56:56PM +0100
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4e06b232eb42ac5fa1758244858d260f

   Hi!

On Wed, Dec 01, 1999 at 05:56:56PM +0100, MOULET Xavier CNET/DMR/ISS wrote:
> [...]
> 
> Thus, I am waiting eagerly of an implementation of the API discussions (or
> is there one ?), and of course, of an engine.
> 
> Is there already one or many good engines fundations for such a thing ?
> Would Quasimodo (without the interface) do the job or is it too Csound
> oriented ?
> Raw Esd ? THE API (mucows (?)), aRts ? xmms ?

I can tell you what aRts is doing right now.

The idea I have is moving away from CORBA towards a lighter consistent
object model which spreads throughout aRts. The thing will be called
MCOP, which expands to multimedia communication protocol. But keep in
mind that it cares about communcation and object model (the things that
were handled by CORBA before).  One will write things like

interface Synth_ADD {
  in audio stream signal1, signal2;
  out audio stream result;
};

in an idl file, and it will generate C++ skeleton classes, which you
only need to implement. For Synth_ADD, this could look somthing along
the lines:

void SynthAdd_impl::calculateBlock(unsigned long cycles)
{
    float *end = result + cycles;
	 
	while(result != end) *result++ = *signal1++ + *signal2++;
}                                                                               

that's about all you need to write. By the way, you could also have
something like

interface BinaryOperation {
  in audio stream signal1, signal2;
  out audio stream result;
};

interface Synth_ADD : BinaryOperation {
  //
};

which means you get the wonders of polymorphism and inheritance in your
plugin system.

The component communication will be handled transparently to the programmer,
and also whether it is in the same process space (linked as library), or in
another thread, or in another process or on a computer somewhere on the
network shall be transparent.

So using aRts as library should finally be possible for those who want
to do that. (This is really important for wave editors for instance). Also,
people will not any longer need to install mico to use aRts. Another
advantage is that the overhead is much much less.

Perhaps other people who are still considering whether they want to do
something similar could also join in. Basically, writing a middleware
like MCOP is a lot of work. It is more or less as complete as CORBA (at
least the relevant parts I used) in it's current development stadium,
though not everything works fine yet, but it supports

- remote method invocations
- inheritance
- multiple inheritance
- using components transparently as libs or remote
- do marshalling
- define own datatypes (e.g. structs and such) in the idl file, such as
  struct MidiEvent or struct FFTPacket
- C++ language binding (if you want - write a C implementation of MCOP,
  at least apps/plugins will be able to communicate properly then)

from my speed tests, it wins factor three against mico for synchronous
invocations, but the slowness is obtained by using a TCP transport, rewriting
that to sharedmem should give another major boost. Also, the real gain is
that you can support streaming, QoS, event transport, etc by your
communication layer, which was impossible to do with CORBA before.

KDE2 will use aRts as multimedia framework, which also means the sound
server that will be running for the desktop will be implemented on top
of that. It will also not necessarily remain an audio-only thing, video
for instance would also be great - but that has some time.

The engine is partially ported from CORBA, but it currently can't do more
than a beep (but at least that: fully modular) - also the plugins aren't
ported, and some infrastructure is still completely missing (Qt GUI stuff).

So the dependancies aRts has are reduced to: C++ with STL (no Qt, no Mico,
no KDE, no X11, if you really want not even Unix are required).

The code is available from the KDE CVS (kdemultimedia/arts), which you also
can get anonymously if you like via CVSup. It is still in its experimental
phase, but I'll port over all aRts infrastructure to MCOP in the next time,
though that may take a while.

   Cu... Stefan

PS: Please - everybody who is now writing something similar - step back a
second and think of you couldn't join aRts. What is missing?
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-

From - Wed Dec  1 23:42:13 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA30778
	for <slinkp@ulster.net>; Wed, 1 Dec 1999 20:57:38 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA24974 for linux-audio-dev-list; Wed, 1 Dec 1999 20:38:59 -0500
Received: from hme0.smtp04.sprint.ca (hme0.smtp04.sprint.ca [207.107.250.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA24971 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Dec 1999 20:38:56 -0500
Received: from vektor.div8.net (root@spc-isp-tor-58-5-20.sprint.ca [149.99.76.20])
	by hme0.smtp04.sprint.ca (8.8.8/8.8.8) with ESMTP id UAA01976;
	Wed, 1 Dec 1999 20:22:16 -0500 (EST)
Received: by div8.net
	via sendmail from stdin
	id <m11tL0w-00096VC@vektor.div8.net> (Debian Smail3.2.0.102)
	for pbd@Op.Net; Wed, 1 Dec 1999 20:26:30 -0500 (EST) 
Date: Wed, 1 Dec 1999 20:26:30 -0500
From: Billy Biggs <vektor@DIV8.NET>
To: Kai Vehmanen <kaiv@wakkanet.fi>
Cc: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] acid, linux
Message-ID: <19991201202630.A17641@div8.net>
Mail-Followup-To: Kai Vehmanen <kaiv@wakkanet.fi>,
	Paul Barton-Davis <pbd@Op.Net>,
	linux-audio-dev@ginette.musique.umontreal.ca
References: <199912011548.KAA17374@renoir.op.net> <Pine.LNX.4.10.9912020102190.3156-100000@sculpcave.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <Pine.LNX.4.10.9912020102190.3156-100000@sculpcave.localdomain>; from kaiv@wakkanet.fi on Thu, Dec 02, 1999 at 02:11:48AM +0200
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ce982f1121f609052443bbb0814f1c49

Kai Vehmanen (kaiv@wakkanet.fi):

> Couldn't agree more! ;) I just finished recording&mixing
> two new songs using the latest stable version of ecasound (v1.6.7r7).
> I didn't use GUI (qtecasound) for anything - all was done using 
> the console-mode interface. [...]

  I don't see how you can do any audio work at all in console mode.  Personally,
I find ecasound to be very powerful and cool, but to me it's mostly useless:

  - If I'm recording a song, I _NEED_ to see peaks so that I can watch for
    clipping.  Without being able to visually see incomming audio data, I could
    finish recording a whole song without realizing that I clipped in the middle.

  - If I'm editing a song, I NEED to visually see the waveform.  Without that,
    I don't see how you can do any reasonable audio editing.

  - I don't want to have to keep typing to use an audio app.  It means using
    both hands to do work on a keyboard, whereas the mouse lets me keep one
    hand on my instrument.

  - Cutting and pasting of audio files, splicing, and punching in, is pretty
    much ridiculous without a GUI.

  BTW, take a look at my ttrk screenshot, http://www.div8.net/ttrk, to see the
basis for a feasible ACID clone GUI.

> Currently qtecasound already has over 5000 lines of code, but still
> it offers only the most basic features of ecasound libraries.
> Console-UI (under 500 lines of C++ code) supports *all* features.

  I don't think you're using Qt properly.

> But what's even worse (as you mentioned), writing GUI code is just 
> *really* boring. You spend most of the time moving widgets from 
> position to another, making layout changes, wondering what the user 
> might do (and in what order), etc etc... I guess GUI-design programs 
> like Glade, QtEz, Qtarch make it more bearable, but they have their 
> own problems (writing HTML w/ emacs is a bit painful, but it's still
> a joy compared to FrontPage :)).

  Programming a good GUI is more about design than programming.  That doesn't
mean it's boring, it just means you have to design and not just fire off code.

-- 
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

From - Wed Dec  1 23:42:14 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA19886
	for <slinkp@ulster.net>; Wed, 1 Dec 1999 23:23:17 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA25305 for linux-audio-dev-list; Wed, 1 Dec 1999 23:02:21 -0500
Received: from renoir.op.net (renoir.op.net [207.29.195.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA25302 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Dec 1999 23:02:18 -0500
Received: from someip.ppp.op.net (d-bm2-1c.ppp.op.net [209.152.194.60]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id WAA27901 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Dec 1999 22:56:26 -0500 (EST)
Message-Id: <199912020356.WAA27901@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] acid, linux 
In-reply-to: Your message of "Thu, 02 Dec 1999 02:18:30 +0100."
             <19991202021830.45633@space.twc.de> 
Date: Wed, 01 Dec 1999 22:57:11 -0500
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f6f1e06eec9bf3e0e2336ff1c8f5103e

>PS: Please - everybody who is now writing something similar - step back a
>second and think of you couldn't join aRts. What is missing?

i don't want this to be read as an "aRts-bashing" letter. i think
there are lots of things to like about aRts. however, stefan did ask,
so ...

what i *think* is missing is an easy way to access the power of the
Music V/unit generator (UG) model that emerged out of academic
computer music over the course of 30 years or so.

aRts is a very nice system, but its fundamentally based around the
idea of having to be a "real programmer" to be able to provide new
functionality for it. the UG model sidesteps this issue by allowing
people who are not "real programmers" but can handle an interpreted
environment like the one offered by UG langauges to create interesting
things. you just provide a language that includes basic arithmetic,
logical and relational operators, some level of flow control, and a
rich set of functions/opcodes/procedures/objects/whatever-you-call-them;
individual users who understand very little of the workings of the
engine or programming languages (let alone IDL's) can develop very
interesting new "instruments".

there are a *relatively* large number of people who are
writing/extending/fixing opcodes for Csound and SAOL, and these don't
really lend themselves to use in aRts without a complete rewrite
(well, often). consider things like the granular synthesis opcodes for
Csound: these are complex algorithms that undergo subtle extensions
from time to time, and it seems to me that there is (currently) no
developer base out there to implement such things as aRts modules.
there are lots more examples like this. the use of SAOL for MP4 is
only going to increase the popularity of a UG model.

another criticism i would make of aRts is the centrality of MIDI. most
people familiar with MIDI know that its representation of pitch leaves
a great deal to be desired, yet the notion of MIDI interconnections
between aRts structures seems fairly fundamental to the whole
program. removing MIDI from the core of Quasimodo is one of my
projects for the new year.

finally, its not clear to me the formalization of an object
relationship between the synthesis engine and a user interface needs
or even should be taken to the extreme that aRts does. i think one can
follow Michael Gogins' lead with his proposal for a Csound engine API
- i don't think that one needs a model that looks anything like CORBA
(or the new MCOP). As long as some entity within a program exists that
supports the function calls and data present in the API, then the
program will get what it requests. It seems to me that placing the
emphasis on inter-object communication instead of object API's leads
one down a strange path for a real-time low latency application.

i may be wrong about a lot of this - i have not tried aRts in at least
a year, and i don't claim to understand much about the program. i have
read the manual from cover to cover, however :)

but to reiterate - i think that aRts is a very interesting and
valuable program, and i hope that it continues to grow and succeed.

--p

From - Wed Dec  1 23:49:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA22917
	for <slinkp@ulster.net>; Wed, 1 Dec 1999 23:47:33 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA25348 for linux-audio-dev-list; Wed, 1 Dec 1999 23:24:03 -0500
Received: from renoir.op.net (renoir.op.net [207.29.195.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA25345 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Dec 1999 23:24:01 -0500
Received: from someip.ppp.op.net (d-bm2-1c.ppp.op.net [209.152.194.60]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id XAA29369 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 1 Dec 1999 23:18:06 -0500 (EST)
Message-Id: <199912020418.XAA29369@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] acid, linux 
In-reply-to: Your message of "Wed, 01 Dec 1999 20:26:30 EST."
             <19991201202630.A17641@div8.net> 
Date: Wed, 01 Dec 1999 23:18:51 -0500
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c5d458a5e1ca0124d6a5fec4a8c11c21

>> But what's even worse (as you mentioned), writing GUI code is just 
>> *really* boring. You spend most of the time moving widgets from 
>> position to another, making layout changes, wondering what the user 
>> might do (and in what order), etc etc... I guess GUI-design programs 
>> like Glade, QtEz, Qtarch make it more bearable,

they don't do a very good job where you want programmatic construction
of the GUI: eg. cmdline arguments specifying 32 steps instead of 16,
where each step UI is identical.

>  Programming a good GUI is more about design than programming.  That doesn't
>mean it's boring, it just means you have to design and not just fire off code.

very true. but that doesn't get rid of the boring stuff that Kai
mentioned. 

--p

From - Thu Dec  2 11:58:15 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA30963
	for <slinkp@ulster.net>; Thu, 2 Dec 1999 09:12:06 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA00024 for linux-audio-dev-list; Thu, 2 Dec 1999 08:41:26 -0500
Received: from mout1.01019freenet.de (mout1.01019freenet.de [62.104.201.3]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA00021 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 2 Dec 1999 08:41:23 -0500
From: depet@gmx.de
Received: from [62.104.201.2] (helo=mx1.01019freenet.de)
	by mout1.01019freenet.de with esmtp (Exim 3.10 #1)
	id 11tWOT-0005eO-00
	for linux-audio-dev@ginette.musique.umontreal.ca; Thu, 02 Dec 1999 14:35:33 +0100
Received: from [212.81.221.162] (helo=Nirvana.Saustall)
	by mx1.01019freenet.de with esmtp (Exim 3.10 #2)
	id 11tWOS-0005Ca-00
	for linux-audio-dev@ginette.musique.umontreal.ca; Thu, 02 Dec 1999 14:35:32 +0100
Message-ID: <XFMail.991202144723.depet@gmx.de>
X-Mailer: XFMail 1.3 [p0] on Linux
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <199912011330.IAA07239@op.net>
Date: Thu, 02 Dec 1999 14:47:23 +0100 (CET)
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: RE: [linux-audio-dev] wine, cubase etc.
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 6b35a6dae43bf1ce7e489dc1689996d3


On 01-Dec-99 Paul Barton-Davis wrote:
> i was just checking the Wine application database
> (www.winehq.com/Apps) to follow up on the old rating of 4 given to
> running cubase under wine. its a very old rating.
> 
> however, when i searched for new entries with a score of 5 (perfect),
> i noticed that 2 of them had some significant audio component:
> realplayer and napster. possibly significant.
> 
> is there anyone on the list who has a recent version of, say, cubase,
> or something similar, and has tried to run it under a recent version
> of wine ?
> 
> --p

tried this recently because I needed some usable midi sequencer (Brahms is
close to, but needs still some things)

Winamp - works fine (mentioned before here), pretty stable timing
Cubasis 1.1(?) - looks fine but wine cannot do midi for 16 bit :-(
Voyetra Midi Orch. plus - whines about some dll version althougt it's
                          the right one :-(
Cubase Score 3.5 - installs but doesn't start, vxd for the dongle check
                        screws somehow :-(
Cooledit Pro 1.2 - installs fine but has same problems as Cubase Score 3.5
                        wine doesn't want to load some files :-(
Logic Audio Platinum 4.02 - doesn't even want to install :-(

note: I don't have any W9x installed and as you may have guessed I used the 
nice and quality Radium addons for the last three programms (haven't that much
money for such experiments ;)

I'm sure there are better results at least at one programm if you have some W9x
installed and if you use some native libs, but I can't test this because of disk
space and my aversion to MS.

ps: is anyone working/thinking of starting some GPL'd successor to multitrack?
    I recently started playing around with gtk,threads,etc but I'm slow crawling
    (nearly no programming experience...)
    
...o..oO0 NoehliE 0Oo..o...

From - Thu Dec  2 11:58:17 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA05256
	for <slinkp@ulster.net>; Thu, 2 Dec 1999 09:51:44 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA00113 for linux-audio-dev-list; Thu, 2 Dec 1999 09:26:43 -0500
Received: from www.tomy.net (www.tomy.net [209.186.149.104]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA00110 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 2 Dec 1999 09:26:37 -0500
Received: from tomy.net (IDENT:thudson@jimi.tomy.net [192.168.1.2])
	by www.tomy.net (8.9.3/8.9.3) with ESMTP id JAA01937;
	Thu, 2 Dec 1999 09:17:58 -0500
Message-ID: <38467F95.839BA165@tomy.net>
Date: Thu, 02 Dec 1999 09:17:57 -0500
From: Thomas Hudson <thudson@tomy.net>
Reply-To: thudson@cygnus.com
Organization: Cygnus Solutions
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Stefan Westerfeld <stefan@space.twc.de>
CC: MOULET Xavier CNET/DMR/ISS <xavier.moulet@cnet.francetelecom.fr>,
        "'linux-audio-dev@ginette.musique.umontreal.ca'" 
 <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] acid, linux
References: <F09BA6AD2FB2D211BFAC00805F312C89B5878F@p-heron.issy.cnet.fr> <19991202021830.45633@space.twc.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 7319985e33eaf5bb2aa12b76af79fc7e

Stefan Westerfeld wrote:
> Perhaps other people who are still considering whether they want to do
> something similar could also join in. Basically, writing a middleware
> like MCOP is a lot of work. It is more or less as complete as CORBA (at
> least the relevant parts I used) in it's current development stadium,
> though not everything works fine yet, but it supports
> 
Have you considered ILU? I don't claim to be that knowledgable of ILU,
but I seem to remember it doing something similar to what COM does on
windows. If the object is invoked in the same process space, the overhead
is equivalent to a function call. Out of process but machine local is
still optimized by using shared memory. And it will fall back to RPC
when the object it not local to the machine. It might save you a lot of
work.

I believe ILU was considered for GNOME but the licensing was screwy.
Since then Xerox has changed the licensing, it may be more palatable
now.

Thomas

From - Thu Dec  2 11:58:25 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA15697
	for <slinkp@ulster.net>; Thu, 2 Dec 1999 10:54:52 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA00220 for linux-audio-dev-list; Thu, 2 Dec 1999 10:19:20 -0500
Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net [194.217.242.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA00217 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 2 Dec 1999 10:19:18 -0500
Received: from muse.demon.co.uk ([158.152.21.220] helo=bartman.plc.psion.com)
	by finch-post-12.mail.demon.net with smtp (Exim 2.12 #1)
	id 11tXvA-000OOe-0C; Thu, 2 Dec 1999 15:13:24 +0000
Received: by bartman.plc.psion.com with Microsoft Mail
	id <01BF3CD7.0F6CFFA0@bartman.plc.psion.com>; Thu, 2 Dec 1999 15:08:16 -0000
Message-ID: <01BF3CD7.0F6CFFA0@bartman.plc.psion.com>
From: "Richard W.E. Furse" <richard@muse.demon.co.uk>
To: "'Stefan Westerfeld'" <stefan@space.twc.de>
Cc: "'linux-audio-dev@ginette.musique.umontreal.ca'"
	 <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: RE: [linux-audio-dev] acid, linux
Date: Thu, 2 Dec 1999 15:04:02 -0000
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: fbd84bbe70c67ff2d59b8eac4e3c9acc

Perhaps we should talk - MNLib (http://www.muse.demon.co.uk/mn_index_html ) 
has a VERY powerful internal architecture for configuring and linking 
objects together. I've not published source mostly because I ought to look 
into publishing a paper or two. The approach you are describing works fine 
until the object structures start to become complex. A trivial example is a 
multi-channel mixer for which the number of channels is configurable, a 
more complex example I've been working with is an acoustic space model. 
Also, would you want to allow object grouping? Polyphonic synthesisers 
built from component objects? A few other things handled by the approach 
I've been using are feedback support and latency compensation.

Such issues might be considered too complex to bother about for 
standardised portable interfacing - it's been hard enough in raw C++, so 
fair enough. In which case I'm at least interested at level of providing 
support for 'plugins' using some straightforward interface or other and 
yours sounds sensible - perhaps I should write an aRt skeleton generator 
for MNLib. I'd prefer a dynamic loading approach to a process switching 
approach as last time I looked process switching wasn't terribly fast 
(well, compared to a virtual function call) although the flexibility to use 
both would be nice. Intuitively I prefer the idea of handling distributed 
processing using 'bridge' units (shm/TCP) maintained by higher-level 
organisation rather than leaving the OS to handle it - using the latter 
model makes timing information much harder to quantify.

-- Richard

-----Original Message-----
From:	Stefan Westerfeld [SMTP:stefan@space.twc.de]
Sent:	Thursday, December 02, 1999 1:19 AM
To:	MOULET Xavier CNET/DMR/ISS
Cc:	'linux-audio-dev@ginette.musique.umontreal.ca'
Subject:	Re: [linux-audio-dev] acid, linux

   Hi!

On Wed, Dec 01, 1999 at 05:56:56PM +0100, MOULET Xavier CNET/DMR/ISS wrote:
> [...]
>
> Thus, I am waiting eagerly of an implementation of the API discussions 
(or
> is there one ?), and of course, of an engine.
>
> Is there already one or many good engines fundations for such a thing ?
> Would Quasimodo (without the interface) do the job or is it too Csound
> oriented ?
> Raw Esd ? THE API (mucows (?)), aRts ? xmms ?

I can tell you what aRts is doing right now.

The idea I have is moving away from CORBA towards a lighter consistent
object model which spreads throughout aRts. The thing will be called
MCOP, which expands to multimedia communication protocol. But keep in
mind that it cares about communcation and object model (the things that
were handled by CORBA before).  One will write things like

interface Synth_ADD {
  in audio stream signal1, signal2;
  out audio stream result;
};

in an idl file, and it will generate C++ skeleton classes, which you
only need to implement. For Synth_ADD, this could look somthing along
the lines:

void SynthAdd_impl::calculateBlock(unsigned long cycles)
{
    float *end = result + cycles;
	
	while(result != end) *result++ = *signal1++ + *signal2++;
} 
   

that's about all you need to write. By the way, you could also have
something like

interface BinaryOperation {
  in audio stream signal1, signal2;
  out audio stream result;
};

interface Synth_ADD : BinaryOperation {
  //
};

which means you get the wonders of polymorphism and inheritance in your
plugin system.

The component communication will be handled transparently to the 
programmer,
and also whether it is in the same process space (linked as library), or in
another thread, or in another process or on a computer somewhere on the
network shall be transparent.

So using aRts as library should finally be possible for those who want
to do that. (This is really important for wave editors for instance). Also,
people will not any longer need to install mico to use aRts. Another
advantage is that the overhead is much much less.

Perhaps other people who are still considering whether they want to do
something similar could also join in. Basically, writing a middleware
like MCOP is a lot of work. It is more or less as complete as CORBA (at
least the relevant parts I used) in it's current development stadium,
though not everything works fine yet, but it supports

- remote method invocations
- inheritance
- multiple inheritance
- using components transparently as libs or remote
- do marshalling
- define own datatypes (e.g. structs and such) in the idl file, such as
  struct MidiEvent or struct FFTPacket
- C++ language binding (if you want - write a C implementation of MCOP,
  at least apps/plugins will be able to communicate properly then)

from my speed tests, it wins factor three against mico for synchronous
invocations, but the slowness is obtained by using a TCP transport, 
rewriting
that to sharedmem should give another major boost. Also, the real gain is
that you can support streaming, QoS, event transport, etc by your
communication layer, which was impossible to do with CORBA before.

KDE2 will use aRts as multimedia framework, which also means the sound
server that will be running for the desktop will be implemented on top
of that. It will also not necessarily remain an audio-only thing, video
for instance would also be great - but that has some time.

The engine is partially ported from CORBA, but it currently can't do more
than a beep (but at least that: fully modular) - also the plugins aren't
ported, and some infrastructure is still completely missing (Qt GUI stuff).

So the dependancies aRts has are reduced to: C++ with STL (no Qt, no Mico,
no KDE, no X11, if you really want not even Unix are required).

The code is available from the KDE CVS (kdemultimedia/arts), which you also
can get anonymously if you like via CVSup. It is still in its experimental
phase, but I'll port over all aRts infrastructure to MCOP in the next time,
though that may take a while.

   Cu... Stefan

PS: Please - everybody who is now writing something similar - step back a
second and think of you couldn't join aRts. What is missing?
--
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-

From - Thu Dec  2 11:58:37 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA20836
	for <slinkp@ulster.net>; Thu, 2 Dec 1999 11:24:12 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA00250 for linux-audio-dev-list; Thu, 2 Dec 1999 10:42:59 -0500
Received: from renoir.op.net (renoir.op.net [207.29.195.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA00246 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 2 Dec 1999 10:42:56 -0500
Received: from someip.ppp.op.net (d-bm3-00.ppp.op.net [209.152.194.64]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id KAA07782 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 2 Dec 1999 10:05:33 -0500 (EST)
Message-Id: <199912021505.KAA07782@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] acid, linux 
In-reply-to: Your message of "Thu, 02 Dec 1999 17:26:20 +0200."
             <Pine.LNX.4.10.9912021617280.692-100000@sculpcave.localdomain> 
Date: Thu, 02 Dec 1999 10:06:24 -0500
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 4c19755040d454bbb70b6da0dfd2e508

>2) When recording, I can use the -eaw effect (amplify w/ clip-control) 
>   in the recording chain to warn about clipping.

someone should implement a logarithmic/exponential clipping function
that asymptotically approaches ((2^bits_per_sample)-1) once the sample
amplitude exceeds ((2^bits_per_sample)-some_threshold).

for those who don't know, one implementation of this is patented by
apogee ("softlimit"), but there i suspect that their patent covers (1)
a fairly h/w-based implementation and (2) probably only cover a particular
function. 

the result is tape-like limiting. its very nice. you avoid
transient-induced clipping.

--p

From - Thu Dec  2 11:58:18 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA08154
	for <slinkp@ulster.net>; Thu, 2 Dec 1999 10:10:31 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA00136 for linux-audio-dev-list; Thu, 2 Dec 1999 09:41:15 -0500
Received: from sculpcave (ppp-9.wakkanet.fi [194.157.35.217]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA00133 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 2 Dec 1999 09:41:09 -0500
Received: from localhost (localhost [127.0.0.1])
	by sculpcave (Postfix) with ESMTP
	id E9CB134DB9; Thu,  2 Dec 1999 17:26:20 +0200 (EET)
Date: Thu, 2 Dec 1999 17:26:20 +0200 (EET)
From: Kai Vehmanen <kaiv@wakkanet.fi>
X-Sender: root@sculpcave.localdomain
To: Billy Biggs <vektor@DIV8.NET>
Cc: Paul Barton-Davis <pbd@Op.Net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] acid, linux
In-Reply-To: <19991201202630.A17641@div8.net>
Message-ID: <Pine.LNX.4.10.9912021617280.692-100000@sculpcave.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 8d12c57915c7c1c9dc3a0467475cea2f

On Wed, 1 Dec 1999, Billy Biggs wrote:

>> I didn't use GUI (qtecasound) for anything - all was done using 
>> the console-mode interface. [...]
> I don't see how you can do any audio work at all in console mode.  Personally,
> I find ecasound to be very powerful and cool, but to me it's mostly
> useless:

Hmm, now don't get me wrong, I didn't mean to say that console mode
UIs are better. As an example, SF SoundForge has a superb GUI.
I haven't used Acid, but I guess it's well designed as well. I'd 
like qtecasound to be as good, but the task seems almost impossible.
If I was developing commercial software this wouldn't be a issue 
(more code = more money ;)), but with free software this is a real
problem.

>   - If I'm recording a song, I _NEED_ to see peaks so that I can watch for
>     clipping.  Without being able to visually see incomming audio data, I could
>     finish recording a whole song without realizing that I clipped in the middle.

Yes, this is difficult, but not impossible.

1) When I start recording, I use ecasound's -ev effect to analyze
   volume level. I play a while -> check the statistics -> play some
   more -> check again -> etc...
2) When recording, I can use the -eaw effect (amplify w/ clip-control) 
   in the recording chain to warn about clipping.

These aren't very elegent, but they work.

>   - If I'm editing a song, I NEED to visually see the waveform.  Without that,
>     I don't see how you can do any reasonable audio editing.

This is more difficult. My advice is to use an external wave-editor
(that's what I do). I'll release a simple wave editor (ecawave) 
aimed at recording and mixing purposes sometime in Jan-Feb 2000.

>   - I don't want to have to keep typing to use an audio app.  It means using
>     both hands to do work on a keyboard, whereas the mouse lets me keep one
>     hand on my instrument.

Well, this is a matter of taste. I prefer to use keyboard shortcuts
even in GUI environment. 

>   - Cutting and pasting of audio files, splicing, and punching in, is pretty
>     much ridiculous without a GUI.

This is possible without a GUI, but once again I recommend using an
external editor.

>   BTW, take a look at my ttrk screenshot, http://www.div8.net/ttrk, to see the
> basis for a feasible ACID clone GUI.

I'm offline at the moment, but I'll check your site. This sounds 
interesting. All in all, I'd like to see more co-operation and code
reuse. I think this is the best way we can compete with commercial
audio apps. I admit that I'm not the best GUI designer in the world,
so any help is welcome. ;)

>> Currently qtecasound already has over 5000 lines of code, but still
>> it offers only the most basic features of ecasound libraries.
>   I don't think you're using Qt properly.

What did I just say. ;) Seriously, I'm not trying to say that 
"why use C++ when you can do the same with 10 lines of Visual Basic?". 
When writing a GUI, you just have to do more. 

As an example, the console mode UI can use formatted strings to 
handle various different components. In GUI environment you have
to write widgets for these. Ok, if you're clever, you can avoid
some work. For instance, it's fairly easy to write a generic
GUI for all effects. But what about MIDI-controllers, oscillators,
file objects, soundcard drivers? And of course, you need to have
some kind of widgets for connecting/using these components. 

>> But what's even worse (as you mentioned), writing GUI code is just 
>> *really* boring. You spend most of the time moving widgets from 
>   Programming a good GUI is more about design than programming.  That doesn't
> mean it's boring, it just means you have to design and not just fire off code.

Well, as a Eiffel/C++/OO-in-general advocate I'd say you can't
separate design and programming. Of course, design can mean different 
things. You might design clothes, web pages, programs, whatever. But 
here I'm talking about design in abstract level. And yes, you need to 
have a good design before you start writing a GUI. But this applies 
to all programming. However, fine-tuning object layout, writing
widgets, making connections, has nothing to do with design. It's
plain, boring work.

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav

From - Thu Dec  2 12:18:11 1999
Received: from mc-qout4.whowhere.com (mc-qout4.whowhere.com [209.185.123.18])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA28218
	for <slinkp@ulster.net>; Thu, 2 Dec 1999 12:08:48 -0500
Received: from Unknown/Local ([?.?.?.?]) by angelfire.com; Thu Dec  2 08:58:55 1999
To: slinkp@ulster.net
Date: Thu, 02 Dec 1999 11:58:55 -0500
From: "Paul Winkler" <slinkp@angelfire.com>
Message-ID: <PBKJOHIIJCMBAAAA@angelfire.com>
Mime-Version: 1.0
X-Sent-Mail: off
X-Mailer: MailCity Service
Subject: Fwd: Re: Malibu kurzweil synth documentation?
X-Sender-Ip: 208.242.164.116
Organization: Angelfire  (http://email.angelfire.com:80)
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 3566cc6e1c6fe738a22659ac25ae4ba3

 
--

--------- Forwarded Message ---------

DATE: Tue, 16 Nov 1999 12:49:44
From: tbtech@voyetra.com
To: "Paul Winkler" <slinkp@angelfire.com>

Paul,
	We will take your email into consideration.  In the mean time, 
however, Linux is not supported by us.  Thank you.

Regards,

Dan
Turtle Beach Tech Support
Voyetra Turtle Beach, Inc. 
Ph. 914-966-2150  
Fax.914-966-1093
tech@tbeach.com 
www.voyetra.com  www.tbeach.com

------ Original Message -----
To:             	tbtech@voyetra.com
Date sent:      	Tue, 16 Nov 1999 02:57:43 -0500
From:           	"Paul Winkler" <slinkp@angelfire.com>
Copies to:      	Send reply to:  	Subject:        	Re: Malibu kurzweil synth documentation?
Organization:   	Angelfire  (http://email.angelfire.com:80)

> Dan,
> 
> Thanks for the quick reply.
> 
> You wrote:
> >Paul,
> >	While we at Voyetra Turtle Beach understand the growing 
> >alternative OS market( Linux, BeOS,etc), currently we do not offer 
> >drivers or support for these OSes.
> 
> I certainly understand that-- every company works with limited resources
> and the Linux community is not yet a large market. However, I can't help
> pointing out that I am not asking for either drivers or support. The ALSA
> team has already written a driver that works very well for all features of
> the Malibu _except_ the Kurzweil synth.
> 
> All we would need is access to one document, which I assume already exists
> for your developers' internal use, that contains information on
> controlling the malibu's internal kurzweil synth.
> 
> Once such information became available to the ALSA team, we would have no
> further need of any assistance from Turtle Beach.
> 
> If you would prefer not to release such a document on the grounds of
> protecting trade secrets, I would like to point out:
> 
> 1) There's not much to protect -- everything about the Malibu except the
> Kurzweil chip is covered in Crystal's CS4237B data sheets.
> 
> 2) Being protective about the Malibu doesn't give you any competitive edge
> at this point-- I don't see the Malibu listed as a currently available
> soundcard on the Turtle Beach web page.
> 
> 3) Some of your competitors are already being very cooperative to the open
> source community. You may have heard the announcement that Creative Labs
> has released source code for a driver for the Soundblaster Live. Earlier,
> Trident was developing a driver for Linux for their 4D card and decided to
> turn the driver over to the ALSA team; as a result, they have
> simultaneously increased their market share and decreased their workload,
> since one advantage of releasing source code and / or documentation is
> that you can let the open source community do all the driver development
> for you.
> 
> I sincerely hope that you will reconsider releasing the documentation on
> the Kurzweil synth.
> 
> Thanks for your time,
> 
> PW
> 
> 
> Angelfire for your free web-based e-mail. http://www.angelfire.com


*******************************************************

Please check the VTB Tech Support Knowledge Base / FAQ: 
http://www.voyetra-turtle-beach.com/site/kb_ftp/kb.asp
Most of the questions asked by customers are covered here. 

The VTB KB/FAQ is open at all hours and regularly 
updated for your convenience - no waiting for a 
technician to take your call or return your e-mail, 
and no long-distance phone fees! 

*******************************************************
Please include your Product Id in the subject line of 
all email and include all previous correspondence in 
the body of the message.
*******************************************************
 
Turtle Beach Systems
Technical support (914)966-2150
Fax number (914)966-1093
Web URL:  http://www.tbeach.com
5 Odell Plaza, Yonkers, NY 10701-1406 USA

--------- End Forwarded Message ---------



Angelfire for your free web-based e-mail. http://www.angelfire.com

From - Thu Dec  2 12:18:13 1999
Received: from mc-qout4.whowhere.com (mc-qout4.whowhere.com [209.185.123.18])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA28358
	for <slinkp@ulster.net>; Thu, 2 Dec 1999 12:09:49 -0500
Received: from Unknown/Local ([?.?.?.?]) by angelfire.com; Thu Dec  2 08:59:29 1999
To: slinkp@ulster.net
Date: Thu, 02 Dec 1999 11:59:29 -0500
From: "Paul Winkler" <slinkp@angelfire.com>
Message-ID: <JPHKMMDFBDMBAAAA@angelfire.com>
Mime-Version: 1.0
X-Sent-Mail: off
X-Mailer: MailCity Service
Subject: Fwd: Re: Malibu kurzweil synth documentation?
X-Sender-Ip: 208.242.164.116
Organization: Angelfire  (http://email.angelfire.com:80)
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 30ec88322f4e820bfaf2d270fb3c146f

 
--

--------- Forwarded Message ---------

DATE: Mon, 15 Nov 1999 12:40:16
From: tbtech@voyetra.com
To: Paul Winkler <slinkp@angelfire.com>

Paul,
	While we at Voyetra Turtle Beach understand the growing 
alternative OS market( Linux, BeOS,etc), currently we do not offer 
drivers or support for these OSes.  This could change in the future.  
Please periodically visit our website for updated information about 
future support for non- Microsoft OSes.  Thank you for your 
understanding.


Regards,

Dan
Turtle Beach Tech Support
Voyetra Turtle Beach, Inc. 
Ph. 914-966-2150  
Fax.914-966-1093
tech@tbeach.com 
www.voyetra.com  www.tbeach.com

----- Original Message -----
Date sent:      	Sun, 14 Nov 1999 19:41:32 -0500
From:           	Paul Winkler <slinkp@angelfire.com>
To:             	tech@tbeach.com
Subject:        	Malibu kurzweil synth documentation?

> Hi Turtle Beach,
> 
> I've been using a TB Malibu quite happily for almost 2 years. I'm a
> Linux user and have found that the OSS drivers (from www.4front.com)
> support the Malibu pretty well; so do the free ALSA
> (www.alsa-project.org) drivers.
> 
> However, I'm now in a bit of a fix. I'm running up against some
> limitations of the OSS midi driver, and I would love to switch to
> the ALSA driver, which is developing a greatly improved linux MIDI
> driver. The only trouble is that ALSA  is so far unable to support
> the Malibu's onboard Kurzweil synth, which I need to use.
> 
> To quote ALSA project organizer Jaroslav Kysela:
> Jaroslav Kysela <perex@suse.cz> wrote:
> > Malibu seems to have the internal synthesizer connected to the MPU401
> > port, but I don't know how to initialize this connection :-(( If you get
> > specs from Turtle Beach, I'll enable it..
> 
> I hope you will consider releasing these specs. It seems to me that
> Turtle Beach has nothing to lose by doing this, and much good will
> to gain from the Open Source community. The ALSA project has not
> hesitated to recommend that their users buy products from companies
> that have cooperated with them. Most of the documentation for the
> Malibu is already available, since it uses the CS4237B chipset which
> Crystal Semi has released documents for. I am hoping Turtle Beach
> will acknowledge their Linux-using customers by releasing the
> documentation for the Kurzweil synth.
> 
> For more information on why releasing technical docs is a good idea,
> read:
> http://www.alsa-project.org/~cdavid/vendorinfo/call.html
> 
> Thanks very much,
> 
> PW
> 
> ................    paul winkler    ..................
> slinkP arts:   music, sound, illustration, design, etc.
> A member of ARMS    ----->    http://www.reacharms.com
> or http://www.mp3.com/arms or http://www.amp3.com/arms
> personal page   ---->    http://www.ulster.net/~abigoo


*******************************************************

Please check the VTB Tech Support Knowledge Base / FAQ: 
http://www.voyetra-turtle-beach.com/site/kb_ftp/kb.asp
Most of the questions asked by customers are covered here. 

The VTB KB/FAQ is open at all hours and regularly 
updated for your convenience - no waiting for a 
technician to take your call or return your e-mail, 
and no long-distance phone fees! 

*******************************************************
Please include your Product Id in the subject line of 
all email and include all previous correspondence in 
the body of the message.
*******************************************************
 
Turtle Beach Systems
Technical support (914)966-2150
Fax number (914)966-1093
Web URL:  http://www.tbeach.com
5 Odell Plaza, Yonkers, NY 10701-1406 USA

--------- End Forwarded Message ---------



Angelfire for your free web-based e-mail. http://www.angelfire.com

From - Thu Dec  2 12:58:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA03464
	for <slinkp@ulster.net>; Thu, 2 Dec 1999 12:56:04 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA00388 for linux-audio-dev-list; Thu, 2 Dec 1999 12:23:49 -0500
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA00385 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 2 Dec 1999 12:23:46 -0500
Received: from ulster.net (port116.ts2.ulster.net [208.242.164.116])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id MAA31179;
	Thu, 2 Dec 1999 12:27:21 -0500
Message-ID: <3846AC1C.9582B45B@ulster.net>
Date: Thu, 02 Dec 1999 12:27:56 -0500
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Barton-Davis <pbd@Op.Net>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] acid, linux
References: <199912021505.KAA07782@renoir.op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 46092d73d0494c95326674d1af7d6123

Paul Barton-Davis wrote:
> 
> >2) When recording, I can use the -eaw effect (amplify w/ clip-control)
> >   in the recording chain to warn about clipping.
> 
> someone should implement a logarithmic/exponential clipping function
> that asymptotically approaches ((2^bits_per_sample)-1) once the sample
> amplitude exceeds ((2^bits_per_sample)-some_threshold).

Couldn't you just do this with waveshaping, using a table lookup?
Use the input as the index, and fill the table with a straight line
up to the threshold level, then some sort of curve beyond that (but
what sort of curve I guess would be the question). I know some
people are doing this in csound, though I don't know what gen
routine they use for making the table.

-- 
................    paul winkler    ..................
slinkP arts:   music, sound, illustration, design, etc.
A member of ARMS    ----->    http://www.reacharms.com
or http://www.mp3.com/arms or http://www.amp3.com/arms
personal page   ---->    http://www.ulster.net/~abigoo

From - Thu Dec  2 14:18:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA16400
	for <slinkp@ulster.net>; Thu, 2 Dec 1999 14:16:18 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA00502 for linux-audio-dev-list; Thu, 2 Dec 1999 13:40:59 -0500
Received: from iona.abel.net.uk (iona.abel.net.uk [212.1.130.142]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA00499 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 2 Dec 1999 13:40:51 -0500
Message-Id: <199912021840.NAA00499@ginette.musique.umontreal.ca>
Received: (qmail 23252 invoked from network); 2 Dec 1999 18:34:56 -0000
Received: from ppp-1-121.cvx2.telinco.net (HELO default) (212.1.144.121)
  by iona.abel.net.uk with SMTP; 2 Dec 1999 18:34:56 -0000
From: "Paul Kellett" <paul.kellett@maxim.abel.co.uk>
To: <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] acid, linux 
Date: Thu, 2 Dec 1999 18:21:48 -0000
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 9efa92cc37788162370bc8e329df5889

> someone should implement a logarithmic/exponential clipping function
> that asymptotically approaches ((2^bits_per_sample)-1) once the sample
> amplitude exceeds ((2^bits_per_sample)-some_threshold).
> 
> the result is tape-like limiting. its very nice. you avoid
> transient-induced clipping.


You may as well use a _real_ limiter - no distortion until you start driving
it really hard. Simple example - limits mono floating-point data to +/-1:

 rec=(sig>0.f)? sig : -sig;     //rectify signal
 env=(rec>env)? rec : env*rel;  //slow release envelope
 if(env>1.f) sig/=env;          //limit



Paul.

-- 
paul.kellett@maxim.abel.co.uk
http://www.abel.co.uk/~maxim/

From - Thu Dec  2 15:08:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA22760
	for <slinkp@ulster.net>; Thu, 2 Dec 1999 14:57:44 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA00572 for linux-audio-dev-list; Thu, 2 Dec 1999 14:24:27 -0500
Received: from cs.tut.fi (varis.cs.tut.fi [130.230.4.42]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA00569 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 2 Dec 1999 14:24:24 -0500
Received: from kalalokki.cs.tut.fi (jams@kalalokki.cs.tut.fi [130.230.14.118])
	by cs.tut.fi (8.8.8/8.8.8) with ESMTP id VAA01480;
	Thu, 2 Dec 1999 21:18:52 +0200 (EET)
Received: (from jams@localhost)
          by kalalokki.cs.tut.fi (8.8.5/8.8.4)
	  id VAA07204; Thu, 2 Dec 1999 21:18:52 +0200 (EET)
To: Paul Barton-Davis <pbd@Op.Net>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] acid, linux
References: <199912021505.KAA07782@renoir.op.net>
From: jams@cs.tut.fi (Jarno Seppanen)
Reply-To: jams@cs.tut.fi (Jarno Seppanen)
X-Url: http://www.modeemi.cs.tut.fi/~jams/
Date: 02 Dec 1999 21:18:51 +0200
In-Reply-To: Paul Barton-Davis's message of "Thu, 02 Dec 1999 10:06:24 -0500"
Message-ID: <ruvbt89rw10.fsf@kalalokki.cs.tut.fi>
Lines: 30
X-Mailer: Gnus v5.7/Emacs 20.4
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: RO
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 18dfc3a81d5f4c1390e3e5e18ce07c92

Paul Barton-Davis <pbd@Op.Net> writes:

> someone should implement a logarithmic/exponential clipping function
> that asymptotically approaches ((2^bits_per_sample)-1) once the sample
> amplitude exceeds ((2^bits_per_sample)-some_threshold).
> 
> for those who don't know, one implementation of this is patented by
> apogee ("softlimit"), but there i suspect that their patent covers (1)
> a fairly h/w-based implementation and (2) probably only cover a particular
> function. 

Well, this is a soft clipping code snippet from "Out Of Phase" anno 1994.  It
is essentially a waveshaper with a nice smooth waveshaping function.  If I
recall correctly, it starts to soft clip at +-1 and CurrentLimitingExcess is
the hard clipping threshold.

  if (X > 1)
    {
      /* X exceeds normal channel boundary on top, apply limiter */
      X = 1 + FATAN((X - 1) * HALFPI / (Compressor->CurrentLimitingExcess - 1))
        / (HALFPI / (Compressor->CurrentLimitingExcess - 1));
    }
  else if (X < -1)
    {
      /* X exceeds normal channel boundary on bottom, apply limiter */
      X = -1 + FATAN((X + 1) * HALFPI / (Compressor->CurrentLimitingExcess - 1))
        / (HALFPI / (Compressor->CurrentLimitingExcess - 1));
  
-- 
-Jarno

From - Thu Dec  2 14:38:31 1999
Received: from renoir.op.net (root@renoir.op.net [207.29.195.4])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id OAA19064
	for <slinkp@ulster.net>; Thu, 2 Dec 1999 14:34:27 -0500
Received: from someip.ppp.op.net (d-bm3-1d.ppp.op.net [209.152.194.93]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id OAA16798; Thu, 2 Dec 1999 14:24:17 -0500 (EST)
Message-Id: <199912021924.OAA16798@renoir.op.net>
To: Paul Winkler <slinkp@ulster.net>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] acid, linux 
In-reply-to: Your message of "Thu, 02 Dec 1999 12:27:56 EST."
             <3846AC1C.9582B45B@ulster.net> 
Date: Thu, 02 Dec 1999 14:24:41 -0500
From: Paul Barton-Davis <pbd@Op.Net>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 9b9ed834313976296e814bb4c52703c6

In message <3846AC1C.9582B45B@ulster.net>you write:
>Paul Barton-Davis wrote:
>> 
>> >2) When recording, I can use the -eaw effect (amplify w/ clip-control)
>> >   in the recording chain to warn about clipping.
>> 
>> someone should implement a logarithmic/exponential clipping function
>> that asymptotically approaches ((2^bits_per_sample)-1) once the sample
>> amplitude exceeds ((2^bits_per_sample)-some_threshold).
>
>Couldn't you just do this with waveshaping, using a table lookup?
>Use the input as the index, and fill the table with a straight line
>up to the threshold level, then some sort of curve beyond that (but

now that you mention, i think one can do it more space-efficiently
than this:

    if (*sample > threshold) {
         *sample = table[*sample-threshold];
    }

this doesn't save much for 16 bit samples, but if you're going to use,
say, 24 bit samples, do you really want a 16MB table for lookups ? not
me - i'd just use a table for values over the threshold.

and yes, missing the branch prediction on the conditional is
expensive, but its really not our job to worry about that :)

--p

From - Thu Dec  2 16:08:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA01405
	for <slinkp@ulster.net>; Thu, 2 Dec 1999 16:06:42 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA00682 for linux-audio-dev-list; Thu, 2 Dec 1999 15:37:38 -0500
Received: from zapfhahn.bone.twc.de (zapfhahn.bone.twc.de [193.158.34.194]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA00679 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 2 Dec 1999 15:37:34 -0500
Received: from space.twc.de (IDENT:stefan@space.twc.de [193.158.34.195])
	by zapfhahn.bone.twc.de (8.9.3/8.9.3) with ESMTP id WAA02769;
	Thu, 2 Dec 1999 22:31:02 +0100
Received: (from stefan@localhost)
	by space.twc.de (8.8.7/8.8.7) id WAA18344;
	Thu, 2 Dec 1999 22:35:21 +0100
Message-ID: <19991202223520.05594@space.twc.de>
Date: Thu, 2 Dec 1999 22:35:20 +0100
From: "'Stefan Westerfeld'" <stefan@space.twc.de>
To: "Richard W.E. Furse" <richard@muse.demon.co.uk>
Cc: "'linux-audio-dev@ginette.musique.umontreal.ca'" <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] acid, linux
References: <01BF3CD7.0F6CFFA0@bartman.plc.psion.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.85e
In-Reply-To: <01BF3CD7.0F6CFFA0@bartman.plc.psion.com>; from Richard W.E. Furse on Thu, Dec 02, 1999 at 03:04:02PM -0000
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 89a8e714bc66d574a24eb0b458687a3d

   Hi!

On Thu, Dec 02, 1999 at 03:04:02PM -0000, Richard W.E. Furse wrote:
> Perhaps we should talk - MNLib (http://www.muse.demon.co.uk/mn_index_html ) 
> has a VERY powerful internal architecture for configuring and linking 
> objects together. I've not published source mostly because I ought to look 
> into publishing a paper or two.
So I can't really see how it is built and how aRts compares to it.

> The approach you are describing works fine 
> until the object structures start to become complex. A trivial example is a 
> multi-channel mixer for which the number of channels is configurable, a 
> more complex example I've been working with is an acoustic space model. 
> Also, would you want to allow object grouping? Polyphonic synthesisers 
> built from component objects? A few other things handled by the approach 
> I've been using are feedback support and latency compensation.

Well, yes I want to do all that. The current aRts already provides something
like a "multichannel mixer" with configurable channel count, though the
current implementation is a hack ;)

Object composition (which seems to be what you mean with your last two points)
should be supported as well. So for instance, you can draw the flow graph for
one voice of a synthetic instrument (such as a synthetic string), and
parametrize this by velocity, pitch and some other parameters which you may
want to configure by GUI or by midi effect, or whatever else. Then you can
take some kind of routing object, which will start per-voice instantiations
of that structure as required while playing an incoming midi stream.

The current aRts does that already. Feedback support has also been in aRts
since quite some time. (Though not yet ported to the MCOP version in the CVS).

What you mean with latency compensation isn't quite clear to me. If you mean
timestamping for instance incoming events from the midi sequencer and then
play them exactly, (I mean: too late, but each event exactly the same time
too late) - I've thought of that. However, it is not in aRts currently,
though if somebody comes up with a plan how to implement that properly and
consistent, no problem.

The main problem seems to be that if your sequencer says "play that at 1.324s
from start", you need some exact source of timing, which is completely
identical to all partners of the communication - which is bad if you can
play midi events only after the "now" or the "midi clock" scheme, and audio
only after the "sample clock" scheme, because those are no identical sources
of time.

> Such issues might be considered too complex to bother about for 
> standardised portable interfacing - it's been hard enough in raw C++, so 
> fair enough. In which case I'm at least interested at level of providing 
> support for 'plugins' using some straightforward interface or other and 
> yours sounds sensible - perhaps I should write an aRt skeleton generator 
> for MNLib.

As I don't know how MNLib looks internally, I can't comment on that. However
about complexity:

The idea behind aRts is, that you handle the complexity (synchronization,
recursive flow, communication, threading, io, scheduling) outside the
plugins, and use those real simple plugin implementations.

Using the IDL, skeletons and whatever else, I think that goal is implementable.
The plugin writer won't be bothered with things like that, though they will
work, because the aRts framework takes care of them.

> I'd prefer a dynamic loading approach to a process switching 
> approach as last time I looked process switching wasn't terribly fast 
> (well, compared to a virtual function call) although the flexibility to use 
> both would be nice.

Yes. The idea was that you can decide later if you want threading, virtual
function call or multiple processes, if you do it with the IDL and middleware
thing.

> Intuitively I prefer the idea of handling distributed 
> processing using 'bridge' units (shm/TCP) maintained by higher-level 
> organisation rather than leaving the OS to handle it - using the latter 
> model makes timing information much harder to quantify.

Yes - and that higher level organisation would be the aRts MCOP layer, which
also makes it possible to exchange SHM/TCP by a specially adapted kernel
extension only for aRts, if you really want that. (MidiShare seems to do
it that way, implementing a message passing thing in the kernel, though
it wasn't stable as I tried it).


Regarding the MNLib issue: as I see it, the most sensible thing to do would
be linking MNLib against libmcop (and perhaps libartsflow), if it's a thing
that offers something that you can't break up in aRts components. So you
would have access to the aRts components, flow graphing, scheduling, and
plugin loading and whatever. On the other hand you could do whatever magic
isn't implementable using aRts flow stuff seperately.

If MNLib can be broken into aRts components completely, that would be even
better.

Regarding licensing issues: of course I can't depend aRts on something 
(currently) closed source like MNLib. I could go using windows and VST
then, instead ;). If you on the other hand want to depend MNLib on the
aRts infrastructure, it would be no problem, the relevant parts of aRts
are supposed to be LGPLd.

Merging would only be possible if MNLib was free, too.

Switching aRts to MNLib completely would be possible if starting from aRts
would be more work than starting from MNLib to get where I want to get.
Well, but as I can't even look at the code, I can't say anything about
MNLib right now.

   Cu... Stefan

> -----Original Message-----
> From:	Stefan Westerfeld [SMTP:stefan@space.twc.de]
> Sent:	Thursday, December 02, 1999 1:19 AM
> To:	MOULET Xavier CNET/DMR/ISS
> Cc:	'linux-audio-dev@ginette.musique.umontreal.ca'
> Subject:	Re: [linux-audio-dev] acid, linux
> 
>    Hi!
> 
> On Wed, Dec 01, 1999 at 05:56:56PM +0100, MOULET Xavier CNET/DMR/ISS wrote:
> > [...]
> >
> > Thus, I am waiting eagerly of an implementation of the API discussions 
> (or
> > is there one ?), and of course, of an engine.
> >
> > Is there already one or many good engines fundations for such a thing ?
> > Would Quasimodo (without the interface) do the job or is it too Csound
> > oriented ?
> > Raw Esd ? THE API (mucows (?)), aRts ? xmms ?
> 
> I can tell you what aRts is doing right now.
> 
> The idea I have is moving away from CORBA towards a lighter consistent
> object model which spreads throughout aRts. The thing will be called
> MCOP, which expands to multimedia communication protocol. But keep in
> mind that it cares about communcation and object model (the things that
> were handled by CORBA before).  One will write things like
> 
> interface Synth_ADD {
>   in audio stream signal1, signal2;
>   out audio stream result;
> };
> 
> in an idl file, and it will generate C++ skeleton classes, which you
> only need to implement. For Synth_ADD, this could look somthing along
> the lines:
> 
> void SynthAdd_impl::calculateBlock(unsigned long cycles)
> {
>     float *end = result + cycles;
> 	
> 	while(result != end) *result++ = *signal1++ + *signal2++;
> } 
>    
> 
> that's about all you need to write. By the way, you could also have
> something like
> 
> interface BinaryOperation {
>   in audio stream signal1, signal2;
>   out audio stream result;
> };
> 
> interface Synth_ADD : BinaryOperation {
>   //
> };
> 
> which means you get the wonders of polymorphism and inheritance in your
> plugin system.
> 
> The component communication will be handled transparently to the 
> programmer,
> and also whether it is in the same process space (linked as library), or in
> another thread, or in another process or on a computer somewhere on the
> network shall be transparent.
> 
> So using aRts as library should finally be possible for those who want
> to do that. (This is really important for wave editors for instance). Also,
> people will not any longer need to install mico to use aRts. Another
> advantage is that the overhead is much much less.
> 
> Perhaps other people who are still considering whether they want to do
> something similar could also join in. Basically, writing a middleware
> like MCOP is a lot of work. It is more or less as complete as CORBA (at
> least the relevant parts I used) in it's current development stadium,
> though not everything works fine yet, but it supports
> 
> - remote method invocations
> - inheritance
> - multiple inheritance
> - using components transparently as libs or remote
> - do marshalling
> - define own datatypes (e.g. structs and such) in the idl file, such as
>   struct MidiEvent or struct FFTPacket
> - C++ language binding (if you want - write a C implementation of MCOP,
>   at least apps/plugins will be able to communicate properly then)
> 
> from my speed tests, it wins factor three against mico for synchronous
> invocations, but the slowness is obtained by using a TCP transport, 
> rewriting
> that to sharedmem should give another major boost. Also, the real gain is
> that you can support streaming, QoS, event transport, etc by your
> communication layer, which was impossible to do with CORBA before.
> 
> KDE2 will use aRts as multimedia framework, which also means the sound
> server that will be running for the desktop will be implemented on top
> of that. It will also not necessarily remain an audio-only thing, video
> for instance would also be great - but that has some time.
> 
> The engine is partially ported from CORBA, but it currently can't do more
> than a beep (but at least that: fully modular) - also the plugins aren't
> ported, and some infrastructure is still completely missing (Qt GUI stuff).
> 
> So the dependancies aRts has are reduced to: C++ with STL (no Qt, no Mico,
> no KDE, no X11, if you really want not even Unix are required).
> 
> The code is available from the KDE CVS (kdemultimedia/arts), which you also
> can get anonymously if you like via CVSup. It is still in its experimental
> phase, but I'll port over all aRts infrastructure to MCOP in the next time,
> though that may take a while.
> 
>    Cu... Stefan
> 
> PS: Please - everybody who is now writing something similar - step back a
> second and think of you couldn't join aRts. What is missing?
> --
>   -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
>      KDE Developer, project infos at http://space.twc.de/~stefan/kde *-

-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-

From - Fri Dec  3 10:39:11 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA13974
	for <slinkp@ulster.net>; Thu, 2 Dec 1999 17:17:43 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA00783 for linux-audio-dev-list; Thu, 2 Dec 1999 16:46:48 -0500
Received: from mout1.01019freenet.de (mout1.01019freenet.de [62.104.201.3]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA00780 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 2 Dec 1999 16:46:44 -0500
From: depet@gmx.de
Received: from [62.104.201.6] (helo=mx0.01019freenet.de)
	by mout1.01019freenet.de with esmtp (Exim 3.10 #1)
	id 11tdyO-0007Er-00
	for linux-audio-dev@ginette.musique.umontreal.ca; Thu, 02 Dec 1999 22:41:08 +0100
Received: from [212.81.223.81] (helo=Nirvana.Saustall)
	by mx0.01019freenet.de with esmtp (Exim 3.10 #2)
	id 11tdyN-0005Mx-00
	for linux-audio-dev@ginette.musique.umontreal.ca; Thu, 02 Dec 1999 22:41:07 +0100
Message-ID: <XFMail.991202225250.depet@gmx.de>
X-Mailer: XFMail 1.3 [p0] on Linux
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <3846AC1C.9582B45B@ulster.net>
Date: Thu, 02 Dec 1999 22:52:50 +0100 (CET)
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] acid, linux
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 46d9bb585f7a0ba92caba7c0b51cd20f


> Couldn't you just do this with waveshaping, using a table lookup?
> Use the input as the index, and fill the table with a straight line
> up to the threshold level, then some sort of curve beyond that (but
> what sort of curve I guess would be the question). I know some
> people are doing this in csound, though I don't know what gen
> routine they use for making the table.
> 

yes, but this would waste around 32k, I'd only do
if(sample>start_limit_value) sample=kill_tape(sample);

I want to implement something like this in my realtime effects thingy ldse
since the algo it's using now is pretty bad for this job and the people at the
music-dsp list tend to be very quiet about algos...

the simplest function would be
(first hard clip the sample to 2**bits_per_sample):

f(x)=start_limit_value+thresh*sin(x*(PI/2)/thresh-start_limit_value)
bad thing: tangent in starting point isn't 45, how to avoid this?

how to do this with some sort of f(x)=a+m*log(x**n+b)?

my math got pretty rusty, it's scarry because I'm only half a year out of
school :-/

...o..oO0 NoehliE 0Oo..o...

From - Fri Dec  3 10:39:14 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA24359
	for <slinkp@ulster.net>; Thu, 2 Dec 1999 18:22:16 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA00892 for linux-audio-dev-list; Thu, 2 Dec 1999 17:57:01 -0500
Received: from zapfhahn.bone.twc.de (zapfhahn.bone.twc.de [193.158.34.194]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA00889 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 2 Dec 1999 17:56:56 -0500
Received: from space.twc.de (IDENT:stefan@space.twc.de [193.158.34.195])
	by zapfhahn.bone.twc.de (8.9.3/8.9.3) with ESMTP id AAA03946;
	Fri, 3 Dec 1999 00:50:27 +0100
Received: (from stefan@localhost)
	by space.twc.de (8.8.7/8.8.7) id AAA18899;
	Fri, 3 Dec 1999 00:54:45 +0100
Message-ID: <19991203005445.40357@space.twc.de>
Date: Fri, 3 Dec 1999 00:54:45 +0100
From: Stefan Westerfeld <stefan@space.twc.de>
To: Paul Barton-Davis <pbd@Op.Net>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] acid, linux
References: <19991202021830.45633@space.twc.de> <199912020356.WAA27901@renoir.op.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.85e
In-Reply-To: <199912020356.WAA27901@renoir.op.net>; from Paul Barton-Davis on Wed, Dec 01, 1999 at 10:57:11PM -0500
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 94d3acf4db6c23a7c981e18f39b68385

   Hi!

On Wed, Dec 01, 1999 at 10:57:11PM -0500, Paul Barton-Davis wrote:
> >PS: Please - everybody who is now writing something similar - step back a
> >second and think of you couldn't join aRts. What is missing?
> 
> i don't want this to be read as an "aRts-bashing" letter. i think
> there are lots of things to like about aRts. however, stefan did ask,
> so ...

I'll read it as constructive criticism ;) Perhaps I can also make the
direction a bit more clear, since aRts seems to be one of the projects
nobody really knows what exactly it is ... I should really document
the aRts/MCOP plans/internals/visions somewhere.

> what i *think* is missing is an easy way to access the power of the
> Music V/unit generator (UG) model that emerged out of academic
> computer music over the course of 30 years or so.
> 
> aRts is a very nice system, but its fundamentally based around the
> idea of having to be a "real programmer" to be able to provide new
> functionality for it. [...]
> individual users who understand very little of the workings of the
> engine or programming languages (let alone IDL's) can develop very
> interesting new "instruments".

What I did just show you in the last mail is about the "raw internals"
of aRts. How it looks inside.

On the surface, it will be still UG model, so every normal user can draw
flow graphs, using simple modules "real programmers" wrote. So you write
a sine oscillator, add module, multiply module, triangle oscillator and
some filters. People can then build their synthstrings themselves, without
knowing anything about how these modules actually work (let alone IDLs).

When the UG model was developed, the normal "academic way" to make music
was to write a piece of music in your text editor, describe the instruments
also in a text editor (using these nice opcodes). Then you would put your
computer to work, and after 20 hours of calculation, you would hear the
result. Compiler like music creation. Like LaTeX for writing books.

But today, people want something that is interactive at every point, greatly
integrated with the GUI, easy to understand (at least first steps) even if
you have no clue about anything, visually attractive, etc.

When people are using AudioLogic or CuBase and these various Plugins,
Softsynths and whatever, they get a lot more of what they expect than
if they are using CSound and Emacs.

> [...]
> 
> another criticism i would make of aRts is the centrality of MIDI. most
> people familiar with MIDI know that its representation of pitch leaves
> a great deal to be desired, yet the notion of MIDI interconnections
> between aRts structures seems fairly fundamental to the whole
> program. removing MIDI from the core of Quasimodo is one of my
> projects for the new year.

There are some modules which deal with MIDI, and to those the thing is
fairly important. However, midi instruments currently are somewhat tied
to midi, and kludgy implemented in the arts core. For instance, you can't
use a midi instrument for something else than for midi. I suppose to be able
to get around all this by looking at these instruments again as objects.

So that goal for the next year we share between aRts and Quasimodo. ;)

> finally, its not clear to me the formalization of an object
> relationship between the synthesis engine and a user interface needs
> or even should be taken to the extreme that aRts does.

Let's say: it's not proven that it's really a great thing to do it like
aRts does, but I suppose it is (though certainity only comes if you go
that way quite a while and see if it proves successful - somebody's got
to try it).

Note however the relationship between the modules (or if you like) opcodes
needs to be formally defined in any case for useful editing, and using the
same formal definitions for "opcodes" and "widgets" - which happen to be
something similar in aRts - seemed to be a good idea.

> i think one can
> follow Michael Gogins' lead with his proposal for a Csound engine API
> - i don't think that one needs a model that looks anything like CORBA
> (or the new MCOP). As long as some entity within a program exists that
> supports the function calls and data present in the API, then the
> program will get what it requests. It seems to me that placing the
> emphasis on inter-object communication instead of object API's leads
> one down a strange path for a real-time low latency application.

Well, what I observed is: whatever datatypes you want for "opcodes",
you will also want to edit them in the GUI. Whatever data you communicate
between "opcodes", some day, you will have the need to visualize them.

When you are constructing flow graphs, they shall be tightly coupled to
corresponding GUI elements (or at least that should be possible). When
building larger plugins, they should have larger GUIs.

For instance if you have an opcode (to use the UG related terminilogy)
which takes filter coefficients or which produces FFT packets, the day will
come where anybody wants to modify the filter coefficients and the FFT
packets manually.

Of course, you can include FFT packets, and filter coefficients, and Midi
Events, and whatever in the aRts core API. But I want people to be able
to extend things even when they are not in the core API. Instead, the core
API should only contain some essential things.

I am not sure about possible other approaches, but having real objects,
real communication between objects, and for instance "real saving" of
GUI objects seems the easiest way to achieve in aRts what I stated above
as goals: consistent GUI integration throughout the system, interactivity
at any point, ...

> but to reiterate - i think that aRts is a very interesting and
> valuable program, and i hope that it continues to grow and succeed.

Thanks! ;)  We could also try hard to reach interoperability between
aRts and Quasimodo (that could be an even more valuable goal for the
new year than throwing out midi of the respective core's ;), as we'll
probably both continue to go our own way in the next time.

  Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-

From - Fri Dec  3 10:39:18 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA00873
	for <slinkp@ulster.net>; Thu, 2 Dec 1999 22:54:12 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA01340 for linux-audio-dev-list; Thu, 2 Dec 1999 22:02:49 -0500
Received: from hme0.smtp04.sprint.ca (hme0.smtp04.sprint.ca [207.107.250.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA01337 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 2 Dec 1999 22:02:46 -0500
Received: from vektor.div8.net (root@spc-isp-ktc-uas-9-30.sprint.ca [209.148.133.181])
	by hme0.smtp04.sprint.ca (8.8.8/8.8.8) with ESMTP id VAA03449;
	Thu, 2 Dec 1999 21:57:12 -0500 (EST)
Received: by div8.net
	via sendmail from stdin
	id <m11tiVy-00096VC@vektor.div8.net> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Thu, 2 Dec 1999 21:32:06 -0500 (EST) 
Date: Thu, 2 Dec 1999 21:32:06 -0500
From: Billy Biggs <vektor@DIV8.NET>
To: Kai Vehmanen <kaiv@wakkanet.fi>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] acid, linux
Message-ID: <19991202213206.A21589@div8.net>
Mail-Followup-To: Kai Vehmanen <kaiv@wakkanet.fi>,
	linux-audio-dev@ginette.musique.umontreal.ca
References: <19991201202630.A17641@div8.net> <Pine.LNX.4.10.9912021617280.692-100000@sculpcave.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <Pine.LNX.4.10.9912021617280.692-100000@sculpcave.localdomain>; from kaiv@wakkanet.fi on Thu, Dec 02, 1999 at 05:26:20PM +0200
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 32109483dd097e55631b93f69845b793

Kai Vehmanen (kaiv@wakkanet.fi):

> >   - If I'm editing a song, I NEED to visually see the waveform.  Without that,
> >     I don't see how you can do any reasonable audio editing.
> 
> This is more difficult. My advice is to use an external wave-editor
> (that's what I do). I'll release a simple wave editor (ecawave) 
> aimed at recording and mixing purposes sometime in Jan-Feb 2000.

  What wave editor do you currently use for Linux?  I haven't found one that
doesn't try to load the whole wave into memory.  This doesn't work very well
on multiple 80-meg soundfiles.

> [...] However, fine-tuning object layout, writing widgets, making
> connections, has nothing to do with design. It's plain, boring work.

  It's this sort of attitude that's really hurting free software, in my
opinion.  Writing effective GUIs and intuitive GUIs is definitely a design
challenge.  But, I do see your point, and realize that many people find it very
boring.

  Personally, I find it a worthy and important challenge.

--
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

From - Fri Dec  3 10:39:21 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id FAA27696
	for <slinkp@ulster.net>; Fri, 3 Dec 1999 05:00:36 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id EAA06100 for linux-audio-dev-list; Fri, 3 Dec 1999 04:32:14 -0500
Received: from nic.funet.fi (nic.funet.fi [193.166.0.145]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA06097 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 3 Dec 1999 04:32:11 -0500
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S32306AbPLCJ0T>; Fri, 3 Dec 1999 11:26:19 +0200
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <19991202213206.A21589@div8.net> (message from Billy Biggs on
	Thu, 2 Dec 1999 21:32:06 -0500)
Subject: Re: [linux-audio-dev] acid, linux
References: <19991201202630.A17641@div8.net> <Pine.LNX.4.10.9912021617280.692-100000@sculpcave.localdomain> <19991202213206.A21589@div8.net>
Message-Id: <19991203092624Z32306-289+3710@nic.funet.fi>
Date:   Fri, 3 Dec 1999 11:26:19 +0200
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 950b49f6a4d76419c388aee84457592e

>From:   Billy Biggs <vektor@div8.net>
>
>  What wave editor do you currently use for Linux?  I haven't found one that
>doesn't try to load the whole wave into memory.  This doesn't work very well
>on multiple 80-meg soundfiles.

Use XWave or Kwave instead.

Juhana

From - Fri Dec  3 10:39:24 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id IAA13024
	for <slinkp@ulster.net>; Fri, 3 Dec 1999 08:55:17 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA06350 for linux-audio-dev-list; Fri, 3 Dec 1999 08:23:12 -0500
Received: from renoir.op.net (renoir.op.net [207.29.195.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA06347 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 3 Dec 1999 08:23:09 -0500
Received: from someip.ppp.op.net (d-bm3-0a.ppp.op.net [209.152.194.74]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id IAA25061 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 3 Dec 1999 08:17:33 -0500 (EST)
Message-Id: <199912031317.IAA25061@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] acid, linux 
In-reply-to: Your message of "Fri, 03 Dec 1999 00:54:45 +0100."
             <19991203005445.40357@space.twc.de> 
Date: Fri, 03 Dec 1999 08:18:37 -0500
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d7e0a4f8edeea710e6482d2da5b8db00

>On the surface, it will be still UG model, so every normal user can draw
>flow graphs, using simple modules "real programmers" wrote. So you write
>a sine oscillator, add module, multiply module, triangle oscillator and
>some filters. People can then build their synthstrings themselves, without
>knowing anything about how these modules actually work (let alone IDLs).

i don't think that people want to draw flow graphs. flow graphs are a
programmers conception. people want to create interconnections between
elements. as i am all too painfully aware, the flow graph is *not* the
same as the interconnections they create. its very closely related, of
course. 

i don't see a UG model in aRts. your "modules" are fairly complex
units. they correspond more closely to Csound instruments than to
Csound opcodes, which are the real heart of a UG system.

>When the UG model was developed, the normal "academic way" to make music
>was to write a piece of music in your text editor, describe the instruments
>also in a text editor (using these nice opcodes). Then you would put your
>computer to work, and after 20 hours of calculation, you would hear the
>result. Compiler like music creation. Like LaTeX for writing books.
>
>But today, people want something that is interactive at every point, greatly
>integrated with the GUI, easy to understand (at least first steps) even if
>you have no clue about anything, visually attractive, etc.
>
>When people are using AudioLogic or CuBase and these various Plugins,
>Softsynths and whatever, they get a lot more of what they expect than
>if they are using CSound and Emacs.

i agree absolutely - how could i have ever written quasimodo if i
didn't ? :) but i think we should be leveraging from the accumulated
wisdom, source code and design skills that have come with the
evolution of those systems. quasimodo was an attempt to prove that this
could be done: take the UG's (opcodes) from Csound but let people use
them as in a Pulsar/Nord Modular/Kyma kind of way.

>Note however the relationship between the modules (or if you like) opcodes
>needs to be formally defined in any case for useful editing, and using the
>same formal definitions for "opcodes" and "widgets" - which happen to be
>something similar in aRts - seemed to be a good idea.

i think i might need to clarify something. In quasimodo, modules and
opcodes are very different. the relationship is like this:

	a Module is an object containing a ProgramTemplate.

	a ProgramTemplate is essentially a position-independent
	representation of a Program - all pointer references 
	to Module-specific data are relative to some starting point.

	a Program is an instantiation of a ProgramTemplate, and 
	consists of 2 linked list of pointers to functions, one
	of which is executed when the Program is started, and one
	whenever the DSP engine executes this particular Program.

	the linked list of pointers to functions point to opcode functions.

	a Process is an object that contains a Program, and a memory
	allocation for the data used by the Program. A Process is
	created by taking a Module object, allocating memory for
	the Module-local data, then doing run-time editing on a copy of
	the ProgramTemplate to fix up all the relative addresses.
	The result is an object that can be handed to the DSP object
	for initialization and execution.

	a ModuleDefinition is an object that represents (part) of a file that
	defines a Module. it can written in a variety of languages,
	currently just Csound's orchestra language. Typically, a
	ModuleDefinition uses opcodes combined with flow control
	statements, relational, logical and arithmetic operators
	etc. to define the desired operation of the Module. It may
	also contain a definition of a user interface for the Module,
	but this is completely independent of the definition of the
	Module's operation.

>Thanks! ;)  We could also try hard to reach interoperability between
>aRts and Quasimodo (that could be an even more valuable goal for the
>new year than throwing out midi of the respective core's ;), 

good goal, but this might be easier said than done !

--p

From - Fri Dec  3 11:09:01 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA32001
	for <slinkp@ulster.net>; Fri, 3 Dec 1999 11:00:59 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA06566 for linux-audio-dev-list; Fri, 3 Dec 1999 10:31:28 -0500
Received: from sculpcave (cvx-2-244.dyn.nic.fi [62.236.99.244]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA06559 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 3 Dec 1999 10:31:10 -0500
Received: from localhost (localhost [127.0.0.1])
	by sculpcave (Postfix) with ESMTP
	id 77F7A34D7A; Fri,  3 Dec 1999 16:10:12 +0200 (EET)
Date: Fri, 3 Dec 1999 16:10:12 +0200 (EET)
From: Kai Vehmanen <kaiv@wakkanet.fi>
X-Sender: root@sculpcave.localdomain
To: Paul Kellett <paul.kellett@maxim.abel.co.uk>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] acid, linux 
In-Reply-To: <199912021840.NAA00499@ginette.musique.umontreal.ca>
Message-ID: <Pine.LNX.4.10.9912031605030.950-100000@sculpcave.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 94027544a8cdb63a7c454c18c64b5eae

On Thu, 2 Dec 1999, Paul Kellett wrote:

>> someone should implement a logarithmic/exponential clipping function
>> that asymptotically approaches ((2^bits_per_sample)-1) once the sample
> You may as well use a _real_ limiter - no distortion until you start driving
> it really hard. Simple example - limits mono floating-point data to +/-1:

Well, I  prefer to use something that's even more real: an analog
limiter/compressor. ;)

>  rec=(sig>0.f)? sig : -sig;     //rectify signal
>  env=(rec>env)? rec : env*rel;  //slow release envelope
>  if(env>1.f) sig/=env;          //limit

... but this wouldn't hurst Simple, but works. I try to 
avoid table-lookups (--> floating-point values).

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav

From - Fri Dec  3 10:39:27 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA21789
	for <slinkp@ulster.net>; Fri, 3 Dec 1999 09:56:38 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA06462 for linux-audio-dev-list; Fri, 3 Dec 1999 09:33:28 -0500
Received: from p-biset.issy.cnet.fr (p-biset.issy.cnet.fr [139.100.0.33]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id JAA06459 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 3 Dec 1999 09:33:19 -0500
Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0)
	id <XCDLVPZJ>; Fri, 3 Dec 1999 15:28:03 +0100
Message-ID: <F09BA6AD2FB2D211BFAC00805F312C89B5879F@p-heron.issy.cnet.fr>
From: MOULET Xavier CNET/DMR/ISS <xavier.moulet@cnet.francetelecom.fr>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: RE: [linux-audio-dev] API
Date: Fri, 3 Dec 1999 15:28:01 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2cc746946e6b9151a46759b17710252a

Hi all,

sorry if I missed something, but what is the state of the mucows API ?
I haven't read anything about it since a moment here , and since things were
going well and then dropped suddendly, I suspect I've missing something
don't I ?

Is there a draft, a paper, an URL to begin understand the big pattern ?

Thanks,  

xavier

From - Fri Dec  3 10:58:57 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA31385
	for <slinkp@ulster.net>; Fri, 3 Dec 1999 10:57:42 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA06563 for linux-audio-dev-list; Fri, 3 Dec 1999 10:31:25 -0500
Received: from sculpcave (cvx-2-244.dyn.nic.fi [62.236.99.244]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA06560 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 3 Dec 1999 10:31:10 -0500
Received: from localhost (localhost [127.0.0.1])
	by sculpcave (Postfix) with ESMTP
	id CA39234DB9; Fri,  3 Dec 1999 16:59:20 +0200 (EET)
Date: Fri, 3 Dec 1999 16:59:20 +0200 (EET)
From: Kai Vehmanen <kaiv@wakkanet.fi>
X-Sender: root@sculpcave.localdomain
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] acid, linux
In-Reply-To: <19991202213206.A21589@div8.net>
Message-ID: <Pine.LNX.4.10.9912031629430.950-100000@sculpcave.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 0a6dbc3dddea9c71ea1e3c21568fb26a

On Thu, 2 Dec 1999, Billy Biggs wrote:

Hmm, I visited Tektracker's web site and I must admit it looks quite
nice. It would be great if we had a software sampler for Linux. 
Even with just basic functionality it would open up possibilities
(Tektracker, Softwerk, Brahms, etc used for controlling it via MIDI). 
Add ALSA's new MIDI-architecture to this, and you got quite nice 
set of tools for making music.

>> This is more difficult. My advice is to use an external wave-editor
>> (that's what I do). I'll release a simple wave editor (ecawave) 
>   What wave editor do you currently use for Linux?  I haven't found one that
> doesn't try to load the whole wave into memory.  This doesn't work very well
> on multiple 80-meg soundfiles.

snd is quite good.

>> [...] However, fine-tuning object layout, writing widgets, making
>> connections, has nothing to do with design. It's plain, boring work.
>   It's this sort of attitude that's really hurting free software, in my
> opinion.  Writing effective GUIs and intuitive GUIs is definitely a design
> challenge.  But, I do see your point, and realize that many people find it very
> boring.
[...]
>   Personally, I find it a worthy and important challenge.

It's not exactly clear to me, what you mean by "this sort of 
attitude". We are different and like different things. To me writing
UI-code is boring. If I need to write a good GUI, I have to write 
more UI-code. I still do it and I try to find ways to make it easier 
(and more fun) for me. But this is just me. If you look at my 
web pages, you might see a connection between them and my opinions on
GUI-coding. But, but, I didn't mean to say that GUIs are not 
needed or that *designing* them is easy.

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav

From - Fri Dec  3 10:39:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA26824
	for <slinkp@ulster.net>; Fri, 3 Dec 1999 10:29:13 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA06523 for linux-audio-dev-list; Fri, 3 Dec 1999 10:05:54 -0500
Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA06520 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 3 Dec 1999 10:05:48 -0500
Received: from d1o43.telia.com (d1o43.telia.com [194.22.195.241])
	by mailf.telia.com (8.9.3/8.9.3) with ESMTP id QAA15730;
	Fri, 3 Dec 1999 16:00:04 +0100 (CET)
Received: from norran.net (roger@t3o43p41.telia.com [194.22.195.161])
	by d1o43.telia.com (8.8.8/8.8.8) with ESMTP id PAA19150;
	Fri, 3 Dec 1999 15:59:58 +0100 (CET)
Message-ID: <3847E39E.E0244F4D@norran.net>
Date: Fri, 03 Dec 1999 16:37:02 +0100
From: Roger Larsson <roger.larsson@norran.net>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Stefan Westerfeld <stefan@space.twc.de>
CC: "'linux-audio-dev@ginette.musique.umontreal.ca'" 
 <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] [SRC] trial API (was: acid, linux)
References: <F09BA6AD2FB2D211BFAC00805F312C89B5878F@p-heron.issy.cnet.fr> <19991202021830.45633@space.twc.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: d4ad2f07588af7495467b1d129954cc0

Hi all,

First I like to notify you all about my 'trial API'
more can be read at 
 http://www.norran.net/nra02596/

It is not intended to become the one and only audio API.
I won't even try... See this more as a proof of concept.


Stefan Westerfeld wrote:
> 
>    Hi!
> 
> On Wed, Dec 01, 1999 at 05:56:56PM +0100, MOULET Xavier CNET/DMR/ISS wrote:
> > [...]
> 
> I can tell you what aRts is doing right now.
> 
> The idea I have is moving away from CORBA towards a lighter consistent
> object model which spreads throughout aRts. The thing will be called
> MCOP, which expands to multimedia communication protocol. But keep in
> mind that it cares about communcation and object model (the things that
> were handled by CORBA before).  One will write things like
> 
> interface Synth_ADD {
>   in audio stream signal1, signal2;
>   out audio stream result;
> };
> 
> in an idl file, and it will generate C++ skeleton classes, which you
> only need to implement. For Synth_ADD, this could look somthing along
> the lines:
> 
> void SynthAdd_impl::calculateBlock(unsigned long cycles)
> {
>     float *end = result + cycles;
> 
>         while(result != end) *result++ = *signal1++ + *signal2++;
> }
>

How to handle plugin with non constant data rate?
Then you will need one cycle counter per signal (including result)
I have tried to design for the most general case without closing
optimization possibilities. I could write a wrapper for your plugins,
can you write one for mine?

BTW I think this would be faster (testing against zero v. testing
against end
that has to bee in a register anyway):

 void SynthAdd_impl::calculateBlock(unsigned long cycles)
 {
    while(cycles--) *result++ = *signal1++ + *signal2++
 }

> that's about all you need to write. By the way, you could also have
> something like
> 
> interface BinaryOperation {
>   in audio stream signal1, signal2;
>   out audio stream result;
> };
> 
> interface Synth_ADD : BinaryOperation {
>   //
> };
>

But what if I have additional requirements like only handling 2''n
buffer sizes?
Varying data rates? 

You could add such description in the IDL.
And select plugintype depending on it - not too bad.

> which means you get the wonders of polymorphism and inheritance in your
> plugin system.
> 
> [ - - - ]
> 
> Perhaps other people who are still considering whether they want to do
> something similar could also join in. Basically, writing a middleware
> like MCOP is a lot of work. It is more or less as complete as CORBA (at
> least the relevant parts I used) in it's current development stadium,
> though not everything works fine yet, but it supports
>

But won't that mean that there will be several not quite CORBA
implementations
in KDE environment in the future mostly for speed reasons?

In OS/2, IBM handled that with their SOM implementation. When used it
could
link objects to the same process space, or shared in different
processors,
or via DSOM (CORBA) should't it be possible to use one ORB that is
externaly
looking like CORBA, but uses the most effective method when local.
 
> [ - - - ]
>
> KDE2 will use aRts as multimedia framework, which also means the sound
> server that will be running for the desktop will be implemented on top
> of that. It will also not necessarily remain an audio-only thing, video
> for instance would also be great - but that has some time.
> 
> The engine is partially ported from CORBA, but it currently can't do more
> than a beep (but at least that: fully modular) - also the plugins aren't
> ported, and some infrastructure is still completely missing (Qt GUI stuff).
> 
> So the dependancies aRts has are reduced to: C++ with STL (no Qt, no Mico,
> no KDE, no X11, if you really want not even Unix are required).
>

Nice!
 
> The code is available from the KDE CVS (kdemultimedia/arts), which you also
> can get anonymously if you like via CVSup. It is still in its experimental
> phase, but I'll port over all aRts infrastructure to MCOP in the next time,
> though that may take a while.
>

I will take a look.
 
/RogerL

From - Fri Dec  3 11:28:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA03172
	for <slinkp@ulster.net>; Fri, 3 Dec 1999 11:22:57 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA06622 for linux-audio-dev-list; Fri, 3 Dec 1999 10:56:35 -0500
Received: from pat.bath.ac.uk (pat.bath.ac.uk [138.38.32.2]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id KAA06619 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 3 Dec 1999 10:56:32 -0500
Received: (qmail 11692 invoked from network); 3 Dec 1999 15:50:57 -0000
Received: from mary.bath.ac.uk (HELO bath.ac.uk) (mmdf@138.38.32.14)
  by pat.bath.ac.uk with SMTP; 3 Dec 1999 15:50:57 -0000
Received: from kelvin.bath.ac.uk by mary.bath.ac.uk id aa25517;
          3 Dec 99 15:50 GMT
Message-ID: <3847E6F9.966CAA08@bath.ac.uk>
Date: Fri, 03 Dec 1999 15:51:21 +0000
From: Paul Leonard <P.J.Leonard@bath.ac.uk>
Organization: Applied Electromagnetic Research Centre
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "linux-audio-dev@ginette.musique.umontreal.ca" <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Advice on audio application ?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: cd55b3557f7069c0e945e48e7fc76b60

Hello Linux Audio,

  I am hoping to put together a simple application that will be used
for teaching. The application is required to

  - to play wav files
  - apply various filters to the playing file (in real time).
  - display the spectral content of the raw/filtered data (real time).

 For example it could be used to apply a bandpass filter to a spoken
voice to demonstrate the effect on the perception of sound (telecoms
example).

 Long term I would like to develop the application for teaching other
asspects of sound analysis / synthesis etc.

 So I am seeking advice on what components (filters etc) are available
and what existing
frameworks I could build on.


 cheers Paul.

From - Sat Dec  4 17:51:48 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA01182
	for <slinkp@ulster.net>; Fri, 3 Dec 1999 14:44:09 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA06912 for linux-audio-dev-list; Fri, 3 Dec 1999 14:16:36 -0500
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA06909 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 3 Dec 1999 14:16:31 -0500
Received: from smp.localnet.it (IDENT:root@[194.242.217.4])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id UAA30630;
	Fri, 3 Dec 1999 20:10:39 +0100
Received: from smp.localnet.it (IDENT:benno@localhost [127.0.0.1])
	by smp.localnet.it (8.9.3/8.9.3) with SMTP id TAA00657;
	Fri, 3 Dec 1999 19:01:58 +0100
From: Benno Senoner <sbenno@gardena.net>
To: "J Digital" <joshdigital@hotmail.com>, pbd@Op.Net,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] wine, cubase etc.
Date: Fri, 3 Dec 1999 18:54:21 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <19991201144615.77189.qmail@hotmail.com>
In-Reply-To: <19991201144615.77189.qmail@hotmail.com>
MIME-Version: 1.0
Message-Id: <99120319015800.00633@smp.localnet.it>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 76aee6f96b8f00b5db1fabdc60deffcf

On Wed, 01 Dec 1999, J Digital wrote:
> I used wine quite some years ago, and didnt have much luck getting anything 
> beyond simple win 3.11 apps to run. but im seriously looking at getting 
> vmware up and running, as i think it will really run nicely on my dual 
> processor machine. check out details on www.vmware.com
> 
> josh
> 
>

I'm sorry to disappoint you,
but vmware is not able to deliver accurate timing, since it runs the whole
virtual machine as an user process.
I tested N.I. Reaktor on vmware on my PII400 + 256MB while my box
was  todally *idle* on the linux side.

Very choppy sound even with very large buffersizes.
winamp behaves in similar fashion.
I would not run a MIDI sequencer on a virtual machine.

On the other hand wine seems much more promising, since
there are no virtual machine emulation techniques, but only API
call translations which run on the native linux box.
But Cubase, Logic etc are so complex beasts, and often
use dirty tricks (irq reprogrramming etc.)to achieve  better timing
stability/latency that I have little hopes to get these beasts
running on wine someday.

One advantage of unix is that it forbids to userspace apps
to perform dirty tricks, and that unix apps are almost hackfree
(irq stuff etc) by default.

Benno.

From - Sat Dec  4 17:51:46 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA26725
	for <slinkp@ulster.net>; Fri, 3 Dec 1999 13:57:29 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA06838 for linux-audio-dev-list; Fri, 3 Dec 1999 13:28:43 -0500
Received: from gehenna0.rutgers.edu (gehenna0.rutgers.edu [165.230.116.155]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA06835 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 3 Dec 1999 13:28:36 -0500
Received: (qmail 14635 invoked by alias); 3 Dec 1999 18:16:20 -0000
Received: (qmail 14628 invoked from network); 3 Dec 1999 18:16:19 -0000
Received: from envelopegirl.rutgers.edu (HELO acm.org) (128.6.134.21)
  by gehenna0.rutgers.edu with SMTP; 3 Dec 1999 18:16:19 -0000
Message-ID: <38480916.6F0D2951@acm.org>
Date: Fri, 03 Dec 1999 13:16:54 -0500
From: jfm3 <jfm3@acm.org>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] midi monitor
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 826b666dd789917173a456b9d76ded5c

Has anybody written a CLI MIDI monitor for Linux?  I'd imagine this is
something everyone hacks together in a c.c file and then forgets about,
and I'm not in the mood to reinvent the wheel.  Also, I didn't see
anything on Freshmeat.  Thanks!

(jfm3)


From - Sat Dec  4 17:51:50 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA05017
	for <slinkp@ulster.net>; Fri, 3 Dec 1999 15:11:17 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA06964 for linux-audio-dev-list; Fri, 3 Dec 1999 14:46:45 -0500
Received: from heroine.tampa.fl.us (alpha-iota97.resnet.usf.edu [131.247.220.97]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id OAA06961 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 3 Dec 1999 14:46:43 -0500
Received: (qmail 2939 invoked from network); 3 Dec 1999 19:36:48 -0000
Received: from unknown (HELO earthling.net) (root@127.0.0.1)
  by 127.0.0.1 with SMTP; 3 Dec 1999 19:36:48 -0000
Message-ID: <38481BD0.BC378700@earthling.net>
Date: Fri, 03 Dec 1999 14:36:48 -0500
From: Adam Williams <broadcast@earthling.net>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] mp3 decoder library
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 9c76da37a716149ccfafbe811a5621c1

What is the mp3 decoding library of choice that supports the following
functions:

open
close
high speed random seek
read to array of int16 or floats
mp2 compatibility

I've looked at various methods of accessing mpg123's decoding engine: 

running mpg123 over a pipe but every seek invokes a sequential search
through the entire file.

xmms input plugin: the mpg123 seeking was somehow fixed but with no
documentation.

osaflp...: runs mpg123 over a pipe.

using the libmpg object included in mpg123: doesn't support mp2/no
documentation

skysound: no seeking.

Any way of seeking mpg123 without the sequential search?
-- 
                               Heroine Virtual
                        freeyellow.com/members4/heroine
                      Render the impossible into reality

From - Sat Dec  4 17:51:51 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA23766
	for <slinkp@ulster.net>; Fri, 3 Dec 1999 17:06:42 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA07163 for linux-audio-dev-list; Fri, 3 Dec 1999 16:44:08 -0500
Received: from renoir.op.net (renoir.op.net [207.29.195.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA07160 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 3 Dec 1999 16:44:05 -0500
Received: from someip.ppp.op.net (d-bm3-02.ppp.op.net [209.152.194.66]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id QAA15876; Fri, 3 Dec 1999 16:37:07 -0500 (EST)
Message-Id: <199912032137.QAA15876@renoir.op.net>
To: jfm3 <jfm3@acm.org>
cc: linux-audio-dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] midi monitor 
In-reply-to: Your message of "Fri, 03 Dec 1999 13:16:54 EST."
             <38480916.6F0D2951@acm.org> 
Date: Fri, 03 Dec 1999 16:38:17 -0500
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: f0cabdb5c7b03ff8b4b53d6797d52ebc

In message <38480916.6F0D2951@acm.org>you write:
>Has anybody written a CLI MIDI monitor for Linux?  I'd imagine this is
>something everyone hacks together in a c.c file and then forgets about,
>and I'm not in the mood to reinvent the wheel.  Also, I didn't see
>anything on Freshmeat.  Thanks!

by CLI do you mean "command line interpreter" ? if so, then yes, i
have one based on libmidi++ ... i'll send it to you if you want. its
very simple, because libmidi++ contains a simple way to get the input
and/or output parser(s) to do the tracing for you and send it to any
C++ ostream (cout, wherever).
		
if you want something else, quasimodo has a GTK widget that does this
(gtk-quasimodo/midi_interface.cc), but that just uses the same
functionality in libmidi++.

--p

From - Sat Dec  4 17:51:54 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA11641
	for <slinkp@ulster.net>; Fri, 3 Dec 1999 19:29:06 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA07399 for linux-audio-dev-list; Fri, 3 Dec 1999 19:04:53 -0500
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA07396 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 3 Dec 1999 19:04:50 -0500
Received: from localhost.localdomain (d212-151-84-134.swipnet.se [212.151.84.134]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id AAA23061; 
          Sat, 4 Dec 1999 00:58:20 +0100 (MET)
From: David Olofson <audiality@swipnet.se>
To: MOULET Xavier CNET/DMR/ISS <xavier.moulet@cnet.francetelecom.fr>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: RE: [linux-audio-dev] API
Date: Sat, 4 Dec 1999 00:59:47 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <F09BA6AD2FB2D211BFAC00805F312C89B5879F@p-heron.issy.cnet.fr>
In-Reply-To: <F09BA6AD2FB2D211BFAC00805F312C89B5879F@p-heron.issy.cnet.fr>
MIME-Version: 1.0
Message-Id: <99120401075002.00478@localhost.localdomain>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA11641
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: fbbea55c26ac5851696056f91071132f

On Fri, 03 Dec 1999, MOULET Xavier CNET/DMR/ISS wrote:
> Hi all,
> 
> sorry if I missed something, but what is the state of the mucows API ?
> I haven't read anything about it since a moment here , and since things were
> going well and then dropped suddendly, I suspect I've missing something
> don't I ?
> 
> Is there a draft, a paper, an URL to begin understand the big pattern ?

Soon... Should have been up last weekend, but problems at work,
getting involved in a dance project and other things have delayed it.
:-( I might get something up this weekend, but don't count on it...

I'll hack the downloads page and put the current files there ASAP.
However, the MuCoS API part is more drafts than source code - the
most "interesting" part is the quick'n'dirty softsynth that I'm about
to port to MuCoS while hacking my prototype version of the API
together.


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Dec  4 17:51:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA12413
	for <slinkp@ulster.net>; Fri, 3 Dec 1999 19:35:38 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA07437 for linux-audio-dev-list; Fri, 3 Dec 1999 19:17:19 -0500
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA07431 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 3 Dec 1999 19:17:16 -0500
Received: from localhost.localdomain (d212-151-84-134.swipnet.se [212.151.84.134]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA04206; 
          Sat, 4 Dec 1999 01:10:54 +0100 (MET)
From: David Olofson <audiality@swipnet.se>
To: Kai Vehmanen <kaiv@wakkanet.fi>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] acid, linux
Date: Sat, 4 Dec 1999 01:10:31 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <Pine.LNX.4.10.9912031629430.950-100000@sculpcave.localdomain>
In-Reply-To: <Pine.LNX.4.10.9912031629430.950-100000@sculpcave.localdomain>
MIME-Version: 1.0
Message-Id: <99120401202503.00478@localhost.localdomain>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA12413
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b74554c39d29205cc9e9ee1efcaa0d42

On Fri, 03 Dec 1999, Kai Vehmanen wrote:
> On Thu, 2 Dec 1999, Billy Biggs wrote:
> 
> Hmm, I visited Tektracker's web site and I must admit it looks quite
> nice. It would be great if we had a software sampler for Linux. 

That's one of the first things I want to implement - problem is; when
do I get the time for that...? Anyway, I need it, as I'm not going to
pay $$$$ for a limited, proprietary, dedicated box that needs to be
expanded for another $$$$ before it's actually usable. And, I've
always wanted to code one. :-)

> >   Personally, I find it a worthy and important challenge.
> 
> It's not exactly clear to me, what you mean by "this sort of 
> attitude". We are different and like different things. To me writing
> UI-code is boring. If I need to write a good GUI, I have to write 
> more UI-code. I still do it and I try to find ways to make it easier 
> (and more fun) for me. But this is just me. If you look at my 
> web pages, you might see a connection between them and my opinions on
> GUI-coding. But, but, I didn't mean to say that GUIs are not 
> needed or that *designing* them is easy.

Well, I happen to like design, UI coding, low level coding, UI
design, audio coding, real time systems, writing articles, web
design, writing songs and some other things as well. :-)

No wonder I'm having trouble concentrating on one or two projects.
*heh...*


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Sat Dec  4 17:51:58 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA13304
	for <slinkp@ulster.net>; Fri, 3 Dec 1999 19:41:52 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA07451 for linux-audio-dev-list; Fri, 3 Dec 1999 19:23:49 -0500
Received: from mb07.swip.net (mb07.swip.net [193.12.122.211]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA07448 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 3 Dec 1999 19:23:46 -0500
Received: from localhost.localdomain (d212-151-84-134.swipnet.se [212.151.84.134]) 
          by mb07.swip.net (8.8.8/8.8.8) with SMTP 
          id BAA06732; 
          Sat, 4 Dec 1999 01:17:21 +0100 (MET)
From: David Olofson <audiality@swipnet.se>
To: Benno Senoner <sbenno@gardena.net>, "J Digital" <joshdigital@hotmail.com>,
        pbd@Op.Net, linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] wine, cubase etc.
Date: Sat, 4 Dec 1999 01:25:51 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <19991201144615.77189.qmail@hotmail.com> <99120319015800.00633@smp.localnet.it>
In-Reply-To: <99120319015800.00633@smp.localnet.it>
MIME-Version: 1.0
Message-Id: <99120401265104.00478@localhost.localdomain>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id TAA13304
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 24994bfbc3fad4e055f68385f04f5c97

On Fri, 03 Dec 1999, Benno Senoner wrote:
> One advantage of unix is that it forbids to userspace apps
> to perform dirty tricks, and that unix apps are almost hackfree
> (irq stuff etc) by default.

And who needs application level performance hacks anyway? ;-D


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Mon Dec  6 01:37:02 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA16119
	for <slinkp@ulster.net>; Sat, 4 Dec 1999 21:36:04 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA11832 for linux-audio-dev-list; Sat, 4 Dec 1999 21:13:37 -0500
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id VAA11829 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 4 Dec 1999 21:13:34 -0500
From: est@hyperreal.org
Received: (qmail 16894 invoked by uid 162); 5 Dec 1999 02:07:53 -0000
Message-ID: <19991205020753.16893.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] mp3 decoder library
In-Reply-To: <38481BD0.BC378700@earthling.net> from Adam Williams at "Dec 3,
 1999 02:36:48 pm"
To: Adam Williams <broadcast@earthling.net>
Date: Sat, 4 Dec 1999 18:07:53 -0800 (PST)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: faba8891bb157a9520189805e9532cbc

Adam Williams discourseth:
> 
> Any way of seeking mpg123 without the sequential search?

I believe you have to create a table-of-contents before-hand.  Each
mp3 frame can have an optional byte of padding, so a simple
multiplicative seek doesn't work.  This is even more of a concern when
using variable-bitrate files. :)

I'm implementing this plus reentrancy (have heard it in action :) but
make no promises re when it will be available.

E

From - Mon Dec  6 01:37:04 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA06665
	for <slinkp@ulster.net>; Sun, 5 Dec 1999 10:24:45 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA16453 for linux-audio-dev-list; Sun, 5 Dec 1999 09:54:59 -0500
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA16450 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 5 Dec 1999 09:54:54 -0500
Received: from linuxhost.localdomain (ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id PAA29911;
	Sun, 5 Dec 1999 15:48:43 +0100
Received: from linuxhost.localdomain (localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id QAA01005;
	Sun, 5 Dec 1999 16:48:19 +0100
From: Benno Senoner <sbenno@gardena.net>
To: est@hyperreal.org, Adam Williams <broadcast@earthling.net>
Subject: Re: [linux-audio-dev] mp3 decoder library
Date: Sun, 5 Dec 1999 16:40:39 +0100
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <19991205020753.16893.qmail@hyperreal.org>
MIME-Version: 1.0
Message-Id: <99120516481901.00738@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: bc76203583eb59d7928358327121b598

On Sun, 05 Dec 1999, est@hyperreal.org wrote:
> Adam Williams discourseth:
> > 
> > Any way of seeking mpg123 without the sequential search?
> 
> I believe you have to create a table-of-contents before-hand.  Each
> mp3 frame can have an optional byte of padding, so a simple
> multiplicative seek doesn't work.  This is even more of a concern when
> using variable-bitrate files. :)
> 
> I'm implementing this plus reentrancy (have heard it in action :) but
> make no promises re when it will be available.
> 
> E

I tried to add reentrancy to mpg123 sometime ago (quick hack of a couple of
hours), but failed because I forgot to duplicate the windowing filter,
that means you were able to open multiple streams , but when you played
more than one stream simultaneously you heard a loud noise, because the
windowing filter coefficients were screwed up by the other streams.
:-)

Eric, please drop us a note when you got the re-entrancy working.
I'm interested too in a fast and reentrant mp2/mp3 decoding lib.

FYI: Xaudio is a nice fast (similar speed as mpg123) and re-entrant MPEG layer
1,2,3 decoding lib,  ( http://www.xaudio.com ) , of free apps there is no
license to pay, for commercial ones, I think the license is $2 - $5.
Not that you get binary-only libs, no opensource, but the API works very well,
and has been ported to various platforms, windoze included. :-)

Benno.

From - Tue Dec  7 01:24:08 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id FAA17236
	for <slinkp@ulster.net>; Mon, 6 Dec 1999 05:38:32 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA21746 for linux-audio-dev-list; Mon, 6 Dec 1999 05:11:36 -0500
Received: from p-voyageur.issy.cnet.fr (p-voyageur.issy.cnet.fr [139.100.0.39]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id FAA21743 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 6 Dec 1999 05:11:33 -0500
Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2448.0)
	id <XRK18VM1>; Mon, 6 Dec 1999 09:29:52 +0100
Message-ID: <F09BA6AD2FB2D211BFAC00805F312C89B587A6@p-heron.issy.cnet.fr>
From: MOULET Xavier CNET/DMR/ISS <xavier.moulet@cnet.francetelecom.fr>
To: "'David Olofson'" <audiality@swipnet.se>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: RE: [linux-audio-dev] API
Date: Mon, 6 Dec 1999 09:29:51 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id FAA17236
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 661f91e645469e78489c4ca26f71d3e5

thanks,
is there already a web page or something ?
> 
> > Hi all,
> > 
> > sorry if I missed something, but what is the state of the 
> mucows API ?
> > I haven't read anything about it since a moment here , and 
> since things were
> > going well and then dropped suddendly, I suspect I've 
> missing something
> > don't I ?
> > 
> > Is there a draft, a paper, an URL to begin understand the 
> big pattern ?
> 
> Soon... Should have been up last weekend, but problems at work,
> getting involved in a dance project and other things have delayed it.
> :-( I might get something up this weekend, but don't count on it...
> 
> I'll hack the downloads page and put the current files there ASAP.
> However, the MuCoS API part is more drafts than source code - the
> most "interesting" part is the quick'n'dirty softsynth that I'm about
> to port to MuCoS while hacking my prototype version of the API
> together.
> 
> 
> //David
> 
> 
>  AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
> -  - 
> ------------------------------------------------------------- -  -
>     Rock Solid                                      David Olofson:
>     Low Latency    www.angelfire.com/or/audiality   Audio Hacker
>     Plug-Ins            audiality@swipnet.se        Linux Advocate
>     Open Source                                     Singer/Composer
> 

From - Mon Dec  6 04:30:58 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id EAA13506
	for <slinkp@ulster.net>; Mon, 6 Dec 1999 04:24:28 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id DAA21477 for linux-audio-dev-list; Mon, 6 Dec 1999 03:55:02 -0500
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA21474 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 6 Dec 1999 03:54:59 -0500
Received: from ulster.net (port68.ts2.ulster.net [208.242.164.68])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id DAA12263
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 6 Dec 1999 03:59:17 -0500
Message-ID: <384B7ADC.D30EC1B1@ulster.net>
Date: Mon, 06 Dec 1999 03:59:08 -0500
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] math question re. tempo changes
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: f86065676be68ba8070134d8b1211c45

Hi folks,

I have a math question about tempo.
I'm working on a python module for creating csound scores, and I
want a way to do what csound does with the "t" statement.
(Eventually I want to do more than that, but that would do for a
start.) This is a simple linearly-interpolated accelerando /
decelerando. Trouble is, I can't for the life of me figure out the
math.

What I want to do is basically this:
Let's say I have a section that starts at "beat" 0. The section
lasts until "beat" 10. During this section, the tempo accelerates
(linearly) from 60 to 120.

Given any beat value in this section, I should be able to calculate
the "real" (seconds) time value for this beat. 
Let's say it was a function called: 
beat_to_clock(beat_value, start_tempo, section_length, end_tempo)

How can I do that?

I tried looking at cscsort.c (in the csound sources) and the files
it includes, but I can't read C nearly well enough to have any idea
what's going on there.

I played around with some "t" statements in csound scores, just to
see what I could observe about the results. All I could tell is that
the ratio between beat-time and clock-time changes linearly during
the section. I have no idea what formula would produce the desired
result. Blind guessing has got me nowhere, so I thought I'd throw
myself on the mercy of this list.

thanks,

--PW

p.s. anyone who really wants to see my code, just ask. I'll be
posting it on my website before long. At the moment pysco does
everything that Pscore did (Pscore was my earlier attempt at doing
the same things in Perl), with a few new features.   I would not yet
characterize pysco as useful code, but I think it will soon be in a
state where I at least can compose with it. Tempo changes are the
big hurdle at the moment.
 
................    paul winkler    ..................
slinkP arts:   music, sound, illustration, design, etc.
A member of ARMS    ----->    http://www.reacharms.com
or http://www.mp3.com/arms or http://www.amp3.com/arms
personal page   ---->    http://www.ulster.net/~abigoo

From - Tue Dec  7 01:24:14 1999
Received: from ccrma.stanford.edu (ccrma.Stanford.EDU [36.49.0.84])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id JAA07080
	for <slinkp@ulster.net>; Mon, 6 Dec 1999 09:28:27 -0500
Received: from cmn14.stanford.edu (cmn14.stanford.edu [36.49.0.93])
	by ccrma.stanford.edu (8.9.3/8.9.3) with ESMTP id GAA00456
	for <slinkp@ulster.net>; Mon, 6 Dec 1999 06:18:11 -0800 (PST)
Received: (from bil@localhost)
	by cmn14.stanford.edu (8.9.3/8.9.3) id GAA28696
	for slinkp@ulster.net; Mon, 6 Dec 1999 06:18:10 -0800 (PST)
Message-Id: <199912061418.GAA28696@cmn14.stanford.edu>
Content-Type: text/plain
MIME-Version: 1.0 (NeXT Mail 3.3 v148.2.1)
In-Reply-To: <384B7ADC.D30EC1B1@ulster.net>
X-Nextstep-Mailer: Mail 3.3 [m68k] (Enhance 2.2p2)
Received: by NeXT.Mailer (1.148.2.1)
From: Bill Schottstaedt <bil@ccrma.stanford.edu>
Date: Mon,  6 Dec 1999 06:18:07 -0800
To: Paul Winkler <slinkp@ulster.net>
Subject: Re: [linux-audio-dev] math question re. tempo changes
References: <384B7ADC.D30EC1B1@ulster.net>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c462f6053b075bc37b175e4ee0bbb8c6

David Jaffe wrote an article on tempo maps that might help --
it's in CMJ somewhere (I don't have the reference at hand).
Basically, the idea was to integrate the tempo curve, then
all the beat timings are just array lookups.

From - Tue Dec  7 01:24:19 1999
Received: from naps.uwindsor.ca (dns.uwindsor.ca [137.207.232.1])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA02612
	for <slinkp@ulster.net>; Mon, 6 Dec 1999 15:30:27 -0500
Received: 	id PAA17977; Mon, 6 Dec 1999 15:20:06 -0500
Received: by gateway id PAA58860 for <slinkp@ulster.net>; Mon, 6 Dec 1999 15:17:16 -0500 (EST)
Date: Mon, 6 Dec 1999 15:18:33 -0500
From: Stewart M <stewars@server.uwindsor.ca>
To: Paul Winkler <slinkp@ulster.net>
Subject: Re: [linux-audio-dev] math question re. tempo changes
In-Reply-To: <384B7ADC.D30EC1B1@ulster.net>
Message-ID: <Pine.SGI.4.10.9912061510560.945888-100000@server.uwindsor.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: d11f6c057ca4e8faa8cfb30fbcf8a6da

On Mon, 6 Dec 1999, Paul Winkler wrote:

> Date: Mon, 06 Dec 1999 03:59:08 -0500
> From: Paul Winkler <slinkp@ulster.net>
> To: Linux Audio Dev. <linux-audio-dev@ginette.musique.umontreal.ca>
> Subject: [linux-audio-dev] math question re. tempo changes
> 
> Hi folks,
> 
> I have a math question about tempo.

> What I want to do is basically this:
> Let's say I have a section that starts at "beat" 0. The section
> lasts until "beat" 10. During this section, the tempo accelerates
> (linearly) from 60 to 120.

I think this can be done by figuring out a value that you would
multiply your tempo by for each lets say beat.  For the case that
you have described you are going from 60 to 120 which is a factor of
2 in 10 steps.  You can get a constant by using the formula like

2^(1/10)  or generally c=(tempo2/tempo1)^(1/divisions)

Then just do tempo*=c; for each beat.

I haven't actually tried this but I think it may work.

-Mark Stewart


From - Tue Dec  7 01:24:26 1999
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA09554
	for <slinkp@ulster.net>; Mon, 6 Dec 1999 19:05:47 -0500
Message-Id: <199912070005.TAA09554@nerf.ulster.net>
Subject: Re: [linux-audio-dev] math question re. tempo changes
To: Paul Winkler <slinkp@ulster.net>
Date: Mon, 6 Dec 1999 18:54:39 -0500 (EST)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
In-Reply-To: <384B7ADC.D30EC1B1@ulster.net> from "Paul Winkler" at Dec 6, 99 03:59:08 am
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 74072f40ff3465ca86a55873c04b3b87

Paul Winkler wrote:
> What I want to do is basically this:
> Let's say I have a section that starts at "beat" 0. The section
> lasts until "beat" 10. During this section, the tempo accelerates
> (linearly) from 60 to 120.
> 
> Given any beat value in this section, I should be able to calculate
> the "real" (seconds) time value for this beat. 
> Let's say it was a function called: 
> beat_to_clock(beat_value, start_tempo, section_length, end_tempo)
> 
> How can I do that?

ok, we're dealing with
        tempo: beats per second
        tempocurve: function from beats to tempo
        beat_to_clock: function from beats to seconds

the basic relationship is
        d(beat)/d(sec) = tempocurve(t)
so
        d(sec)/d(beat) = 1 / tempocurve(t)
so
        b_t_c(beat) = Integral(from 0 to beat)  1 / tempocurve(b)  d(b)

you've got a linear tempo curve
        tempocurve(b) = start_tempo + (b / section_length) * 
                                      (end_tempo - start_tempo)
so in this case
        b_t_c(beat) = Integral(from 0 to beat)
                      start_tempo +
                      ((end_tempo - start_tempo) / section_length) * b
                      d(b)
                    = 1/k ln(start_tempo + k*b)
where
        k = (end_tempo - start_tempo) / section_length

hmm, does that look sane?

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Tue Dec  7 01:24:27 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA13405
	for <slinkp@ulster.net>; Mon, 6 Dec 1999 19:29:53 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA22881 for linux-audio-dev-list; Mon, 6 Dec 1999 19:01:19 -0500
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id TAA22878 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 6 Dec 1999 19:01:13 -0500
Message-Id: <199912070001.TAA22878@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] math question re. tempo changes
To: Paul Winkler <slinkp@ulster.net>
Date: Mon, 6 Dec 1999 18:54:39 -0500 (EST)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
In-Reply-To: <384B7ADC.D30EC1B1@ulster.net> from "Paul Winkler" at Dec 6, 99 03:59:08 am
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 29d8e76023a035bdad8ce4f7d3fedd29

Paul Winkler wrote:
> What I want to do is basically this:
> Let's say I have a section that starts at "beat" 0. The section
> lasts until "beat" 10. During this section, the tempo accelerates
> (linearly) from 60 to 120.
> 
> Given any beat value in this section, I should be able to calculate
> the "real" (seconds) time value for this beat. 
> Let's say it was a function called: 
> beat_to_clock(beat_value, start_tempo, section_length, end_tempo)
> 
> How can I do that?

ok, we're dealing with
        tempo: beats per second
        tempocurve: function from beats to tempo
        beat_to_clock: function from beats to seconds

the basic relationship is
        d(beat)/d(sec) = tempocurve(t)
so
        d(sec)/d(beat) = 1 / tempocurve(t)
so
        b_t_c(beat) = Integral(from 0 to beat)  1 / tempocurve(b)  d(b)

you've got a linear tempo curve
        tempocurve(b) = start_tempo + (b / section_length) * 
                                      (end_tempo - start_tempo)
so in this case
        b_t_c(beat) = Integral(from 0 to beat)
                      start_tempo +
                      ((end_tempo - start_tempo) / section_length) * b
                      d(b)
                    = 1/k ln(start_tempo + k*b)
where
        k = (end_tempo - start_tempo) / section_length

hmm, does that look sane?

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Tue Dec  7 12:55:21 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id CAA06567
	for <slinkp@ulster.net>; Tue, 7 Dec 1999 02:59:38 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id CAA27361 for linux-audio-dev-list; Tue, 7 Dec 1999 02:36:47 -0500
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA27358 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 7 Dec 1999 02:36:45 -0500
Received: from ulster.net (port96.ts2.ulster.net [208.242.164.96])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id CAA05646;
	Tue, 7 Dec 1999 02:40:52 -0500
Message-ID: <384CBA01.2A59B44D@ulster.net>
Date: Tue, 07 Dec 1999 02:40:49 -0500
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: eli+@cs.cmu.edu
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] math question re. tempo changes
References: <199912070005.TAA09554@nerf.ulster.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4e3a2e89d820824fd1cda862b4bc3edd

Thanks for the reply, Eli.

If you can bear with my ignorance a bit, I hope I can make sense of
your message... I'm out of my depth here, but I'm trying!

Eli Brandt wrote:
> 
> Paul Winkler wrote:
> > What I want to do is basically this:
> > Let's say I have a section that starts at "beat" 0. The section
> > lasts until "beat" 10. During this section, the tempo accelerates
> > (linearly) from 60 to 120.
> >
> > Given any beat value in this section, I should be able to calculate
> > the "real" (seconds) time value for this beat.
> > Let's say it was a function called:
> > beat_to_clock(beat_value, start_tempo, section_length, end_tempo)
> >
> > How can I do that?
> 
> ok, we're dealing with
>         tempo: beats per second
>         tempocurve: function from beats to tempo
>         beat_to_clock: function from beats to seconds
> 
> the basic relationship is
>         d(beat)/d(sec) = tempocurve(t)

what is d?
what is t? I thought short for "tempo" but that would suggest tempo
is the argument, not return value, of tempocurve?

> so
>         d(sec)/d(beat) = 1 / tempocurve(t)

OK, that much I can handle. :)

> so
>         b_t_c(beat) = Integral(from 0 to beat)  1 / tempocurve(b)  d(b)

uh-oh.
 

This is what I was afraid of -- we've left the realm of the math
courses I took so long ago... I never got farther than trig (which I
barely remember) and some logic, no calculus. I don't know what an
integral is, nor how to compute it, nor where to find an explanation
of that which I can understand. any pointers would be appreciated.
Preferably online as libraries here are rather limited (no good
university I can get to easily), and I have no money for books these
days.

Also I looked for "integrals" in the python documentation and turned
up empty, except in several cases where they seem to mean "integer".
So much for hoping to solve the problem without understanding it!


> you've got a linear tempo curve
>         tempocurve(b) = start_tempo + (b / section_length) *
>                                       (end_tempo - start_tempo)
> so in this case
>         b_t_c(beat) = Integral(from 0 to beat)
>                       start_tempo +
>                       ((end_tempo - start_tempo) / section_length) * b
>                       d(b)
>                     = 1/k ln(start_tempo + k*b)

That last line looks tantalizingly simple. Too bad I'm lost again...
what's ln()?

> where
>         k = (end_tempo - start_tempo) / section_length
> 
> hmm, does that look sane?

Sure! {:)

-- 
................    paul winkler    ..................
slinkP arts:   music, sound, illustration, design, etc.
A member of ARMS    ----->    http://www.reacharms.com
or http://www.mp3.com/arms or http://www.amp3.com/arms
personal page   ---->    http://www.ulster.net/~abigoo

From - Tue Dec  7 12:55:27 1999
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA32627
	for <slinkp@ulster.net>; Tue, 7 Dec 1999 12:24:01 -0500
From: est@hyperreal.org
Received: (qmail 10461 invoked by uid 162); 7 Dec 1999 17:13:18 -0000
Message-ID: <19991207171318.10460.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] math question re. tempo changes
In-Reply-To: <384CBA01.2A59B44D@ulster.net> from Paul Winkler at "Dec 7, 1999
 02:40:49 am"
To: Paul Winkler <slinkp@ulster.net>
Date: Tue, 7 Dec 1999 09:13:18 -0800 (PST)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ccb652122e3afb9b598dd6a38128ef92

Paul Winkler discourseth:
> Eli Brandt wrote:
> > 
> > ok, we're dealing with
> >         tempo: beats per second
> >         tempocurve: function from beats to tempo
> >         beat_to_clock: function from beats to seconds
> > 
> > the basic relationship is
> >         d(beat)/d(sec) = tempocurve(t)
> > so
> >         d(sec)/d(beat) = 1 / tempocurve(t)
> > so
> >         b_t_c(beat) = Integral(from 0 to beat)  1 / tempocurve(b)  d(b)
> 
> uh-oh.
> 
> This is what I was afraid of -- we've left the realm of the math
> courses I took so long ago...

The basic concept is pretty easy.  Your changing tempo means that the
rate at which time accumulates per unit beat (which is what
d(sec)/d(beat) is in the language of calculus) is changing.  Integrals
are good for taking a changing rate of accumulation and turning it
into a function giving the total of the accumulated quantity (time
here) at any point.

> > you've got a linear tempo curve
> >         tempocurve(b) = start_tempo + (b / section_length) *
> >                                       (end_tempo - start_tempo)
> > so in this case
> >         b_t_c(beat) = Integral(from 0 to beat)
> >                       start_tempo +
> >                       ((end_tempo - start_tempo) / section_length) * b
> >                       d(b)
> >                     = 1/k ln(start_tempo + k*b)
> 
> That last line looks tantalizingly simple. Too bad I'm lost again...
> what's ln()?

That's the `natural logarithm'..math.log() in python.

> > where
> >         k = (end_tempo - start_tempo) / section_length
> > 
> > hmm, does that look sane?

The basic idea of integrals is easy..but doing them is (relatively) a
black art.  I haven't done this sort of thing in years..but what
better place to refresh than in public. :D

I get:

    b_t_c(beat)    
 =  Integral(from 0 to beat) start_tempo + k * b  d(b)
 =  start_tempo * beat + k * beat^2 / 2

Note that `beat' must be 0 at the start of the sequence when plugged
into this formula.  Try both and see which sounds better. :)

Eric

From - Tue Dec  7 13:05:20 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA06842
	for <slinkp@ulster.net>; Tue, 7 Dec 1999 13:01:55 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA28198 for linux-audio-dev-list; Tue, 7 Dec 1999 12:19:30 -0500
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id MAA28195 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 7 Dec 1999 12:19:26 -0500
From: est@hyperreal.org
Received: (qmail 10461 invoked by uid 162); 7 Dec 1999 17:13:18 -0000
Message-ID: <19991207171318.10460.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] math question re. tempo changes
In-Reply-To: <384CBA01.2A59B44D@ulster.net> from Paul Winkler at "Dec 7, 1999
 02:40:49 am"
To: Paul Winkler <slinkp@ulster.net>
Date: Tue, 7 Dec 1999 09:13:18 -0800 (PST)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 17d10b09fd16792accc63eeb1a08595f

Paul Winkler discourseth:
> Eli Brandt wrote:
> > 
> > ok, we're dealing with
> >         tempo: beats per second
> >         tempocurve: function from beats to tempo
> >         beat_to_clock: function from beats to seconds
> > 
> > the basic relationship is
> >         d(beat)/d(sec) = tempocurve(t)
> > so
> >         d(sec)/d(beat) = 1 / tempocurve(t)
> > so
> >         b_t_c(beat) = Integral(from 0 to beat)  1 / tempocurve(b)  d(b)
> 
> uh-oh.
> 
> This is what I was afraid of -- we've left the realm of the math
> courses I took so long ago...

The basic concept is pretty easy.  Your changing tempo means that the
rate at which time accumulates per unit beat (which is what
d(sec)/d(beat) is in the language of calculus) is changing.  Integrals
are good for taking a changing rate of accumulation and turning it
into a function giving the total of the accumulated quantity (time
here) at any point.

> > you've got a linear tempo curve
> >         tempocurve(b) = start_tempo + (b / section_length) *
> >                                       (end_tempo - start_tempo)
> > so in this case
> >         b_t_c(beat) = Integral(from 0 to beat)
> >                       start_tempo +
> >                       ((end_tempo - start_tempo) / section_length) * b
> >                       d(b)
> >                     = 1/k ln(start_tempo + k*b)
> 
> That last line looks tantalizingly simple. Too bad I'm lost again...
> what's ln()?

That's the `natural logarithm'..math.log() in python.

> > where
> >         k = (end_tempo - start_tempo) / section_length
> > 
> > hmm, does that look sane?

The basic idea of integrals is easy..but doing them is (relatively) a
black art.  I haven't done this sort of thing in years..but what
better place to refresh than in public. :D

I get:

    b_t_c(beat)    
 =  Integral(from 0 to beat) start_tempo + k * b  d(b)
 =  start_tempo * beat + k * beat^2 / 2

Note that `beat' must be 0 at the start of the sequence when plugged
into this formula.  Try both and see which sounds better. :)

Eric

From - Tue Dec  7 15:34:42 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA30506
	for <slinkp@ulster.net>; Tue, 7 Dec 1999 15:32:02 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA28446 for linux-audio-dev-list; Tue, 7 Dec 1999 14:31:56 -0500
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA28443 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 7 Dec 1999 14:31:52 -0500
Received: from ulster.net (port231.ts2.ulster.net [208.242.164.231])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id OAA21556;
	Tue, 7 Dec 1999 14:35:42 -0500
Message-ID: <384D6184.91BA0D0A@ulster.net>
Date: Tue, 07 Dec 1999 14:35:32 -0500
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: est@hyperreal.org
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] math question re. tempo changes
References: <19991207171318.10460.qmail@hyperreal.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 8d3c64bdaf2823a1ec8d6b3431284c9f

est@hyperreal.org wrote:
> The basic concept is pretty easy.  Your changing tempo means that the
> rate at which time accumulates per unit beat (which is what
> d(sec)/d(beat) is in the language of calculus) is changing.  Integrals
> are good for taking a changing rate of accumulation and turning it
> into a function giving the total of the accumulated quantity (time
> here) at any point.

OK.

> The basic idea of integrals is easy..but doing them is (relatively) a
> black art.  I haven't done this sort of thing in years..but what
> better place to refresh than in public. :D
> I get:
> 
>     b_t_c(beat)
>  =  Integral(from 0 to beat) start_tempo + k * b  d(b)
>  =  start_tempo * beat + k * beat^2 / 2
> 

Seems like you got it right! At least, your method produces
identical results to those obtained using a t statement in csound.
 
Here's my test code -- this will need to be modified somewhat to
make it more generally useful in my module:

#!/usr/bin/python

def b2c(beat, start_tempo=60, end_tempo=60, end_beat):
    #make sure we use float values even if args are ints
    (beat, end_beat) = (float(beat), float(end_beat))
    # convert tempo from bpm to bps
    start_tempo, end_tempo = 60.0/start_tempo, 60.0/end_tempo
    k = (end_tempo - start_tempo) / end_beat
    clocktime = ((start_tempo * beat) + (k * beat**2 / 2))
    return clocktime


## TEST
a = range(0, 11)
b = []
for i in a:
    b.append( b2c(i, 60, 120, 10))
    print a[i], "-->", b[i]

a = range(0, 6)
b = []
for i in a:
    b.append( b2c(i, 40, 30, 5))
    print a[i], "-->", b[i]

-- 
................    paul winkler    ..................
slinkP arts:   music, sound, illustration, design, etc.
A member of ARMS    ----->    http://www.reacharms.com
or http://www.mp3.com/arms or http://www.amp3.com/arms
personal page   ---->    http://www.ulster.net/~abigoo

From - Tue Dec  7 15:05:22 1999
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA25444
	for <slinkp@ulster.net>; Tue, 7 Dec 1999 15:00:39 -0500
From: est@hyperreal.org
Received: (qmail 4862 invoked by uid 162); 7 Dec 1999 19:49:35 -0000
Message-ID: <19991207194935.4860.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] math question re. tempo changes
In-Reply-To: <384D6184.91BA0D0A@ulster.net> from Paul Winkler at "Dec 7, 1999
 02:35:32 pm"
To: Paul Winkler <slinkp@ulster.net>
Date: Tue, 7 Dec 1999 11:49:35 -0800 (PST)
CC: wsannis@execpc.com
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 5ef21d94585c13b9f55b68adabf73fc2

Paul, a private aside:

You definitely need to talk to William Annis who is also using python
as a score language. :D

E

PS: ..and/or maybe William should be on linux-audio-dev.

Paul Winkler discourseth:
> est@hyperreal.org wrote:
> > The basic concept is pretty easy.  Your changing tempo means that the
> > rate at which time accumulates per unit beat (which is what
> > d(sec)/d(beat) is in the language of calculus) is changing.  Integrals
> > are good for taking a changing rate of accumulation and turning it
> > into a function giving the total of the accumulated quantity (time
> > here) at any point.
> 
> OK.
> 
> > The basic idea of integrals is easy..but doing them is (relatively) a
> > black art.  I haven't done this sort of thing in years..but what
> > better place to refresh than in public. :D
> > I get:
> > 
> >     b_t_c(beat)
> >  =  Integral(from 0 to beat) start_tempo + k * b  d(b)
> >  =  start_tempo * beat + k * beat^2 / 2
> > 
> 
> Seems like you got it right! At least, your method produces
> identical results to those obtained using a t statement in csound.
>  
> Here's my test code -- this will need to be modified somewhat to
> make it more generally useful in my module:
> 
> #!/usr/bin/python
> 
> def b2c(beat, start_tempo=60, end_tempo=60, end_beat):
>     #make sure we use float values even if args are ints
>     (beat, end_beat) = (float(beat), float(end_beat))
>     # convert tempo from bpm to bps
>     start_tempo, end_tempo = 60.0/start_tempo, 60.0/end_tempo
>     k = (end_tempo - start_tempo) / end_beat
>     clocktime = ((start_tempo * beat) + (k * beat**2 / 2))
>     return clocktime
> 
> 
> ## TEST
> a = range(0, 11)
> b = []
> for i in a:
>     b.append( b2c(i, 60, 120, 10))
>     print a[i], "-->", b[i]
> 
> a = range(0, 6)
> b = []
> for i in a:
>     b.append( b2c(i, 40, 30, 5))
>     print a[i], "-->", b[i]
> 
> -- 
> ................    paul winkler    ..................
> slinkP arts:   music, sound, illustration, design, etc.
> A member of ARMS    ----->    http://www.reacharms.com
> or http://www.mp3.com/arms or http://www.amp3.com/arms
> personal page   ---->    http://www.ulster.net/~abigoo
> 

From - Tue Dec  7 17:27:55 1999
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA15962
	for <slinkp@ulster.net>; Tue, 7 Dec 1999 17:21:10 -0500
Message-Id: <199912072221.RAA15962@nerf.ulster.net>
Subject: Re: [linux-audio-dev] math question re. tempo changes
To: est@hyperreal.org
Date: Tue, 7 Dec 1999 17:10:17 -0500 (EST)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
Cc: slinkp@ulster.net, linux-audio-dev@ginette.musique.umontreal.ca
In-Reply-To: <19991207171318.10460.qmail@hyperreal.org> from "est@hyperreal.org" at Dec 7, 99 09:13:18 am
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2a49be370b4f6ba627b4918d74f5cf0b

est@hyperreal.org wrote:
[a good explanation of what I was trying to do]

> I get:
> 
>     b_t_c(beat)    
>  =  Integral(from 0 to beat) start_tempo + k * b  d(b)
>  =  start_tempo * beat + k * beat^2 / 2

If Paul says this one is doing the right thing for him, great, and
there was surely something troubling about finding a natural log in
mine.  But I'm confused.

Say k is positive, so the tempo -- beats per second -- is increasing.
As we go along, each beat ought to map to less seconds.  But that
beats_to_secs() formula has later beats mapping to /more/ seconds;
k is bringing in a superlinear term.  This seems like a secs_to_beats().

(The difference we have is what we put in the 
        beats_to_secs = integral foo d(beat)
I figure tempocurve() is d(b)/d(s), so I took the reciprocal.)

> I haven't done this sort of thing in years..but what
> better place to refresh than in public. :D

Yeh, tell me about it.

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Tue Dec  7 22:49:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA21150
	for <slinkp@ulster.net>; Tue, 7 Dec 1999 17:51:00 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA28781 for linux-audio-dev-list; Tue, 7 Dec 1999 17:16:34 -0500
Received: from v.gp.cs.cmu.edu (V.GP.CS.CMU.EDU [128.2.191.166]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id RAA28777 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 7 Dec 1999 17:16:28 -0500
Message-Id: <199912072216.RAA28777@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] math question re. tempo changes
To: est@hyperreal.org
Date: Tue, 7 Dec 1999 17:10:17 -0500 (EST)
From: Eli Brandt <eli@v.gp.cs.cmu.edu>
Cc: slinkp@ulster.net, linux-audio-dev@ginette.musique.umontreal.ca
In-Reply-To: <19991207171318.10460.qmail@hyperreal.org> from "est@hyperreal.org" at Dec 7, 99 09:13:18 am
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
Reply-To: eli+@cs.cmu.edu
X-Mailer: ELM [version 2.4 PL25-40]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: db1f652aa56f10c7a6fc771e3cc98080

est@hyperreal.org wrote:
[a good explanation of what I was trying to do]

> I get:
> 
>     b_t_c(beat)    
>  =  Integral(from 0 to beat) start_tempo + k * b  d(b)
>  =  start_tempo * beat + k * beat^2 / 2

If Paul says this one is doing the right thing for him, great, and
there was surely something troubling about finding a natural log in
mine.  But I'm confused.

Say k is positive, so the tempo -- beats per second -- is increasing.
As we go along, each beat ought to map to less seconds.  But that
beats_to_secs() formula has later beats mapping to /more/ seconds;
k is bringing in a superlinear term.  This seems like a secs_to_beats().

(The difference we have is what we put in the 
        beats_to_secs = integral foo d(beat)
I figure tempocurve() is d(b)/d(s), so I took the reciprocal.)

> I haven't done this sort of thing in years..but what
> better place to refresh than in public. :D

Yeh, tell me about it.

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

From - Tue Dec  7 22:49:59 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA01254
	for <slinkp@ulster.net>; Tue, 7 Dec 1999 19:03:08 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA28892 for linux-audio-dev-list; Tue, 7 Dec 1999 18:27:56 -0500
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id SAA28889 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 7 Dec 1999 18:27:54 -0500
From: est@hyperreal.org
Received: (qmail 27040 invoked by uid 162); 7 Dec 1999 23:22:02 -0000
Message-ID: <19991207232202.27039.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] math question re. tempo changes
In-Reply-To: <199912072216.RAA28777@ginette.musique.umontreal.ca> from Eli Brandt
 at "Dec 7, 1999 05:10:17 pm"
To: eli+@cs.cmu.edu
Date: Tue, 7 Dec 1999 15:22:02 -0800 (PST)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1bea8f1bf5023ebf52849642383480d0

Eli Brandt discourseth:
> 
> If Paul says this one is doing the right thing for him, great, and
> there was surely something troubling about finding a natural log in
> mine.  But I'm confused.

No..you were right. :)

I think I correctly solved the integral you showed..but it didn't
match your commentary or end result.

Here's a rederivation complete with explicit u-substitution:

db/dt = start_tempo + (end_tempo - start_tempo) * b/section_length

k = (end_tempo - start_tempo)/section_length

db/dt = start_tempo + k * b

dt/db = 1/(start_tempo + k * b)

t(b) = integral 1/(start_tempo + k * b) db
     = integral 1/(k * u) du  (u = start_tempo + k * b, db = du/k)
     = ln(u)/k
     = ln(start_tempo + k * b)/k

E

From - Tue Dec  7 22:50:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA07393
	for <slinkp@ulster.net>; Tue, 7 Dec 1999 19:41:12 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA28963 for linux-audio-dev-list; Tue, 7 Dec 1999 19:12:01 -0500
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id TAA28960 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 7 Dec 1999 19:11:59 -0500
From: est@hyperreal.org
Received: (qmail 10352 invoked by uid 162); 8 Dec 1999 00:06:08 -0000
Message-ID: <19991208000608.10351.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] math question re. tempo changes
In-Reply-To: <19991207232202.27039.qmail@hyperreal.org> from "est@hyperreal.org"
 at "Dec 7, 1999 03:22:02 pm"
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Tue, 7 Dec 1999 16:06:08 -0800 (PST)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: bc7e8b03844bf1cdb69c618c75c2b498

Ack..I forgot the constant of integration which makes it:

  t(b) = ln(start_tempo + k * b)/k - ln(start_tempo)/k

E

est@hyperreal.org discourseth:
> 
> Here's a rederivation complete with explicit u-substitution:
> 
> db/dt = start_tempo + (end_tempo - start_tempo) * b/section_length
> 
> k = (end_tempo - start_tempo)/section_length
> 
> db/dt = start_tempo + k * b
> 
> dt/db = 1/(start_tempo + k * b)
> 
> t(b) = integral 1/(start_tempo + k * b) db
>      = integral 1/(k * u) du  (u = start_tempo + k * b, db = du/k)
>      = ln(u)/k
>      = ln(start_tempo + k * b)/k

From - Tue Dec  7 23:39:54 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA11207
	for <slinkp@ulster.net>; Tue, 7 Dec 1999 23:38:22 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA29264 for linux-audio-dev-list; Tue, 7 Dec 1999 23:06:11 -0500
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA29261 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 7 Dec 1999 23:06:09 -0500
Received: from ulster.net (port54.ts2.ulster.net [208.242.164.54])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id XAA07610;
	Tue, 7 Dec 1999 23:10:16 -0500
Message-ID: <384DDA27.15D86023@ulster.net>
Date: Tue, 07 Dec 1999 23:10:15 -0500
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: eli+@cs.cmu.edu
CC: est@hyperreal.org, linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] math question re. tempo changes
References: <199912072216.RAA28777@ginette.musique.umontreal.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 60655789c6f51a037b3a97ba94d8caf6

Eli Brandt wrote:
> If Paul says this one is doing the right thing for him, great, and
> there was surely something troubling about finding a natural log in
> mine.  But I'm confused.

Fortunately, I'm too ignorant to be confused!

................    paul winkler    ..................
slinkP arts:   music, sound, illustration, design, etc.
A member of ARMS    ----->    http://www.reacharms.com
or http://www.mp3.com/arms or http://www.amp3.com/arms
personal page   ---->    http://www.ulster.net/~abigoo

From - Thu Dec  9 21:56:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA17460
	for <slinkp@ulster.net>; Thu, 9 Dec 1999 21:25:19 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA07831 for linux-audio-dev-list; Thu, 9 Dec 1999 21:14:19 -0500
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA07828 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 9 Dec 1999 21:14:15 -0500
Received: from localhost.localdomain (d212-151-44-28.swipnet.se [212.151.44.28]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id DAA01332; 
          Fri, 10 Dec 1999 03:06:52 +0100 (MET)
From: David Olofson <audiality@swipnet.se>
To: MOULET Xavier CNET/DMR/ISS <xavier.moulet@cnet.francetelecom.fr>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: RE: [linux-audio-dev] The MuCoS Project Web Site (Was: API)
Date: Fri, 10 Dec 1999 03:07:17 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <F09BA6AD2FB2D211BFAC00805F312C89B587A6@p-heron.issy.cnet.fr>
In-Reply-To: <F09BA6AD2FB2D211BFAC00805F312C89B587A6@p-heron.issy.cnet.fr>
MIME-Version: 1.0
Message-Id: <99121003164600.01225@localhost.localdomain>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id VAA17460
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c1b70e6b93889385bfd4e989b031c3be

On Mon, 06 Dec 1999, MOULET Xavier CNET/DMR/ISS wrote:
> thanks,
> is there already a web page or something ?

Well, not when you asked, but NOW there is. (FINALLY! :-) Sorry about
the delay...

	http://www.linuxdj.com/mucos

Have a look, and in particular those mentioned in the Links and
Contact sections; please comment on the details! (Where did my links
to Paul's projects go, for example? Other stuff that should be on the
site?)

Next, I'll hack the Overview section, and start turning that
softsynth into a MuCoS engine + plugins...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Fri Dec 10 21:07:20 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA19861
	for <slinkp@ulster.net>; Fri, 10 Dec 1999 13:03:54 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA09147 for linux-audio-dev-list; Fri, 10 Dec 1999 12:41:53 -0500
Received: from rslx01.fht-esslingen.de (rslx01.fht-esslingen.de [134.108.51.101]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA09144 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 10 Dec 1999 12:41:47 -0500
Received: from firewall.dc.com (rsra100.fht-esslingen.de [134.108.128.100])
	by rslx01.fht-esslingen.de (8.9.3/8.9.3) with ESMTP id SAA30394
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 10 Dec 1999 18:35:41 +0100
Received: from 42.fht-esslingen.de (machtnix.dc.com [192.168.192.168])
	by firewall.dc.com (8.9.3/8.9.3) with ESMTP id SAA00437
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 10 Dec 1999 18:30:16 GMT
Message-ID: <3851391C.27E9858C@42.fht-esslingen.de>
Date: Fri, 10 Dec 1999 18:32:12 +0100
From: Alexander =?iso-8859-1?Q?K=F6nig?= <alex@rhlx01.fht-esslingen.de>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Linux Audio Dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] SCHED_FIFO machine stalls
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by rslx01.fht-esslingen.de id SAA30394
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id NAA19861
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: c0e46d4e8e6ca232202b3cb1a04b4e0b

Hi,

I'm currently doing some terminatorX hacking and ran in to some
problems:

I use two (p)threads: one for the gtk+-GUI and one for audio rendering.
As tX has to be near-realtime I have to use really small buffer sizes
(playback is done via write() to /dev/dsp). Now if both threads run with
the same priority operating the GUI causes a lot of audio-dropouts
(especially when using them beautiful gtk+-pixmap-themes ;) Which is why
I decided to use some scheduling-stuff. Now what I do is this:

After creating the audio-thread the GUI-thread task-priority is set to
20 via setpriority(). With pthread_attr_setschedpolicy() the
audio-thread is run with SCHED_FIFO-policy. Additionally I do a
setpriority() to level -20 although this possibly doesn't make much
difference I guess it won't hurt. 

The good news is: it actually works! I love this Kernel ;) The
GUI-thread does painting at 486-speed but it doens't hurt the
audio-thread anymore (Although I still get rare audio-dropouts (no
matter whether the GUI-thread is busy or not)). But: running as root (==
with the code described above enabled) tX sometimes causes system
stalls. At first I thought that the cause of this might be some
pthread_mutex-deadlocks() but I guess these should occur in normal
operation mode (not messing with the scheduler at all) too, shouldn't
they?

Well, anyway this problem is somewhat hard to debug so I could really
use some suggestions ;)

Oh, btw, I use a plain 2.2.13 currently.

Bye,
Alex
-- 
_______________________________________________________________________
                            Alexander Knig - alex@42.fht-esslingen.de
                                                  http://termX.cjb.net

[From the Homer Quotables:]
 
If it'll make you feel any better, I've learned that life is one
crushing defeat after another until you just wish Flanders was dead.

		-- Homer Simpson
		   Homer and Apu

From - Fri Dec 10 21:07:22 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA24692
	for <slinkp@ulster.net>; Fri, 10 Dec 1999 13:35:17 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA09201 for linux-audio-dev-list; Fri, 10 Dec 1999 13:10:57 -0500
Received: from server.things.nl ([195.240.38.236]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA09198 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 10 Dec 1999 13:10:54 -0500
Received: from mtg150.upf.es (mtg150.upf.es [193.145.44.150])
	by server.things.nl (8.8.7/8.8.7) with SMTP id TAA25478
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 10 Dec 1999 19:46:42 +0100
From: maarten de boer <maarten@things.nl>
Reply-To: maarten@things.nl
To: <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] SCHED_FIFO machine stalls
Date: Fri, 10 Dec 1999 19:14:27 +0100
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <99121019143808.10521@mtg150.upf.es>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 193f28edf95d76dfb5c0b13ae83f12a1


Hi

> I'm currently doing some terminatorX hacking and ran in to some
> problems:

Great program BTW.

> After creating the audio-thread the GUI-thread task-priority is set to
> 20 via setpriority(). With pthread_attr_setschedpolicy() the
> audio-thread is run with SCHED_FIFO-policy. Additionally I do a
> setpriority() to level -20 although this possibly doesn't make much
> difference I guess it won't hurt. 

Yeah, that seems redundant to me.
In my opinion it is not be necesairy at all to change the
priority of the GUI thread. The audio thread had SCHED_FIFO
priority and thus goes first.

> The good news is: it actually works! I love this Kernel ;) The
> GUI-thread does painting at 486-speed but it doens't hurt the

Yeah, GTK might not be the ideal choice in this case.
I'd say that for such a dedicated task where performance
is a main issue FLTK is a better choice.

I'd say that especially for terminatorX you *do* want the
GUI to have decent speed, at least the mouse-event handling.
Maybe you need a seperate thread for the mouse-events, but
maybe this complicates things too much...

> audio-thread anymore (Although I still get rare audio-dropouts (no
> matter whether the GUI-thread is busy or not)). But: running as root (==

You should apply the low-latency patch, this should solve that
problem.

> with the code described above enabled) tX sometimes causes system
> stalls. At first I thought that the cause of this might be some
> pthread_mutex-deadlocks() but I guess these should occur in normal
> operation mode (not messing with the scheduler at all) too, shouldn't
> they?

Are you sure you don't have a bug in the audio processing code?
If you enter a tight loop at rt-priority, you loose your system.

Good luck, indeed a PITA to debug... 

Maarten

From - Fri Dec 10 21:07:23 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA29436
	for <slinkp@ulster.net>; Fri, 10 Dec 1999 14:04:52 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA09246 for linux-audio-dev-list; Fri, 10 Dec 1999 13:42:58 -0500
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA09243 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 10 Dec 1999 13:42:50 -0500
Received: from linuxhost.localdomain (ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id TAA08585;
	Fri, 10 Dec 1999 19:36:29 +0100
Received: from linuxhost.localdomain (localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id UAA01175;
	Fri, 10 Dec 1999 20:36:38 +0100
From: Benno Senoner <sbenno@gardena.net>
To: Alexander Knig <alex@rhlx01.fht-esslingen.de>,
        Linux Audio Dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] SCHED_FIFO machine stalls
Date: Fri, 10 Dec 1999 20:31:44 +0100
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <3851391C.27E9858C@42.fht-esslingen.de>
MIME-Version: 1.0
Message-Id: <99121020363801.00813@linuxhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by em.gardena.net id TAA08585
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id OAA29436
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e57de62e6ba65537937bdc0ebd1570f9

On Fri, 10 Dec 1999, Alexander Knig wrote:
> Hi,
> 

> 
> The good news is: it actually works! I love this Kernel ;) The
> GUI-thread does painting at 486-speed but it doens't hurt the
> audio-thread anymore (Although I still get rare audio-dropouts (no
> matter whether the GUI-thread is busy or not)). But: running as root (==
> with the code described above enabled) tX sometimes causes system
> stalls. At first I thought that the cause of this might be some
> pthread_mutex-deadlocks() but I guess these should occur in normal
> operation mode (not messing with the scheduler at all) too, shouldn't
> they?
> 
> Well, anyway this problem is somewhat hard to debug so I could really
> use some suggestions ;)

remember that you need to be root to use SCHED_FIFO, that means
when setting the scheduling policy to SCHED_FIFO as a regular user
, the syscall simply returns -1 and does nothing.
You get higher priority because you raised the priority using setpriority(),
that means as normal user your audio engine runs still in the unix scheduler,
but with nice -20  which is still not perfect , because the gui thread could
interrupt the audio thread.

the lockups you are experiencing, are imho some deadlock, where your app uses
up all CPU, and you feel like the machine is frozen, even if the kernel is stil
alive.

any opinions from the other folks ?

Benno.



 > 
> Oh, btw, I use a plain 2.2.13 currently.
> 
> Bye,
> Alex
> -- 
> _______________________________________________________________________
>                             Alexander Knig - alex@42.fht-esslingen.de
>                                                   http://termX.cjb.net
> 
> [From the Homer Quotables:]
>  
> If it'll make you feel any better, I've learned that life is one
> crushing defeat after another until you just wish Flanders was dead.
> 
> 		-- Homer Simpson
> 		   Homer and Apu
--
Benno Senoner
E-Mail: sbenno@gardena.net
Linux low-latency audio / scheduling latency benchmarks
http://www.gardena.net/benno/linux/audio

From - Fri Dec 10 21:07:25 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA20641
	for <slinkp@ulster.net>; Fri, 10 Dec 1999 16:34:12 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA01444 for linux-audio-dev-list; Fri, 10 Dec 1999 16:22:23 -0500
Received: from rslx01.fht-esslingen.de (rslx01.fht-esslingen.de [134.108.51.101]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA01437 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 10 Dec 1999 16:22:16 -0500
Received: from firewall.dc.com (rsra54.fht-esslingen.de [134.108.128.54])
	by rslx01.fht-esslingen.de (8.9.3/8.9.3) with ESMTP id WAA05862;
	Fri, 10 Dec 1999 22:16:05 +0100
Received: from 42.fht-esslingen.de (machtnix.dc.com [192.168.192.168])
	by firewall.dc.com (8.9.3/8.9.3) with ESMTP id WAA00983;
	Fri, 10 Dec 1999 22:10:42 GMT
Message-ID: <38516A43.C6BCAF22@42.fht-esslingen.de>
Date: Fri, 10 Dec 1999 22:01:55 +0100
From: Alexander =?iso-8859-1?Q?K=F6nig?= <alex@rhlx01.fht-esslingen.de>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: maarten@things.nl
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] SCHED_FIFO machine stalls
References: <99121019143808.10521@mtg150.upf.es>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by rslx01.fht-esslingen.de id WAA05862
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id QAA20641
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 28d1667bb17e91b94eb7a14e05a173d6

maarten de boer wrote:
> Great program BTW.

Thanks :) Stay tuned for the next release... IMHO it's way better (Well
I guess that's what everybody says when they're trying to improve
something ;)

[SCHED_FIFO + prio -20]
> Yeah, that seems redundant to me.
> In my opinion it is not be necesairy at all to change the
> priority of the GUI thread. The audio thread had SCHED_FIFO
> priority and thus goes first.

Yeah right, it was just for testing... I'll remove it. As the thread is
no longer in SCHED_OTHER the scheduler doesn't even care about the
normal process prio, right?

> Yeah, GTK might not be the ideal choice in this case.
> I'd say that for such a dedicated task where performance
> is a main issue FLTK is a better choice.

Well, i'm pretty happy with gtk. The "speed-problem" is the
pixmapped-themes - but damn it - they definitely suit (IMHO of course)
audio progs ;) I've been waiting for a gtk-theme-engine that paints
gradients on the fly instead of stretching pixmap-gradients - from what
I know about windowmaker and blackbox that's faster and would proabably
even look better - but it seems nobody wants to code it - Or does
anybody know about such a project as gtk-gradient-engine btw?

> I'd say that especially for terminatorX you *do* want the
> GUI to have decent speed, at least the mouse-event handling.
> Maybe you need a seperate thread for the mouse-events, but
> maybe this complicates things too much...

Well on my machine plain gtk works pretty good - the widgets that need
speedy updateing are those I've written myself (the wavdisplay and the
new "level-meter") and as they're not standard they're not modified by
themes... Oh and the mouse input stuff happens in the audio-thread with
direct XFree-DGA mouse grabbing - no unnecessary latencies here ;)

> > audio-thread anymore (Although I still get rare audio-dropouts (no
> > matter whether the GUI-thread is busy or not)). But: running as root (==
> 
> You should apply the low-latency patch, this should solve that
> problem.

Yeah well the machine stalling is the bigger problem currently :( But my
next Kernel will have that patch applied.

> Are you sure you don't have a bug in the audio processing code?

Well I'm not sure but there are no deadlocks without SCHED_FIFO so... On
the other hand the problem occurs not very often so it may occur without
SCHED_FIFO too - I just dont know

> Good luck, indeed a PITA to debug...

Thanks!

Bye,
Alex
-- 
_______________________________________________________________________
                            Alexander Knig - alex@42.fht-esslingen.de
                                                  http://termX.cjb.net

[From the Homer Quotables:]
 
I didn't want a hokey second wedding like
those ones on TV!  This one's for real!

                -- Homer Simpson
                   A Milhouse Divided


From - Fri Dec 10 21:07:27 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA20640
	for <slinkp@ulster.net>; Fri, 10 Dec 1999 16:34:12 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA01443 for linux-audio-dev-list; Fri, 10 Dec 1999 16:22:21 -0500
Received: from rslx01.fht-esslingen.de (rslx01.fht-esslingen.de [134.108.51.101]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA01438 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 10 Dec 1999 16:22:16 -0500
Received: from firewall.dc.com (rsra54.fht-esslingen.de [134.108.128.54])
	by rslx01.fht-esslingen.de (8.9.3/8.9.3) with ESMTP id WAA05863;
	Fri, 10 Dec 1999 22:16:05 +0100
Received: from 42.fht-esslingen.de (machtnix.dc.com [192.168.192.168])
	by firewall.dc.com (8.9.3/8.9.3) with ESMTP id WAA00987;
	Fri, 10 Dec 1999 22:10:45 GMT
Message-ID: <38516C26.1ACBF001@42.fht-esslingen.de>
Date: Fri, 10 Dec 1999 22:09:58 +0100
From: Alexander =?iso-8859-1?Q?K=F6nig?= <alex@rhlx01.fht-esslingen.de>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Benno Senoner <sbenno@gardena.net>
CC: Linux Audio Dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] SCHED_FIFO machine stalls
References: <3851391C.27E9858C@42.fht-esslingen.de> <99121020363801.00813@linuxhost.localdomain>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by rslx01.fht-esslingen.de id WAA05863
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id QAA20640
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d1ea0169d9c25e6047fc3faf516abe95

Benno Senoner wrote:
> remember that you need to be root to use SCHED_FIFO, that means
> when setting the scheduling policy to SCHED_FIFO as a regular user
> , the syscall simply returns -1 and does nothing.

Yes, I actually "if (getuid())" before doing anything with prio... Even
for the decreasing the GUI-prio as you can't raise it again as normal
user - hey who wants to be a normal user anyway? :)

<..>

> the lockups you are experiencing, are imho some deadlock, where your app uses
> up all CPU, and you feel like the machine is frozen, even if the kernel is
> stil alive.

Assuming it's a deadlock - does anybody know a good strategy to detect
deadlocks? Errm, random deadlocks btw - stepping through it with a
debugger wont help here - and btw I never managed to get gdb debug a
pthreaded program properly.

Alex
-- 
_______________________________________________________________________
                            Alexander Knig - alex@42.fht-esslingen.de
                                                  http://termX.cjb.net

[From the Homer Quotables:]
 
I didn't want a hokey second wedding like
those ones on TV!  This one's for real!

		-- Homer Simpson
		   A Milhouse Divided

From - Fri Dec 10 21:07:28 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA25493
	for <slinkp@ulster.net>; Fri, 10 Dec 1999 17:05:54 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA01495 for linux-audio-dev-list; Fri, 10 Dec 1999 16:55:16 -0500
Received: from alsa.alsa-project.org (alsa.jcu.cz [160.217.1.49]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA01492 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 10 Dec 1999 16:55:14 -0500
Received: from localhost (andy@localhost)
	by alsa.alsa-project.org (8.9.3/8.9.3) with ESMTP id WAA29948;
	Fri, 10 Dec 1999 22:48:55 +0100
Date: Fri, 10 Dec 1999 22:48:55 +0100 (MET)
From: Andy Lo A Foe <andy@alsa-project.org>
To: Alexander =?iso-8859-1?Q?K=F6nig?= <alex@rhlx01.fht-esslingen.de>
cc: Benno Senoner <sbenno@gardena.net>,
        Linux Audio Dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] SCHED_FIFO machine stalls
In-Reply-To: <38516C26.1ACBF001@42.fht-esslingen.de>
Message-ID: <Pine.LNX.4.05.9912102242260.28183-100000@alsa.alsa-project.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by nerf.ulster.net id RAA25493
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 108f1a92f3f38a35d216953aa7fe0902

On Fri, 10 Dec 1999, Alexander [iso-8859-1] Knig wrote:

> Assuming it's a deadlock - does anybody know a good strategy to detect
> deadlocks? Errm, random deadlocks btw - stepping through it with a

AFAIK there is no good strategy other than designing your code to be
deadlock-free *grin*
The way to go is to make sure you got rid of all deadlocks before giving
the code SCHED_FIFO priority, this is kinda hard if the deadlocks only
occur under special (scheduling) circumstances, but hey, who said it was
easy? :)

> debugger wont help here - and btw I never managed to get gdb debug a
> pthreaded program properly.

Something that really helped me when debugging alsaplayer real-time
capabilities was the Sysreq keys. Whenever a deadlock occured in the
tight soundcard loop (which had SCHED_FIFO prior) I killed off the whole X
shebang with alt-shift-sysreq-k. It worked most of the time, allowed me to
recover without reboot/fsck. YMMV though...

Good luck,
Andy

PS. You can always try using the AlsaNode/AlsaSubscriber classes from
alsaplayer for your output needs. Gives you real-time capabilities coupled
to a straight forward interface (IMHO)

 

From - Fri Dec 10 21:07:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA28612
	for <slinkp@ulster.net>; Fri, 10 Dec 1999 17:28:48 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA01533 for linux-audio-dev-list; Fri, 10 Dec 1999 17:14:54 -0500
Received: from renoir.op.net (renoir.op.net [207.29.195.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA01530 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 10 Dec 1999 17:14:51 -0500
Received: from someip.ppp.op.net (d-bm2-15.ppp.op.net [209.152.194.53]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id RAA10981; Fri, 10 Dec 1999 17:05:58 -0500 (EST)
Message-Id: <199912102205.RAA10981@renoir.op.net>
To: Alexander K nig <alex@rhlx01.fht-esslingen.de>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] SCHED_FIFO machine stalls 
In-reply-to: Your message of "Fri, 10 Dec 1999 22:01:55 +0100."
             <38516A43.C6BCAF22@42.fht-esslingen.de> 
Date: Fri, 10 Dec 1999 17:06:07 -0500
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 147d2d07c2c0c760903645aba113226e

>> Are you sure you don't have a bug in the audio processing code?
>
>Well I'm not sure but there are no deadlocks without SCHED_FIFO so... On
>the other hand the problem occurs not very often so it may occur without
>SCHED_FIFO too - I just dont know

if you really do have places where you end up in a tight loop, you
won't detect the deadlock without SCHED_FIFO because regular
scheduling policy will ensure that other tasks run after you burn up
your timeslice. If you run with SCHED_FIFO, those pesky CPU-holding
loops turn into apparent deadlocks.

i don't know any good ways to debug this. fortunately, its never
happened to me.

--p

From - Fri Dec 10 21:07:30 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA32257
	for <slinkp@ulster.net>; Fri, 10 Dec 1999 17:52:56 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA01567 for linux-audio-dev-list; Fri, 10 Dec 1999 17:37:35 -0500
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA01564 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 10 Dec 1999 17:37:30 -0500
Received: from linuxhost.localdomain (ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id XAA11988;
	Fri, 10 Dec 1999 23:31:08 +0100
Received: from linuxhost.localdomain (localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id AAA01445;
	Sat, 11 Dec 1999 00:31:21 +0100
From: Benno Senoner <sbenno@gardena.net>
To: Alexander Knig <alex@rhlx01.fht-esslingen.de>, maarten@things.nl
Subject: [linux-audio-dev] realtime mouse/video .. Was: Re: SCHED_FIFO machine stalls 
Date: Sat, 11 Dec 1999 00:11:09 +0100
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: linux-audio-dev@ginette.musique.umontreal.ca
References: <38516A43.C6BCAF22@42.fht-esslingen.de>
MIME-Version: 1.0
Message-Id: <99121100312102.00813@linuxhost.localdomain>
X-MIME-Autoconverted: from 8bit to quoted-printable by em.gardena.net id XAA11988
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id RAA32257
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 1d6ddf65b191033204e8e6eaabba4cb3

On Fri, 10 Dec 1999, Alexander Knig wrote:
> maarten de boer wrote:
> > I'd say that especially for terminatorX you *do* want the
> > GUI to have decent speed, at least the mouse-event handling.
> > Maybe you need a seperate thread for the mouse-events, but
> > maybe this complicates things too much...
> 
> Well on my machine plain gtk works pretty good - the widgets that need
> speedy updateing are those I've written myself (the wavdisplay and the
> new "level-meter") and as they're not standard they're not modified by
> themes... Oh and the mouse input stuff happens in the audio-thread with
> direct XFree-DGA mouse grabbing - no unnecessary latencies here ;)

The type of widget toolkit doesn't matter (slow or fast) as long as you run the
GUI thread with lower priority than the audio engine.

The problem could be the interaction with the X server,
even if you read only mouse events via DGA, but you must go through the
X server.
I'm beginning to really hate the Xwindows concept from a realtime POV,
I discussed this a bit with Alan Cox and Daryl Strauss (of Precision Insight),
and they effectively admit that X is not designed from the ground up for
real-time use, or at least speaking in terms of an X server implementation.

I think a suitable solution could be to run the core X server part which 
has to cope with realtime tasks (dispatching loop,blitting)
as SCHED_FIFO / SCHED_RR (with lowest priority) thread,
and run a 2nd X server thread which does the non-realtime things like pixmap
allocation , memory handling etc. since these things are all non-deterministic.

Associate a priority to each X connection id
(similar to SCHED_FIFO and SCHED_RR) in order to let the X server execute
X requests from the higher priority Xclient, before all other clients.
( yes this could stall other X11 apps completely if the "realtime-X" client
uses the full Xserver bandwidth, but you asked for realtime and you got it :-)
)

I tested terminator-X while doing heavy disk I/O , CPU stuff etc in background,
on a low-latency kernel the audio doesn't drop out, but the mouse
responsiveness get very bad since the poor X server doesn't get rescheduled
in time in order to provide a smooth mouse event-stream to the app.
The resulting scratch sounds very crappy since , events come in bursts.

On the real-time audio side, we are now ok thank to the lowlatency stuff,
on the realtime video (which comprises keyboard+mouse managed by X)
we have still this problem, and I think it is not as trivial to solve as it
was for audio.

I hope that SGI  will bring some expertise in this field since they are
one of the major players in the realtime rendering/video fields.

(Daryll told me that they have still problems , even with XF4.0 DRI ,
when there are disturbing task in the background)

comments ?

Benno.


From - Fri Dec 10 21:07:32 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA20066
	for <slinkp@ulster.net>; Fri, 10 Dec 1999 20:21:03 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA01845 for linux-audio-dev-list; Fri, 10 Dec 1999 20:06:40 -0500
Received: from rslx01.fht-esslingen.de (rslx01.fht-esslingen.de [134.108.51.101]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA01842 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 10 Dec 1999 20:06:36 -0500
Received: from firewall.dc.com (rsra78.fht-esslingen.de [134.108.128.78])
	by rslx01.fht-esslingen.de (8.9.3/8.9.3) with ESMTP id CAA11632
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 11 Dec 1999 02:00:29 +0100
Received: from 42.fht-esslingen.de (machtnix.dc.com [192.168.192.168])
	by firewall.dc.com (8.9.3/8.9.3) with ESMTP id BAA01574
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 11 Dec 1999 01:55:14 GMT
Message-ID: <3851A22C.87D5C0E5@42.fht-esslingen.de>
Date: Sat, 11 Dec 1999 02:00:28 +0100
From: Alexander =?iso-8859-1?Q?K=F6nig?= <alex@rhlx01.fht-esslingen.de>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Linux Audio Dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] deadlocks contd
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by rslx01.fht-esslingen.de id CAA11632
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id UAA20066
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 32ba6ff2477d151c8cbaaf749edecb92

[Was Re: SCHED_FIFO machine stalls]

First of: thanks for all your suggestions. Now I tried to investigate
the problem a little further....

Am I correct that a deadlock can only occur where I try to lock more
than one mutex? Now I did a grep -15 mutex_lock over my .cc files and
found only one piece of code where I lock two mutexes: when I start the
audio-enigne. Now the stalls occur while playing when that code is no
longer relevant.

Well I know glibc (and maybe other libs) do locking too but I have only
one fd (for the dsp) and one X-Connection and I'm pretty sure there's no
problem with these.

Now what I should mention: I have experienced stalls before with my
machine, but those seemed to be related to xawtv (Yes - there's a nice
solution to that: turn of the tv ;) so maybe the problem is not
SCHED_FIFO related but occurs more proabably under such conditions....

Well, I'll try some more testing, updates and most importantly some
other machines (Yes I own only one :( ) and see what happens.

Alex
-- 
_______________________________________________________________________
                            Alexander Knig - alex@42.fht-esslingen.de
                                                  http://termX.cjb.net

[From the Homer Quotables:]
 
If there was any justice, my face would be on a bunch of crappy
merchandise!

		-- Homer Simpson
		   Flaming Moe's

From - Fri Dec 10 23:10:00 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id WAA06605
	for <slinkp@ulster.net>; Fri, 10 Dec 1999 22:52:00 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA02088 for linux-audio-dev-list; Fri, 10 Dec 1999 22:39:39 -0500
Received: from renoir.op.net (renoir.op.net [207.29.195.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA02085 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 10 Dec 1999 22:39:36 -0500
Received: from someip.ppp.op.net (d-bm2-19.ppp.op.net [209.152.194.57]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id WAA02058; Fri, 10 Dec 1999 22:30:41 -0500 (EST)
Message-Id: <199912110330.WAA02058@renoir.op.net>
To: Alexander K nig <alex@rhlx01.fht-esslingen.de>
cc: Linux Audio Dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] deadlocks contd 
In-reply-to: Your message of "Sat, 11 Dec 1999 02:00:28 +0100."
             <3851A22C.87D5C0E5@42.fht-esslingen.de> 
Date: Fri, 10 Dec 1999 22:30:43 -0500
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 80dd1e2a61dc165ce657e71d7d0f320c

>Am I correct that a deadlock can only occur where I try to lock more
>than one mutex? Now I did a grep -15 mutex_lock over my .cc files and
>found only one piece of code where I lock two mutexes: when I start the
>audio-enigne. Now the stalls occur while playing when that code is no
>longer relevant.

depends on what you mean by deadlock. what you referring to is
normally termed "livelock".

the way that pthread mutexes are implemented (under Linux anyway)
cannot cause your box to deadlock in the sense of "total lockup", even
if the lock-hungry threads are SCHED_FIFO. Thats because Pthreads
sigsuspend()'s each thread wanting a locked mutex, and it won't wake
up again until it is sent a POSIX signal when the lock is freed. The
only way to get pthread mutexes to cause machine-level "total lockup"
is to use pthread_mutex_trylock().

a more common form of "deadlock" is based around just a single lock.
this can happen inadvertently when just a single thread takes a lock,
and then calls pthread_mutex_lock() again instead of
pthread_mutex_unlock().  This happens to me from time to time when I
use emacs to cut and paste "pthread_mutex_lock(...)" a little too
carelessly. whenever i get a thread jammed somehow, it normally turns
out that i was doing this, and i look carefully for pairs of
lock/unlock calls. i also try to be very, very careful about ensuring
that there is a well defined lock heirarchy and a well defined lock
order (often the same thing), so that lock acquisition and release is
always in the same order.

so, you need to be more specific about what you mean by "deadlock". if
the box is totally jammed, and you don't use pthread_mutex_trylock in
a spin-loop, then pthread mutexes are not responsible.

--p

From - Sat Dec 11 00:50:31 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA16696
	for <slinkp@ulster.net>; Sat, 11 Dec 1999 00:31:25 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA02259 for linux-audio-dev-list; Sat, 11 Dec 1999 00:16:59 -0500
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA02256 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 11 Dec 1999 00:16:57 -0500
Received: from ulster.net (port122.ts2.ulster.net [208.242.164.122])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id AAA14797
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 11 Dec 1999 00:10:08 -0500
Message-ID: <3851DF2E.7FDB42C7@ulster.net>
Date: Sat, 11 Dec 1999 00:20:46 -0500
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] tempo estimator!
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: dcc437abd484900346b08c5fecbb3720

Hi folks,

here's a utility that guesses a tempo based on your taps on the
console kbd.
it just occurred to me today how easy this would be to do in pretty
much any language; I used python 'cause it's what I like for quick
stuff. a little searching in the python faq turned up exactly what I
needed, and voila...
feel free to modify / use / dispose of this anywhere it might be
handy (sequencer-like apps?)
 
................    paul winkler    ..................
slinkP arts:   music, sound, illustration, design, etc.
A member of ARMS    ----->    http://www.reacharms.com
or http://www.mp3.com/arms or http://www.amp3.com/arms
personal page   ---->    http://www.ulster.net/~abigoo

here's the code:

#!/usr/bin/python

print  """
Tap a steady beat on any key.
Hit 'q' to stop and print the estimated tempo of your beat.
"""

## This is almost entirely based on the 'keypress' entry in python
FAQ, by
## Andrew Kuchling.

import termios, TERMIOS, sys, os, time

fd = sys.stdin.fileno()
# Get 2 copies of termios info... one to modify, one to restore
old = termios.tcgetattr(fd)
new = termios.tcgetattr(fd)
# turn off "canonical mode" & "echo"
new[3] = new[3] & ~TERMIOS.ICANON & ~TERMIOS.ECHO
# I have no idea what these do-- not in python docs or 'man termios'
new[6][TERMIOS.VMIN] = 1
new[6][TERMIOS.VTIME] = 0
termios.tcsetattr(fd, TERMIOS.TCSANOW, new)

times = [] # save the time when keys are pressed.
try:
    while 1:
        c = os.read(fd, 1)
        when = time.time()
        if c == "q": break
        else:
            times.append(when)
            print "%s %f" % (c, when)
finally:
    # be sure to restore tty attributes no matter what!
    termios.tcsetattr(fd, TERMIOS.TCSAFLUSH, old)

diffs = []
for i in range(len(times)):
    try:
        diffs.append(times[i + 1] - times[i])
    except IndexError: pass #

sum = 0
## print "diffs:"
for d in diffs:
##      print d,
     sum = sum + d

estimate = 60.0 / (sum / len(diffs))
print "\n\nestimate is: %f" % estimate

From - Sat Dec 11 14:03:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id IAA12083
	for <slinkp@ulster.net>; Sat, 11 Dec 1999 08:30:54 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA06729 for linux-audio-dev-list; Sat, 11 Dec 1999 08:20:05 -0500
Received: from gamma.interaction.de (interaction.de [212.227.29.41]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA06726 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 11 Dec 1999 08:19:53 -0500
Received: (from sn@localhost)
	by gamma.interaction.de (8.9.1/8.8.5) id OAA10562
	for linux-audio-dev@ginette.musique.umontreal.ca; Sat, 11 Dec 1999 14:13:34 +0100
From: su sn <sn@vega.interaction.de>
Message-Id: <199912111313.OAA10562@gamma.interaction.de>
Subject: Re: [linux-audio-dev] SCHED_FIFO machine stalls
To: linux-audio-dev@ginette.musique.umontreal.ca
Date: Sat, 11 Dec 1999 14:13:34 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL39 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2af0ff05e7a790679aa0bbce0ab551e0


I noticed simular problems some time ago when writing my RTSynth
application.
At this time the program had the following layout:

- Audio/Synth thread with RT priority
- Midi input thread with RT priority 
- GUI thread with normal priority

from time to time the application went into a dead lock, which
did not happen if all threads where added to the same scheduler!
I tried hard to figure out what the problem was (mutex_lock/unlock
problems etc..) but didn't found a solution. To me it looked like
a general scheduler/thread bug. 
I noticed this problem with both linux 2.0.35 using pthreads and with 
linux 2.2.5.

To get rid of this problem together with some other problems I had
with the FLTK tool kit (at this time there was no multi thread support
available) I changed the layout to:

- Main program running with RT priority managing the GUI and the
  Audio/Synth things. BTW this results in a noticeable reduction
  of CPU load.
- Midi input thread with RT priority

With this layout everything works fine except for CPU overload
conditions which block the hole system. I also noticed a heavy bug with 
pipes: when the writer to a pipe get killed the reader eats all CPU power. 
Don't think this is posix conform.
To handle this conditions I added a "vital" thread running at normal
priority with nice 1. Every real time thread has a global variable which 
is increased on each loop and after reaching a given limit the thread 
stops itself or sleeps for a given time. The low priority "vital" thread
resets those global variables in a given time interval. On CPU overload
the "vital" thread does not get any/enough CPU time -> no variable reset ->
the real time threads are stopped by them self. 
On my system this works absolutely perfect under all conditions.

- Stefan


From - Sat Dec 11 14:03:32 1999
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA26074
	for <slinkp@ulster.net>; Sat, 11 Dec 1999 10:51:36 -0500
From: est@hyperreal.org
Received: (qmail 20905 invoked by uid 162); 11 Dec 1999 15:52:05 -0000
Message-ID: <19991211155205.20903.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] tempo estimator! (lispy version)
In-Reply-To: <3851DF2E.7FDB42C7@ulster.net> from Paul Winkler at "Dec 11, 1999
 00:20:46 am"
To: Paul Winkler <slinkp@ulster.net>
Date: Sat, 11 Dec 1999 07:52:05 -0800 (PST)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c47b5a67fee66cca0aade5e81b6ad55d

I genericized getting the times (for use with different interfaces) as
follows:

def get_times(waiter, protector=None):
    times = []
    try:
        while waiter():
            when = time.time()
            times.append(when)
            print when
    finally:
        when = time.time()
        times.append(when)
        if protector: protector()
        return times

def grabchar():
    c = os.read(fd, 1)
    return c != 'q'

def reset_term():
    termios.tcsetattr(fd, TERMIOS.TCSAFLUSH, old)

times = get_times(grabchar, reset_term)

..and the estimate computation became:

# compute sum-of-differences
sod = reduce(lambda x, y: x + y,
             map(lambda x, y: x - y, times[1:], times[:-1]))

estimate = 60.0 / (sod / (len(times) - 1))

Some might say that's less clear..but I say map() and reduce() are
always worth the learning curve. :D

E

From - Sat Dec 11 14:03:33 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA28032
	for <slinkp@ulster.net>; Sat, 11 Dec 1999 11:08:17 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA06891 for linux-audio-dev-list; Sat, 11 Dec 1999 10:58:17 -0500
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id KAA06888 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 11 Dec 1999 10:58:14 -0500
From: est@hyperreal.org
Received: (qmail 20905 invoked by uid 162); 11 Dec 1999 15:52:05 -0000
Message-ID: <19991211155205.20903.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] tempo estimator! (lispy version)
In-Reply-To: <3851DF2E.7FDB42C7@ulster.net> from Paul Winkler at "Dec 11, 1999
 00:20:46 am"
To: Paul Winkler <slinkp@ulster.net>
Date: Sat, 11 Dec 1999 07:52:05 -0800 (PST)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ea67bba4baa6465ce1e0d6506b95cc5a

I genericized getting the times (for use with different interfaces) as
follows:

def get_times(waiter, protector=None):
    times = []
    try:
        while waiter():
            when = time.time()
            times.append(when)
            print when
    finally:
        when = time.time()
        times.append(when)
        if protector: protector()
        return times

def grabchar():
    c = os.read(fd, 1)
    return c != 'q'

def reset_term():
    termios.tcsetattr(fd, TERMIOS.TCSAFLUSH, old)

times = get_times(grabchar, reset_term)

..and the estimate computation became:

# compute sum-of-differences
sod = reduce(lambda x, y: x + y,
             map(lambda x, y: x - y, times[1:], times[:-1]))

estimate = 60.0 / (sod / (len(times) - 1))

Some might say that's less clear..but I say map() and reduce() are
always worth the learning curve. :D

E

From - Sun Dec 12 02:54:31 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA03236
	for <slinkp@ulster.net>; Sat, 11 Dec 1999 17:02:50 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA07280 for linux-audio-dev-list; Sat, 11 Dec 1999 16:50:46 -0500
Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA07277 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 11 Dec 1999 16:50:43 -0500
Received: from d1o43.telia.com (root@d1o43.telia.com [194.22.195.241])
	by maile.telia.com (8.9.3/8.9.3) with ESMTP id WAA18580;
	Sat, 11 Dec 1999 22:44:29 +0100 (CET)
Received: from norran.net (roger@t2o43p39.telia.com [194.22.195.99])
	by d1o43.telia.com (8.8.8/8.8.8) with ESMTP id WAA01907;
	Sat, 11 Dec 1999 22:44:28 +0100 (CET)
Message-ID: <3852CE1A.86711856@norran.net>
Date: Sat, 11 Dec 1999 23:20:10 +0100
From: Roger Larsson <roger.larsson@norran.net>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Linux Audio Dev <linux-audio-dev@ginette.musique.umontreal.ca>
CC: David Olofson <audiality@swipnet.se>
Subject: [linux-audio-dev] [SRC] trial API (r2)
References: <3851391C.27E9858C@42.fht-esslingen.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: b5f99fd3b0e0e1ea5c7ae08c41619a3a

Hi all,

(David, can you make a link to this from MuCoS, I would like
 too play, too...)

My little trial API has become one release older...


News 1999-12-11: 

     cleaned it up, plugin_*.c looks nicer now... :-) 
     better handling of time 
     added effective polymorphism (see plugin_charStdin.c, file should
be renamed) 

You are welcome to look at some explaining (or confusing) text and
get the source from:

http://www.norran.net/nra02596/

or more directly from:

http://www.norran.net/nra02596/trial.html

Comments are more than welcome!

/RogerL

From - Sun Dec 12 02:54:35 1999
Received: from maile.telia.com (maile.telia.com [194.22.190.16])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id RAA04556
	for <slinkp@ulster.net>; Sat, 11 Dec 1999 17:14:41 -0500
Received: from d1o43.telia.com (root@d1o43.telia.com [194.22.195.241])
	by maile.telia.com (8.9.3/8.9.3) with ESMTP id XAA27134;
	Sat, 11 Dec 1999 23:15:06 +0100 (CET)
Received: from norran.net (roger@t2o43p39.telia.com [194.22.195.99])
	by d1o43.telia.com (8.8.8/8.8.8) with ESMTP id XAA13136;
	Sat, 11 Dec 1999 23:15:00 +0100 (CET)
Sender: roger@d1o43.telia.com
Message-ID: <3852D543.5F6250AD@norran.net>
Date: Sat, 11 Dec 1999 23:50:43 +0100
From: Roger Larsson <roger.larsson@norran.net>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: est@hyperreal.org
CC: Paul Winkler <slinkp@ulster.net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] tempo estimator! (lispy version)
References: <19991211155205.20903.qmail@hyperreal.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: a87a1180b58495dd45bfcbf1e0c73e7b

est@hyperreal.org wrote:
> 

> 
> # compute sum-of-differences
> sod = reduce(lambda x, y: x + y,
>              map(lambda x, y: x - y, times[1:], times[:-1]))
> 

Hmm...

sod = last(times) - head(times) ?

or??? Am I missing something

/RogerL

PS
  I am not familiar with python syntax and semantics...
  But ML and Erlang are among my favourite languages!

  See
    http://www.erlang.org/
DS

--
Home page:
  http://www.norran.net/nra02596/

From - Sun Dec 12 02:54:37 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA05949
	for <slinkp@ulster.net>; Sat, 11 Dec 1999 17:29:00 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA07335 for linux-audio-dev-list; Sat, 11 Dec 1999 17:21:19 -0500
Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA07332 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 11 Dec 1999 17:21:16 -0500
Received: from d1o43.telia.com (root@d1o43.telia.com [194.22.195.241])
	by maile.telia.com (8.9.3/8.9.3) with ESMTP id XAA27134;
	Sat, 11 Dec 1999 23:15:06 +0100 (CET)
Received: from norran.net (roger@t2o43p39.telia.com [194.22.195.99])
	by d1o43.telia.com (8.8.8/8.8.8) with ESMTP id XAA13136;
	Sat, 11 Dec 1999 23:15:00 +0100 (CET)
Message-ID: <3852D543.5F6250AD@norran.net>
Date: Sat, 11 Dec 1999 23:50:43 +0100
From: Roger Larsson <roger.larsson@norran.net>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: est@hyperreal.org
CC: Paul Winkler <slinkp@ulster.net>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] tempo estimator! (lispy version)
References: <19991211155205.20903.qmail@hyperreal.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: adf6c0183112ffbef271c2bab2f3191b

est@hyperreal.org wrote:
> 

> 
> # compute sum-of-differences
> sod = reduce(lambda x, y: x + y,
>              map(lambda x, y: x - y, times[1:], times[:-1]))
> 

Hmm...

sod = last(times) - head(times) ?

or??? Am I missing something

/RogerL

PS
  I am not familiar with python syntax and semantics...
  But ML and Erlang are among my favourite languages!

  See
    http://www.erlang.org/
DS

--
Home page:
  http://www.norran.net/nra02596/

From - Sun Dec 12 02:54:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA13813
	for <slinkp@ulster.net>; Sun, 12 Dec 1999 01:01:57 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA07962 for linux-audio-dev-list; Sun, 12 Dec 1999 00:35:44 -0500
Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id AAA07959 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 12 Dec 1999 00:35:42 -0500
From: est@hyperreal.org
Received: (qmail 14801 invoked by uid 162); 12 Dec 1999 05:29:30 -0000
Message-ID: <19991212052930.14800.qmail@hyperreal.org>
Subject: Re: [linux-audio-dev] tempo estimator! (lispy version)
In-Reply-To: <3852D543.5F6250AD@norran.net> from Roger Larsson at "Dec 11, 1999
 11:50:43 pm"
To: Roger Larsson <roger.larsson@norran.net>
Date: Sat, 11 Dec 1999 21:29:29 -0800 (PST)
CC: linux-audio-dev@ginette.musique.umontreal.ca
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 592c136156efce9ac27a74fa0efd221c

Roger Larsson discourseth:
> est@hyperreal.org wrote:
> > 
> > # compute sum-of-differences
> > sod = reduce(lambda x, y: x + y,
> >              map(lambda x, y: x - y, times[1:], times[:-1]))
> > 
> 
> Hmm...
> 
> sod = last(times) - head(times) ?
> 
> or??? Am I missing something

Only my master plan of making a fool of myself on the list to help
give it a relaxed tone and encourage others to post. :D

Hmm..or *maybe* I was planning on moving to a geometric mean..that
would save my lambdas!

>   I am not familiar with python syntax and semantics...
>   But ML and Erlang are among my favourite languages!

Woohoo!  Functional programming in da house!

E

From - Sun Dec 12 15:43:51 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA05242
	for <slinkp@ulster.net>; Sun, 12 Dec 1999 07:42:25 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id HAA12166 for linux-audio-dev-list; Sun, 12 Dec 1999 07:32:54 -0500
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA12163 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 12 Dec 1999 07:32:51 -0500
Received: from localhost.localdomain (d212-151-51-158.swipnet.se [212.151.51.158]) 
          by mb04.swip.net (8.8.8/8.8.8) with SMTP 
          id NAA04403; 
          Sun, 12 Dec 1999 13:25:39 +0100 (MET)
From: David Olofson <audiality@swipnet.se>
To: Roger Larsson <roger.larsson@norran.net>,
        Linux Audio Dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Re: [SRC] trial API (r2)
Date: Sun, 12 Dec 1999 13:32:39 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <3851391C.27E9858C@42.fht-esslingen.de> <3852CE1A.86711856@norran.net>
In-Reply-To: <3852CE1A.86711856@norran.net>
MIME-Version: 1.0
Message-Id: <99121213354300.00490@localhost.localdomain>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id HAA05242
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: e60e8a584f35827f461a25b4a38b16b8

On Sat, 11 Dec 1999, Roger Larsson wrote:
> Hi all,
> 
> (David, can you make a link to this from MuCoS, I would like
>  too play, too...)

Yes, indeed! The link will be up some time today. :-)

> Comments are more than welcome!

I'll have a look any day now - perhaps not today, though, as I should
be working on some tunes...


//David


 AUDIALITY   P r o f e s s i o n a l   L i n u x   A u d i o
-  - ------------------------------------------------------------- -  -
    Rock Solid                                      David Olofson:
    Low Latency    www.angelfire.com/or/audiality   Audio Hacker
    Plug-Ins            audiality@swipnet.se        Linux Advocate
    Open Source                                     Singer/Composer

From - Mon Dec 13 12:21:11 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA19808
	for <slinkp@ulster.net>; Mon, 13 Dec 1999 10:03:16 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA17743 for linux-audio-dev-list; Mon, 13 Dec 1999 09:37:20 -0500
Received: from renoir.op.net (renoir.op.net [207.29.195.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA17740 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 13 Dec 1999 09:37:11 -0500
Received: from op.net (d-bm2-1d.ppp.op.net [209.152.194.61]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id JAA19497; Mon, 13 Dec 1999 09:27:59 -0500 (EST)
Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id XAA04529; Sun, 12 Dec 1999 23:00:16 -0500
Date: Sun, 12 Dec 1999 23:00:16 -0500
Message-Id: <199912130400.XAA04529@op.net>
From: Paul Barton-Davis <pbd@Op.Net>
To: qm-dev@exp.firstpr.com.au
Subject: [linux-audio-dev] Quasimodo parameters, etc.
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 1dd21bdfa731836183b0748dfd7b37c1

[ LAD folk: I forwared this because it occured to me after writing it
  that it might be of interest to some of you. Its something of an
  expansion on a post I made last week. If it bores the pants off you,
  please excuse the intrusion. --p ]

OK, I will try to clear up some misconceptions and confusion that
Stephane (and probably others) have about Parameters in
Quasimodo. I'll have to start with a basic summary of how Quasimodo
works. 

The fundamental unit of execution in Quasimodo is an opcode
function. This is a regular C/C++ function which takes a
ptr-to-an-OpcodeArgument as its argument (more precisely, a pointer to
a class derived from OpcodeArgument). The members of this structure
contain the data needed by the opcode to do whatevers it is going to
do. Many, and often all, of these members are numeric values, either
scalars ("Control values"), or arrays ("Audio values"). To avoid
data copying, the members are actually pointers to numeric
values. Currently, they are almost all of type Number, which is
typedef'ed to be a float. There is a hack to encode string values into
pointers to a float, but its totally irrelevant and confusing for the
purposes of this message.

So, to execute an opcode successfully, we have to set up both its
OpcodeArgument-derived argument, some memory to hold the numeric
values, and then set the members of the OpcodeArgument to point to the
right locations in our memory space. Then we can just call the opcode
function with the argument and we're done. Easy.

Well, not quite. A Module contains a ProgramTemplate. A
ProgramTemplate is (put simply) a linked list of
DspInstructionTemplates, each of which contains an pointer to an
opcode information structure, and pointers to the Parameters that will
be used for the input and output arguments to be used by the opcode
function.

The task of setting up the OpcodeArgument members really comes down to
looking at the Parameters, and figuring out what address to use to set
the relevant member to.

If every Module was monophonic - that is, if there was only ever a
single DspProcess created for any module - and there was no
cross-module patching (like Csound), the process of mapping Parameters
to addresses would be simple. We wouldn't need a ProgramTemplate, just
its instantiated form (Program - see 2 paragraphs below). We would
just figure out at module compilation time how much data space the
module needed, allocate it, and then go through the Program,
fixing up each OpcodeArgument in turn to use pointers into the
allocated space.

However, neither of things is true - Modules are polyphonic by
default, and we do have cross-module patching. The polyphonic aspect
means that we can't allocate the memory for the data values on a
per-module basis. Why ? Because each "voice" must have its own
independent parameters, of which "pitch" is the most obvious. So we
instead defer this until we create an actual DspProcess. Thats why we
use a ProgramTemplate - its essentially a form a position-independent
code.  However, a DspProcess doesn't contain a
ProgramTemplate. Instead, it contains an actual Program - a pair of
linked lists of DspInstructions - and a data memory area.

Each DspInstruction contains a pointers to the relevant opcode
function, and the argument structure for the opcode. So, when we
convert a ProgramTemplate into a Program, we convert all uses of the
Parameters into pointers to specific addresses. Most of these
addresses will be within the DspProcess data block. A few will point
to reserved variable locations (e.g. if you use "ksmps" or "sr"), or
to other "external" memory, such as MIDI controller values (if you use
"c23", "c45" etc).

How are the Parameters converted into addresses ? Each Parameter
contains a DspOffset member. A DspOffset is basically a number
combined with a type. If the type was "pointer", then the number is a
raw C/C++-level pointer value. If the type was "data", the number is
an offset in bytes from the start of the DspProcess' data area where
the Parameter's data can be found. And so on. There aren't many offset
types. Converting a DspOffset into a real C/C++ address is clearly
pretty easy once you know the address of the DspProcess data area.
 
So, this is the normal way things happen. Once this link-editing is
done, the DspProcess is ready to run: we have a 2 linked lists of
pointers to functions, plus a set of structure arguments whose members
point to real data. Why *2* linked lists: one of init-time functions,
and the other of run-time functions. 

OK, when the DspProcess starts, the first thing that happens is that
the DSP object executing the Process calls DspProcess::init(). This
causes the DspProcess to traverse the init-time function pointer list,
calling each opcode function in turn, passing it the appropriate
argument structure, which in turns contains pointers to the relevant
data locations. Once this is successfully done, the DspProcess enters
the DSP object's work queue. For each iteration of the DSP main
loop, the DSP object will call DspProcess::execute(). This causes the
run-time function pointer list for the DspProcess to be executed once
per iteration, subject to any control-flow stuff done by the opcodes
themselves (e.g. kgoto, etc.)

Great, so now we're all clear on how things happen without patching,
right ? Well, lets just take a little example to make sure its clear.
Consider the statement:

	 kvar init 0

This will be compiled down to:

        * a function pointer to "void kinit(AOP *)" in the init-time function
          ptr list
	* an AOP structure containing a 

		 Number *r;
		 Number *v;
      
          "r" will point to the per-process data address corresponding
          to kvar; "v" will contain a pointer to an address
          containing 0.0f

When we run DspProcess::init(), we will call kinit(AOP *), and after
this, the per-process data corresponding to kvar will contain 0.0f.
	  
All with me ? OK. Now lets suppose that the interface for the Module
containing the statement above defines a knob to set the value of
"kvar". Whenever the UI decides it is appropriate, it will call
Module::parameter_edit (Parameter &, Datum &newval). A Datum is a
basic class that can hold a float or a string value, and be used
interchangeably as either (more or less).

What does parameter_edit() do ? Well, it does 2 critical things:

     1) it traverses the set of currently active DspProcesses for the Module.
        For each DspProcess, it adjusts the numeric value stored in
	the part of per-process data area corresponding to the Parameter.

     2) it looks at the Parameter, which was set up during Module
        compilation with a pointer to the DspInstructionTemplate that
	is "responsible" for initializing the Parameter during
        DspProcess::init(). It takes the first input argument to that
	DspInstructionTemplate, and alters it to point to the value
	given by the Datum.

(it also drops every "zombie process" - DspProcesses that could
otherwise be reused by later requests for a DspProcess instantiating
this Module - because doing so is quicker and more efficient than
having to edit them as well; they contain the old value for the
Parameter, which would spell trouble (and did, before I realized this
a few months back).

Now, clearly, step 2 is problematic. It represents a very important
and not very general assumption that the initializing opcode for the
Parameter is something like "init", and that its argument is a
constant that can easily be replaced. Consider:

	 kvar init 3/5

In this case, the constructor will be init, but init's first input
argument will be a "temporary" holding the value of "div 3, 5". In
this particular case, replace the DspOffset that refers to the
temporary is fine (though it will leave us with some "stranded"
init-time functions that are never executed anymore), but its not hard
(I think) to come up with some other examples that would not work so
well. This is particularly true of Csound-init-time variables.

Anyway, the net result is that the Module has just been edited so that
not only all currently running DspProcesses have the new value, but
any newly instantiated DspProcesses will also set the Parameter to the
new value during initialization.

Lets move on to patching, which is both simpler and more complex. 

The fundamental goal of the patching system is to avoid data
copying. As far as I know, Quasimodo is unique in its approach to
this. Modules/DspProcesses do *NOT* pass data around - they share data
pointers, just like any sensible C/C++ programmer would do if they
were writing equivalent code. How do they do this ? 

To be able to use a Parameter for patching, something (typically the
UI/front end) needs to call Parameter::mark_as_patchpoint().  This
gets the Parameter allocates some memory to hold its value. Recall
that before this, the Parameter would have probably had a DspOffset of
type "data", meaning that its memory location is somewhere in the
per-process data area of the executing DspProcess. After this step,
the DspOffset is of type "pointer", and the "number" part of the
DspOffset points directly to the memory allocated by the
Parameter. This means that we can share this data location across (1)
all DspProcesses instantiating the Module to which the Parameter
belongs, and (2) share it across all other DspProcesses.

(1) is obvious, I hope. (2) is probably not. How do we accomplish this?

We do a little trick called "run time editing". When a patch is
created, the destination Parameter causes its Module to traverse all
currently active DspProcesses, and check every DspInstruction in their
init-time and run-time lists. If the Instruction uses the Parameter as
an argument, then the argument is replaced with a pointer to the
originating Parameter's data location. Result ? the patched-into
Module's DspProcess' opcodes see the same data location as the
patched-from Module's DspProcess' opcodes. Whether they read or write,
they are sharing the data. There is no data copying.

All with me still ? So, now we have two DspProcesses running on a DSP,
and sharing data via a Parameter that had mark_as_patchpoint() called
upon it. Excellent.

But what happens when the originating DspProcess shuts down ? The data
storage associated with the Patch won't go away - its fundamentally
associated with the Parameter, not the DspProcess - but the value left
in it will be the last thing written (presumably by the originating
DspProcess). This can lead to some very ugly results. To stay roughly
in keeping with the analog model Quasimodo is emulating, when a
DspProcess shuts down, all Parameters that were marked as (output)
patchpoints are set to zero. However, this happens only once *PER
MODULE PER DSP MAIN LOOP*. This means that if the Module is
polyphonic, other still-running DspProcesses will still get their
chance to write *their* data into the Parameter/patchpoint memory
location, and the receiving Module/DspProcesses will get that
instead. If the Module had only a single DspProcess running, then the
zeroing has effectively turned off all power to the Module, and so
complete silence (or zero values for scalar "control" elements) is all
that we can "hear" on all patchcords originating from the that
Module. The effect is intended to be similar to what one would expect
if you could create a patch where the originating point was "nowhere"
- you'd get no signal at all.

Its also important to realize the that this zeroing of patchpoint data
is *vital* for polyphony. There is a page in the HTML manual about
this. Polyphonic modules are required to use additive methods of
writing to their output sockets, because otherwise, only the last
active DspProcess will get its output to be "audible". Because of
this, it is critical that the data associated with each Parameter
being used as an output patchpoint is zeroed on each iteration of the
DSP main loop; without it, we would end up with numerical overflow and
sonic distortion.

Lets take another look at a concrete example that Stephane asked
about:

>Could you explain me what happens exactly when executing a program ?
>
>look at this:
>
>Module 1
>kparam init 0; actualy controlled by a knob and reflect by an output
>socket
>
><knob param="kparam"/>
><socket param="kparam" direction="output"/>
>
>Module 2:
>kfreq init 0
>aout rtsin kfreq, 32000
>
><socket param="kfreq" direction="input"/>
><socket param="aout" direction="output"/>
>
>Module 3:
>outs aleft, aright
>
><socket...
>
>
>there is a patch between the kparam and kfreq
>and a patch between aout and aleft.
>
>what happens when the program is executed ?

1) something calls Module::turnon() (MIDI/the on-off button)
2) an Execute request is sent to the DSP object, naming the Module
3) the DSP calls Module::checkout_process(), which returns a new DspProcess
4) the DSP calls DspProcess::init()
5) the DSP puts the DspProcess into its Work queue
6) on every iteration, the DSP calls DspProcess::execute() until
   the DspProcess is no longer runnable.

>what buffers are created ?

for Module 1: a per-process data location (sizeof(float) for kparam (never used)
              a shared location for kparam (because it was marked as a 
					    patchpoint) 

for Module 2: a per-process data location (sizeof(float) for kfreq (never used)
              a shared location for kparam (because it was marked as a 
					    patchpoint) 
              a per-process data location (sizeof(float)*CycleFrames) for
			    aout (never used)
              a shared location for aout (because it was marked as a 
					    patchpoint) 

for Module 3: a per-process data location (sizeof(float)*CycleFrames) for
			    aleft (never used)
              a shared location for aleft (because it was marked as a 
					    patchpoint) 
	      a per-process data location (sizeof(float)*CycleFrames) for
			    aright (never used)
              a shared location for aright (because it was marked as a 
					    patchpoint) 

Once the patch aout -> aleft is set up, any DspProcess for Module 3
will be executing a DspProgram in which all pointers to the shared
location of Module 3/aleft now point to the shared location associated
with Module 2/aout.

Once the patch for kparam -> kfreq is set up, any DspProcess for
Module 2 will be executing a DspProgram in which all pointers to the
per-process location of kfreq now point to the shared location
associated with Module 1/kparam.

>when values are copied, if they are ever ?

No data copying.

>is there a buffer copy in the audio case ?

No data copying.

I hope this clears up some confusion. It may also help others to get
up to speed on some of the more complex aspects of Quasimodo's
internals. It may be that there is a fatal flaw in all this, but if
so, getting other people to critique it is the only way I'll ever know :)

--p

 

From - Tue Dec 14 02:25:40 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA24126
	for <slinkp@ulster.net>; Mon, 13 Dec 1999 23:24:15 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA18806 for linux-audio-dev-list; Mon, 13 Dec 1999 23:10:47 -0500
Received: from hme0.smtp04.sprint.ca (hme0.smtp04.sprint.ca [207.107.250.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA18803 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 13 Dec 1999 23:10:45 -0500
Received: from vektor.div8.net (root@spc-isp-ktc-uas-9-23.sprint.ca [209.148.133.174])
	by hme0.smtp04.sprint.ca (8.8.8/8.8.8) with ESMTP id XAA12923;
	Mon, 13 Dec 1999 23:04:21 -0500 (EST)
Received: by div8.net
	via sendmail from stdin
	id <m11xjHO-00096BC@vektor.div8.net> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Mon, 13 Dec 1999 23:09:38 -0500 (EST) 
Date: Mon, 13 Dec 1999 23:09:38 -0500
From: "'Billy Biggs'" <vektor@DIV8.NET>
To: "Richard W.E. Furse" <richard@muse.demon.co.uk>
Cc: Linux Audio Dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Silly audio problem
Message-ID: <19991213230938.A21470@div8.net>
References: <01BF45E5.AD532D40@bartman.plc.psion.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <01BF45E5.AD532D40@bartman.plc.psion.com>; from richard@muse.demon.co.uk on Tue, Dec 14, 1999 at 03:42:57AM -0000
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 578842d2249855c16d2d80aaeccd09d6

Richard W.E. Furse (richard@muse.demon.co.uk):

> Have you tried larger buffers?

  I can't.  The phone I'm talking to can only do 20ms framing and barely any
network buffer, so I have to make sure that I send out frames consistently at
20ms intervals.  This means keeping my buffer smaller than that.

  On the soundcard, I've got a buffer of 32 samples, at 8k.

  PS, on my es1370 alsa, the microphone mysteriously stopped working...  any
ideas?

> -----Original Message-----
> From:	Billy Biggs [SMTP:vektor@DIV8.NET]
> Sent:	Tuesday, December 14, 1999 1:32 AM
> To:	Linux Audio Dev
> Subject:	[linux-audio-dev] Silly audio problem
> 
> Hi,
> 
>   I'm wondering if I could get an objective opinion on an annoying problem I'm
> having.  I'm almost positive the bug is my fault, I'm just looking for thoughts
> on what might be the problem.
> 
>   I'm programming an internet telephony app.  I read in audio off the soundcard
> at mono 16bit, 8000 samples/sec.  I then convert the 16bit shit audio to even
> worse mu-law 8bit audio and stream it out the network.  I get mu-law input from
> the network which I then play back out the soundcard.
> 
>   I've got an ens1370 card (AudioPCI) and am using ALSA 0.4.1h (debian potato
> package).
> 
>   The problem is this:  The sound on the receiving end sounds really awful,
> then switches and sounds good for a while, but then sometimes falls back to
> sounding awful again.  The bass gets this big rumbling sound and it kinda
> sounds like it's clipping.  Definitely sounds chunky.
> 
>   Often, if it's playing all chunky like, if I run 'aumix' to fix the volume,
> that triggers it back to sound-okay mode.
> 
>   Any ideas what might cause this behavior?  I'm likely doing something
> obviously wrong, I've just been staring at it too long.  The code is very
> simple though.

-- 
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

From - Tue Dec 14 02:25:42 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA24706
	for <slinkp@ulster.net>; Mon, 13 Dec 1999 23:29:08 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA18818 for linux-audio-dev-list; Mon, 13 Dec 1999 23:19:49 -0500
Received: from hme0.smtp04.sprint.ca (hme0.smtp04.sprint.ca [207.107.250.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA18815 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 13 Dec 1999 23:19:47 -0500
Received: from vektor.div8.net (root@spc-isp-ktc-uas-9-23.sprint.ca [209.148.133.174])
	by hme0.smtp04.sprint.ca (8.8.8/8.8.8) with ESMTP id XAA25600;
	Mon, 13 Dec 1999 23:13:25 -0500 (EST)
Received: by div8.net
	via sendmail from stdin
	id <m11xjQD-00096BC@vektor.div8.net> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Mon, 13 Dec 1999 23:18:45 -0500 (EST) 
Date: Mon, 13 Dec 1999 23:18:45 -0500
From: "'Billy Biggs'" <vektor@DIV8.NET>
To: "Richard W.E. Furse" <richard@muse.demon.co.uk>
Cc: Linux Audio Dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Silly audio problem
Message-ID: <19991213231844.A21801@div8.net>
References: <01BF45E5.AD532D40@bartman.plc.psion.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <01BF45E5.AD532D40@bartman.plc.psion.com>; from richard@muse.demon.co.uk on Tue, Dec 14, 1999 at 03:42:57AM -0000
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e1c7d7e5be4faf501a823bfed5f8fa84

Richard W.E. Furse (richard@muse.demon.co.uk):

> Have you tried larger buffers?

  Update:  I went up as close as I could to 20ms for the buffer size, and it
didn't help.  It's soo strange, the audio just shifts between sounding find and
sounding crappy.

  It also seems to kinda be related to disk activity- however I think this
assumption is bogus, since if I use 'wavr' to record audio using the same
parameters (16bit, 8k, mono), it doesn't experience the same crapness.

-- 
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

From - Tue Dec 14 02:25:43 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA28368
	for <slinkp@ulster.net>; Tue, 14 Dec 1999 00:02:43 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA18854 for linux-audio-dev-list; Mon, 13 Dec 1999 23:51:40 -0500
Received: from renoir.op.net (renoir.op.net [207.29.195.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA18851 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 13 Dec 1999 23:51:38 -0500
Received: from someip.ppp.op.net (d-bm2-04.ppp.op.net [209.152.194.36]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id XAA14525 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 13 Dec 1999 23:43:36 -0500 (EST)
Message-Id: <199912140443.XAA14525@renoir.op.net>
To: Linux Audio Dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Silly audio problem 
In-reply-to: Your message of "Mon, 13 Dec 1999 23:18:45 EST."
             <19991213231844.A21801@div8.net> 
Date: Mon, 13 Dec 1999 23:43:37 -0500
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ea8556e8ffb3785621cca2209e33df5a

>  Update:  I went up as close as I could to 20ms for the buffer size, and it
>didn't help.  It's soo strange, the audio just shifts between sounding find an
>d
>sounding crappy.
>
>  It also seems to kinda be related to disk activity- however I think this
>assumption is bogus, since if I use 'wavr' to record audio using the same
>parameters (16bit, 8k, mono), it doesn't experience the same crapness.

check your code *very* carefully. on at least 3 occasions i have had
this kind of thing happen, only to later discover that there was a bug
in my code that only revealed itself at certain buffer sizes/sample
rate values/sample bit sizes.

--p

From - Tue Dec 14 05:40:35 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id DAA07151
	for <slinkp@ulster.net>; Tue, 14 Dec 1999 03:06:24 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id CAA22874 for linux-audio-dev-list; Tue, 14 Dec 1999 02:50:44 -0500
Received: from ife.ee.ethz.ch (ife-fast.ee.ethz.ch [129.132.24.193]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA22871 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 14 Dec 1999 02:50:41 -0500
Received: from ife.ee.ethz.ch (eldrich.ee.ethz.ch [129.132.24.203])
	by ife.ee.ethz.ch (8.8.5/8.8.5) with ESMTP id IAA09707;
	Tue, 14 Dec 1999 08:44:16 +0100 (MET)
Message-ID: <3855F550.E67EFDEF@ife.ee.ethz.ch>
Date: Tue, 14 Dec 1999 08:44:16 +0100
From: Thomas Sailer <sailer@ife.ee.ethz.ch>
Organization: IfE
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4u)
X-Accept-Language: de,fr,ru
MIME-Version: 1.0
To: "'Billy Biggs'" <vektor@DIV8.NET>
CC: Linux Audio Dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Silly audio problem
References: <01BF45E5.AD532D40@bartman.plc.psion.com> <19991213230938.A21470@div8.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 4dc2488b82ad444cc282bd839e73defc

'Billy Biggs' wrote:

>   PS, on my es1370 alsa, the microphone mysteriously stopped working...  any
> ideas?

Does your microphone need bias? If so check if the alsa driver sets the
microphone bias bit correctly in the control register.

Tom

From - Tue Dec 14 15:41:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA15206
	for <slinkp@ulster.net>; Tue, 14 Dec 1999 06:02:26 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id FAA23227 for linux-audio-dev-list; Tue, 14 Dec 1999 05:41:57 -0500
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA23224 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 14 Dec 1999 05:41:54 -0500
Received: from ulster.net (port45.ts2.ulster.net [208.242.164.45])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id FAA13864;
	Tue, 14 Dec 1999 05:35:18 -0500
Message-ID: <38561FBB.9E6F836F@ulster.net>
Date: Tue, 14 Dec 1999 05:45:15 -0500
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
CC: Dave Phillips <dlphilp@bright.net>
Subject: [linux-audio-dev] pysco alpha release - trying again
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 58315cb7e528a1eaa63c8ee22ebe14e9

Sorry if any (all?) of you have seen this before. It hasn't shown up
in the list traffic on this end, so I'm re-sending it.

--------------------------------------------------------------

OK, after an amazing amount of time fiddling and grumbling, I've
finally decided to release pysco.py, a python module that
replaces my old barely-functional Pscore.pm and does a lot more.
So I've named my current source 0.0.1 and am releasing it today.


get it here:
www.ulster.net/~abigoo/pw_linux/code.html

What it is:
pysco.py is a python module for mucking around with csound scores.

It is undergoing rapid changes and anything you do with it today
is guaranteed to be broken with next week's version. It has just now
reached the stage where I can start to make music with it, which
means I'll be pretty rapidly discovering what's missing, what's
stupid, what needs a total re-design, etc.


It might eventually be extended to work with other kinds of musical
data and output (e.g. direct to midi devices etc.). Or not.

It is basically procedural in style; it might eventually become more
object-oriented. Or not.

Oh yeah, it's (c) 1999 Paul M. Winkler (slinkp@angelfire.com)
and is released under the GNU General Public License (GPL).
Which means this is free software and there is absolutely no
warranty
of any kind.

currently working features:

unlimited separate output time-streams ("tracks")

unlimited simultaneous different tempos (each track can have its
own tempo, including independent accelerandos / ritards) ... thanks
audio-dev people for helping out!

unlimited named "chunks" of events

many functions provide automatic time updating

will eventually provide many tools for automatically choosing
notes from chunks based on arbitrary criteria; so far only selection
by beat value is implemented.

much documentation in the source

Oh yeah, it's (c) 1999 Paul M. Winkler (slinkp@angelfire.com)
and is released under the GNU General Public License (GPL).
Which means this is free software and there is absolutely no
warranty
of any kind.



-- 
................    paul winkler    ..................
slinkP arts:   music, sound, illustration, design, etc.
A member of ARMS    ----->    http://www.reacharms.com
or http://www.mp3.com/arms or http://www.amp3.com/arms
personal page   ---->    http://www.ulster.net/~abigoo

From - Tue Dec 14 15:41:47 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id IAA27568
	for <slinkp@ulster.net>; Tue, 14 Dec 1999 08:33:59 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA23432 for linux-audio-dev-list; Tue, 14 Dec 1999 08:17:28 -0500
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA23429 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 14 Dec 1999 08:17:23 -0500
Received: from linuxhost.localdomain (ppp15.gardena.net [212.11.71.93])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id OAA15556;
	Tue, 14 Dec 1999 14:10:45 +0100
Received: from linuxhost.localdomain (localhost [127.0.0.1])
	by linuxhost.localdomain (8.9.3/8.9.3) with SMTP id PAA00980;
	Tue, 14 Dec 1999 15:10:49 +0100
From: Benno Senoner <sbenno@gardena.net>
To: Billy Biggs <vektor@DIV8.NET>,
        Linux Audio Dev <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] Silly audio problem
Date: Tue, 14 Dec 1999 15:03:41 +0100
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
Cc: Thomas Sailer <sailer@ife.ee.ethz.ch>
References: <19991213203142.A18934@div8.net>
MIME-Version: 1.0
Message-Id: <99121415104800.00736@linuxhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 931f35487c5ccb8430ff99b8e8c33eb2

On Tue, 14 Dec 1999, Billy Biggs wrote:
> Hi,
> 
>> 
>   I've got an ens1370 card (AudioPCI) and am using ALSA 0.4.1h (debian potato
> package).
> 
>   The problem is this:  The sound on the receiving end sounds really awful,
> then switches and sounds good for a while, but then sometimes falls back to
> sounding awful again.  The bass gets this big rumbling sound and it kinda
> sounds like it's clipping.  Definitely sounds chunky.
> 

I have a Soundblaster 128 PCI (1370) in my dual Celeron box, and I am
experiencing audio quality problems too:

This happens with the 2.2.12 kernel of RH 6.1 using the standard OSS drivers.
(no ALSA)

The sampled sound contains clicks at regular intervals but only in the left
channel and if the input level gets big enough, but without clipping. (I'm
using the microphone input).

I tried to sample some audio under win98 and the audio results perfect on both
channels.  (I used the soundrecorder of windoze)
I don't know if this is a problem related to fullduplex, I haven't tried to
sample in halfduplex mode.

But what is for sure is that my code isn't buggy
I only do
while(1)
{
  read() from /dev/dsp
  write() to /dev/dsp
}

(of course preloading the DAC with a full buffersize write() before entering
the while.
Any thoughts ?

Benno.

From - Tue Dec 14 15:41:50 1999
Received: from shell.nacs.net (IDENT:stutz@shell.nacs.net [207.166.192.99])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id PAA22398
	for <slinkp@ulster.net>; Tue, 14 Dec 1999 15:01:51 -0500
Received: from localhost (stutz@localhost)
	by shell.nacs.net (8.8.7/8.8.8) with ESMTP id PAA22716
	for <slinkp@ulster.net>; Tue, 14 Dec 1999 15:01:42 -0500
X-Authentication-Warning: shell.nacs.net: stutz owned process doing -bs
Date: Tue, 14 Dec 1999 15:01:42 -0500 (EST)
From: Michael Stutz <stutz@dsl.org>
X-Sender: stutz@shell.nacs.net
To: Paul Winkler <slinkp@ulster.net>
Subject: Re: [linux-audio-dev] Audio-Quality-HOWTO updated
In-Reply-To: <37EEE7E1.6F8DEB17@ulster.net>
Message-ID: <Pine.LNX.4.10.9912141501150.22541-100000@shell.nacs.net>
X-URL: http://dsl.org/
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 262cdf52ab02cca6c33e3bcd0b105c5c

Hey -- fyi the linart.net is up and ready. No Python though.

On Sun, 26 Sep 1999, Paul Winkler wrote:

> Michael Stutz wrote:
> > 
> > I know its been a while, want to keep you posted: I'm pretty sure python CGI
> > scripts will be ok; the site should be set up tonight and I should know for
> > sure then ...
> 
> Thanks!
> 
> I'm still not really ready to put it up, anyway. Been frightfully busy.
> 
> --PW
> 
> ----------------    paul winkler    ------------------
> slinkP arts:  music, sound, illustration, design, etc.
> 
> zarmzarm@hotmail.com   --or-- slinkp AT ulster DOT net
> http://www.ulster.net/~abigoo/
> ======================================================
> 

From - Thu Dec 16 11:51:02 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA04471
	for <slinkp@ulster.net>; Wed, 15 Dec 1999 17:19:09 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA29895 for linux-audio-dev-list; Wed, 15 Dec 1999 17:00:51 -0500
Received: from smtp.mail.yahoo.com (smtp.mail.yahoo.com [128.11.68.32]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id RAA29892 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 15 Dec 1999 17:00:47 -0500
Received: from modem31-cisco14.sinectis.com.ar (HELO yahoo.com) (216.244.200.31)
  by smtp.mail.yahoo.com with SMTP; 15 Dec 1999 13:54:16 -0800
X-Apparently-From: <luispagasparotto@yahoo.com>
Message-ID: <3857F78B.633E9B95@yahoo.com>
Date: Wed, 15 Dec 1999 17:18:20 -0300
From: Luis Pablo Gasparotto <luispagasparotto@yahoo.com>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>,
        Multisound <MultiSound@MAILLIST.VOYETRA.COM>,
        Red Hat List <redhat-list@redhat.com>
Subject: [linux-audio-dev] SLab & Sound Studio =?iso-8859-1?Q?don=B4t?= work with FIJI
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 5ef3d7798e5f0e69c40ceab68f117980

Hi all,

I have installed both Slab and Sound Studio multitrack recorders. But no
one works with my FIJI.

SLab: Unable to open audio device
Sound Studio: Operation not supported by device.

My FIJI is in /dev/dsp linked to /dev/dsp0.

I think that these programs uses /dev/audio/ but Im not sure.

SLab and Sound Studio seems to be great recorders. But I cant use
these.

What can I do to use these programs? Is there some other program like
SLab or Sound Studio for use with FIJI?

Thank you very much in advance.

Luis Pablo Gasparotto



__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one place.
Yahoo! Shopping: http://shopping.yahoo.com

From - Fri Dec 17 12:12:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA04924
	for <slinkp@ulster.net>; Fri, 17 Dec 1999 10:14:23 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA11141 for linux-audio-dev-list; Fri, 17 Dec 1999 09:46:37 -0500
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA11138 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 17 Dec 1999 09:46:32 -0500
Received: from smp.localnet.it (IDENT:root@[194.242.217.45])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id PAA15646;
	Fri, 17 Dec 1999 15:39:29 +0100
Received: from smp.localnet.it (IDENT:benno@localhost [127.0.0.1])
	by smp.localnet.it (8.9.3/8.9.3) with SMTP id OAA00815;
	Fri, 17 Dec 1999 14:45:15 +0100
From: Benno Senoner <sbenno@gardena.net>
To: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] mucos client/server implementation issues , I need opinions
Date: Fri, 17 Dec 1999 13:49:51 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: audiality@swipnet.se, benles@powernet.net
MIME-Version: 1.0
Message-Id: <99121714451502.00660@smp.localnet.it>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: eea3f3917e7a697e48b8afbe2cd986c0

Hi,
I am still seeking the best way to implement an efficient
low latency client/server API.

Of course getting as little latency as possible by using minimal
system ressources  is #1 requirement.

The API should be fullduplex, and allow a tree-like client/server
structure. That means every client can be the "server" of other clients.

My first design was to let the clients waken up by the server but the 
server not waiting for client.
I opted for this because it saves some syscalls on server side
( wait for message or semaphore)

This assumes that since the server plays one audio fragment at time,
the clients must have a round-trip time which is <fragment time.

Looking at the latency tests , I came to the conclusion that often we 
need more than 2 audio fragments in order to get reliable performance,
becaue the scheduler doesn't always guarantee that our process is
rescheduled in a time <fragment time.

For example using 3x128 audio buffers, sometimes 2 full buffers are utilized
making the above approach unusable.

An other issue is whether to use a pipelined approach or not,
that means introduce addtional latencies by adding buffers
(but not introducing addidional CPU load, because there is no memory ping-pong
copying).
The pipelined approach has the advantage that you can parallelize (run on
multiple CPUs) sequential datapaths since the audio is a data stream.
 (parallel datapaths can be parallelized anyway without pipelining)
It is very simple to implement in the case of one
single server and many clients at the same level.
for example:

client1  <---->-+
                         +---<----> server
client2  <---->-+

But IMHO this flat design is not flexible enough for us.

( David wants to feed his softsynth output into quasimodo and then send
the result to the mucos server, where at this moment an an external mp3 player
is sending his output too)


client1  <-------> client2 <------>--+
                                                            +--<-----> server
client3  <-------------------->--+


I think in order to avoid complex pipeline dependencies,
It would be better to use the not-pipelined approach.
I say this because the number of parallel datapaths in a common DAW enviroment
is often much greater that the number of CPUs. 

For example the data flow could be the following: ( we assume that server and
clients all to fullduplex audio)

SERVER:
-------
while(1)
{
  read() from soundcard into shared mem  // clients are able to read this data
  wakeup_clients()   // only direct clients that means only client2 and client1
  wait_for_clients()   // wait that the client2 and client3 finish the
  processing process()   // mixdown etc
  write() soundcard
  }
-----

CLIENT3:
-------
while(1)
{
  wait_for_server()
  process_data_from_shmem()
  write_data_to_shmem()
  wakeup_server()
}

CLIENT2:
---------
while(1)
{
  wait_for_server()
  pre_process_data()  // ie does some preprocessing for client's 1 input data
  wakeup_client1()  // wakes up client1 since client2 is the "server" of client1
  wait_for_client1()  // waits that client1 finishes the processing
  read_from_client1_shmem()
  post_process_data() // postprocess data returned by client1
  write_to_server_shm()
  wakeup_server()
}

CLIENT1:  (just like client3  but uses client2 as "server" )
-------
while(1)
{
  wait_for_client2()
  process_data_from_shmem()
  write_data_to_shmem()
  wakeup_client2()
}

Would such an approach be acceptable for you ?
any thoughts , ideas ?

To  allow audio data over network, be can simply introduce
an intermediate "client" between the server and the networked
clients, which takes care to do intermediate buffering in order to overcome to
the network latencies.

In the above example we have about 5-6 context switches per processing cycle:

server -> client2 -> client1 ->  client2 ->  client3 -> etc. ....

Of course it is to determine how low we can get latencies in order to get 100%
reliability.
I'm actually experienting with sem*() and msg*() but msg*() seems to give better
results than sem*() very strange.
But until I have no latency graphs I won't make any false claims.

Benno.

From - Sat Dec 18 12:40:39 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA11877
	for <slinkp@ulster.net>; Fri, 17 Dec 1999 18:10:57 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA11839 for linux-audio-dev-list; Fri, 17 Dec 1999 17:57:53 -0500
Received: from gauss.deltav.hu (gauss.deltav.hu [194.9.64.225]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA11836 for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 17 Dec 1999 17:57:49 -0500
Received: from boksi (116.dial02.deltav.hu [194.9.64.116])
          by gauss.deltav.hu (Netscape Messaging Server 3.6)  with ESMTP
          id AAA5931 for <linux-audio-dev@ginette.musique.umontreal.ca>;
          Fri, 17 Dec 1999 23:55:29 +0100
Received: from reactor by boksi with local (Exim 1.92 #1 (Debian))
	id 11z0IL-00008e-00; Fri, 17 Dec 1999 17:31:53 +0100
Message-ID: <19991217173153.A527@boksi>
Date: Fri, 17 Dec 1999 17:31:53 +0100
From: reactor/CTPmedia <reactor@sagv5.gyakg.u-szeged.hu>
To: LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] midi seq for ALSA
Reply-To: reactor <reactor@sagv5.gyakg.u-szeged.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91.2
Organization: CTP media laboratories
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: cb048788d0cddbd166e27b5027304ce4

yo!

as i see, you don't read the freshmeat-newsletter...
there's a new sequencer out there, called Melys:
http://www.parabola.demon.co.uk/melys/melys-0.1.13.tar.gz

ps: the ALSA sblive support is still only in the cvs, when
will it be released "normally"?

-- 

(reactor/CTPmedia) (http://linux.gyakg.u-szeged.hu/~reactor/index.html)
(linux audiowarez) (http://www.bright.net/~dlphilp/linuxsound/toc.html)

From - Sat Dec 18 12:40:50 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id IAA17310
	for <slinkp@ulster.net>; Sat, 18 Dec 1999 08:20:30 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA16816 for linux-audio-dev-list; Sat, 18 Dec 1999 08:07:21 -0500
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA16813 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 18 Dec 1999 08:07:16 -0500
Received: from smp.localnet.it (IDENT:root@[194.242.217.45])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id OAA01478;
	Sat, 18 Dec 1999 14:00:25 +0100
Received: from smp.localnet.it (IDENT:benno@localhost [127.0.0.1])
	by smp.localnet.it (8.9.3/8.9.3) with SMTP id OAA01583;
	Sat, 18 Dec 1999 14:03:09 +0100
From: Benno Senoner <sbenno@gardena.net>
To: benles@bldigital.com, Ben & Leslie Allfree <benles@powernet.net>
Subject: Re: [linux-audio-dev] mucos client/server implementation issues , I need opinions
Date: Sat, 18 Dec 1999 13:56:01 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <99121714451502.00660@smp.localnet.it> <385A821A.D12CFBF7@powernet.net>
In-Reply-To: <385A821A.D12CFBF7@powernet.net>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
MIME-Version: 1.0
Message-Id: <99121814030801.01232@smp.localnet.it>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 8e199216456065412ef2674a2d99c7e2

On Fri, 17 Dec 1999, Ben & Leslie Allfree wrote:
> > The API should be fullduplex, and allow a tree-like client/server
> > structure. That means every client can be the "server" of other clients.
> 
> What about requiring some kind of IP-multicast hub for optimal functionality? Then
> nobody has to be a server except for their own data. If IP-multicast is not enabled,
> then yes, I think a tree-like broadcast algorithm is the fastest way to do an
> all-to-all broadcast. However, consider the topology of a tree-like network. It
> means buying special hardware, so why not just go with IP-multicast at that point?
> IMHO, most people will probably have a bus or star topology if they have not
> purchased special hubs.

yes IP multicast is not a bad idea,
but I was mainly talking about multiple clients (processes) inside of one box.
but of course shared memory is "multicast capable", for example I have the
server sampling the data from the soundcard,
ad n clients (on the same box) can read the data from shmem in parallel.

> 
> Also, I wonder about shared memory. Shared memory has high overhead and is highly
> dependent on network bandwidth; is it necessary for this application?. Why can't
> clients just send or request data as message packets from other clients?

Of course: I was talking about shmem only for local clients, remote clients
will use some suitable network protocol.
There will be an intermediate "network server" which will communicate with other
"network clients" taking care of buffering etc.

Multicast works for clients on the same level, but often you have
interdependencies therefore for optimal performance you must use a mix of
multicast and single cast.

Benno.


> 
> Take care,
> 
> Ben

From - Sat Dec 18 19:15:45 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA15259
	for <slinkp@ulster.net>; Sat, 18 Dec 1999 18:57:36 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA17647 for linux-audio-dev-list; Sat, 18 Dec 1999 18:40:15 -0500
Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA17644 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 18 Dec 1999 18:40:09 -0500
Received: from d1o43.telia.com (d1o43.telia.com [194.22.195.241])
	by mailg.telia.com (8.9.3/8.9.3) with ESMTP id AAA12083
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 19 Dec 1999 00:33:30 +0100 (CET)
Received: from norran.net (roger@t3o43p59.telia.com [194.22.195.179])
	by d1o43.telia.com (8.8.8/8.8.8) with ESMTP id AAA00946
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 19 Dec 1999 00:33:27 +0100 (CET)
Message-ID: <385C21C3.F7643CBB@norran.net>
Date: Sun, 19 Dec 1999 01:07:31 +0100
From: Roger Larsson <roger.larsson@norran.net>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] mucos client/server implementation issues , I need 
 opinions
References: <99121714451502.00660@smp.localnet.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 38841abaf8f581402d70636abf0c2fb6

Benno Senoner wrote:
> 
> Hi,
> I am still seeking the best way to implement an efficient
> low latency client/server API.
> 
> Of course getting as little latency as possible by using minimal
> system ressources  is #1 requirement.
> 
ok!

> The API should be fullduplex, and allow a tree-like client/server
> structure. That means every client can be the "server" of other clients.
>
ok,
if by fullduplex you mean to/from audio board(s)/HDs...
 
> My first design was to let the clients waken up by the server but the
> server not waiting for client.
> I opted for this because it saves some syscalls on server side
> ( wait for message or semaphore)
> 
> This assumes that since the server plays one audio fragment at time,
> the clients must have a round-trip time which is <fragment time.
> 
> Looking at the latency tests , I came to the conclusion that often we
> need more than 2 audio fragments in order to get reliable performance,
> becaue the scheduler doesn't always guarantee that our process is
> rescheduled in a time <fragment time.
> 
> For example using 3x128 audio buffers, sometimes 2 full buffers are utilized
> making the above approach unusable.
> 
> An other issue is whether to use a pipelined approach or not,
> that means introduce addtional latencies by adding buffers
> (but not introducing addidional CPU load, because there is no memory ping-pong
> copying).
> The pipelined approach has the advantage that you can parallelize (run on
> multiple CPUs) sequential datapaths since the audio is a data stream.
>  (parallel datapaths can be parallelized anyway without pipelining)
> It is very simple to implement in the case of one
> single server and many clients at the same level.

by pipelined do you mean - using a pipe?
I have been playing with that idea for communication in the large.
(Not plugin -> plugin, but engines to engines)

I am currently looking at the kernel code. 
[There might be a SMP read/write race there with a half full buffer,
 unless it is looked on a higher level (2.2.13).
 PIPE_LOCK is tested in one place, but incremented in another...
 both read and write then updates PIPE_LEN...]

There is an issue with data copy. From user memory to system and
later from system to user.
But I think it should be ok when not used between every plugin.

There is also the possibility to introduce a new file system device,
pipe_isocronous(sic? I mean stuff like speech, video, ...).
If blocking on write until a read process enters, and requiring
that the data sizes are the same you should be able to copy directly
user process to user process. I am not sure if this would be a win
or not but you would not need to do some file system checks.

> for example:
> 
> client1  <---->-+
>                          +---<----> server
> client2  <---->-+
> 
> But IMHO this flat design is not flexible enough for us.
> 
> ( David wants to feed his softsynth output into quasimodo and then send
> the result to the mucos server, where at this moment an an external mp3 player
> is sending his output too)

Ahh, each client/plugin has only two pipes... That would be a problem...
But if the engine assigns pipes?

> 
> client1  <-------> client2 <------>--+
>                                                             +--<-----> server
> client3  <-------------------->--+
> 
> I think in order to avoid complex pipeline dependencies,
> It would be better to use the not-pipelined approach.
> I say this because the number of parallel datapaths in a common DAW enviroment
> is often much greater that the number of CPUs.
>
Very true today. But since processor constructors are battling with too
much silicon
space, things might change (cache takes a lot of space and may not be
the most
efficient usage of the space, hit rates can only improve marginally):

- multiple CPUs on one chip
- multiple register files on one CPU chip, allows task switching while
waiting
  for cache miss...
- ...
- use all of above 
  [if I remember correctly SUN is designing a new architecture with four
execution
   units (4*full(fp+int)) times four register files times four
processors and it
   can expand to any number of processors/register files]

> For example the data flow could be the following: ( we assume that server and
> clients all to fullduplex audio)
> 
> SERVER:
> -------
> while(1)
> {
>   read() from soundcard into shared mem  // clients are able to read this data
>   wakeup_clients()   // only direct clients that means only client2 and client1
>   wait_for_clients()   // wait that the client2 and client3 finish the
>   processing process()   // mixdown etc
>   write() soundcard
>   }
> -----
> 
> CLIENT3:
> -------
> while(1)
> {
>   wait_for_server()
>   process_data_from_shmem()
>   write_data_to_shmem()
>   wakeup_server()
> }
> 
> [more code deleted]
> 
> Would such an approach be acceptable for you ?
> any thoughts , ideas ?
> 
> To  allow audio data over network, be can simply introduce
> an intermediate "client" between the server and the networked
> clients, which takes care to do intermediate buffering in order to overcome to
> the network latencies.
> 
> In the above example we have about 5-6 context switches per processing cycle:
> 
> server -> client2 -> client1 ->  client2 ->  client3 -> etc. ....

But shouldn't we be able to do a lot better than that?

Suppose you have a server/engine that loads plugins as shared libraries
(DLL)
and makes a table of the script/drawn scheme/... of how the plugins are
connected, then it can call each plugin JIT, no context switches! no
need
to do 'wait_for_...', no need to know that the memory is shared - it can
local, you only get the pointer.

Or it could be a simple engine that only handles one plugin, that is
loaded by
specifying a command line option - then you get one process per plugin.

Or it could be a multi-instance-multithreaded-engine a mix between the
two -
you may start as many engines as you like. In your user process, in a
daemon,
as a kernel thread, as a RT-Thread.

Each engine handles zero-to-infinite(well almost) numbers of threads
(workers).

Workers run zero-to-infinite numbers of tightly connected plugins, and
you will
always have some plugins that makes sense to tightly connect. But this
could
be handled by the engine.

The problem I have with your code are:
* that it requires one thread per plugin-instance 'while(1) {...}'

* that clients all the time has to request services from the engine,
instead
  of the engine scheduling stuff in a way that data is available when
run and
  ensuring that plugins are not run in an interfering way. [repetitive]


== Something about "trial API" ==

Yes, it is still very possible to run that code on a multi processor
computer
where each plugin-instance has its own process all executing
concurrently
(since my trial uses double buffering). But that is up to the
engine/user
to specify - it is not a question for each plugin.

I am currently cleaning up the code even more, and since the engine is
currently
missing it is hard for outsiders to see what it would look like, at some
times
it is even hard for me :-).

It could in fact be self powered. Upon returning from a 'process-call'
the worker could check if 
a 'connection' has used up its current signal space (read or written to)
and forward it to were it should be used next (forwarding is done by
swapping
buffer pointers, or signal pointers). If you need to communicate
externally
it is handled by another plugin, see 'plugin_charStdin/out' (renames are
in the pipe TODO, it could nowadays be used to read from any file, even
devices :-)

BTW; I am considering moving away from events as a special signal type
that
can affect the whole module and its different signals as well. See the
'plugin_offset' and its offset. (plugin_offset is basically an add/mix)

Instead I am looking at using different sample frequencies to handle
stuff like that.
offset could be a signal with a sample frequency of:
* A constant value / parameter has zero sample frequency.
* A UI knob is sampled at least with 2 Hz, maybe 10 Hz (100 ms)
* A signal from another audio plugin is probably at least 8000 Hz.
But note that the source to this all these signal types
can be generated by another plugin (or rather several other types of).

Note: that a plugin may alter its 'process' call for efficient
 handling the different types of signals. And then only check if it
 still gets that type of signal.

(A plugin may convert MIDI messages to tone signal + envelope signal
for as many signal pairs you like to have polyphonic signals. This
could be in the table, but the )

> Of course it is to determine how low we can get latencies in order to get 100%
> reliability.
> I'm actually experienting with sem*() and msg*() but msg*() seems to give better
> results than sem*() very strange.
> But until I have no latency graphs I won't make any false claims.


What about signals? You only need to wait. Then when the signal arrives
you check that it is the expected signal - that is all. The wait has
been
cancelled and the program continues.
(Note that Ingo has recently patched a latency bug in this area...)

/RogerL


--
Home page:
  http://www.norran.net/nra02596/

From - Mon Dec 20 02:04:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id AAA10740
	for <slinkp@ulster.net>; Sun, 19 Dec 1999 00:02:37 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA18047 for linux-audio-dev-list; Sat, 18 Dec 1999 23:48:11 -0500
Received: from renoir.op.net (renoir.op.net [207.29.195.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA18044 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 18 Dec 1999 23:48:09 -0500
Received: from someip.ppp.op.net (d-bm2-13.ppp.op.net [209.152.194.51]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id XAA27129 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sat, 18 Dec 1999 23:39:49 -0500 (EST)
Message-Id: <199912190439.XAA27129@renoir.op.net>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] mucos client/server implementation issues , I need opinions 
In-reply-to: Your message of "Sun, 19 Dec 1999 01:07:31 +0100."
             <385C21C3.F7643CBB@norran.net> 
Date: Sat, 18 Dec 1999 23:39:51 -0500
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 8f8dc078f4706ff9adc4c64f28189703

>ok,
>if by fullduplex you mean to/from audio board(s)/HDs...

i think benno said that he means fullduplex in the sense that clients
can talk to each other - any client can be a server, and vice versa.

>by pipelined do you mean - using a pipe?
>I have been playing with that idea for communication in the large.
>(Not plugin -> plugin, but engines to engines)

you can't use pipes for high quality audio. they don't hold enough
data (5K) to be useful across more than 1 context switch, and
sometimes not even that (depending on the sample rate and sample
size).

>But shouldn't we be able to do a lot better than that?
>
>Suppose you have a server/engine that loads plugins as shared libraries
>(DLL)
>and makes a table of the script/drawn scheme/... of how the plugins are
>connected, then it can call each plugin JIT, no context switches! no
>need
>to do 'wait_for_...', no need to know that the memory is shared - it can
>local, you only get the pointer.

this was discussed during the mammoth API flood between David and
myself. We want a system that supports both plugins and inter-task
communication, and easily allows code used for one to be reused for
the other. In some cases (many) the plugin system makes more
sense. But for some things, its nicer to have things instantiated as
separate tasks (processes). the MuCOS API is supposed to support both.

>Instead I am looking at using different sample frequencies to handle
>stuff like that.
>offset could be a signal with a sample frequency of:
>* A constant value / parameter has zero sample frequency.
>* A UI knob is sampled at least with 2 Hz, maybe 10 Hz (100 ms)
>* A signal from another audio plugin is probably at least 8000 Hz.
>But note that the source to this all these signal types
>can be generated by another plugin (or rather several other types of).

this is basically what Csound and most subsequent systems have
done. The Nord modular samples control signals at 24KHz, but uses
48KHz for audio data. Csound and SAOL (and Quasimodo) let you specify
the sample rates for both data types independently.

also, from my own experience, you should not even begin to pay
attention to the existence of a UI. the UI system (X, Windows,
whatever) will provide whatever "sampling" rate it can (based on mouse
motion interrupts, for example) - the internals of the system should
not try to second guess this. 

don't get too caught up in the rates stuff. i recently wrote a long
memo to the SAOL guys about rate stuff - its a definite win to have it
as a concept in a system, but I think that both Csound and even more
so SAOL have confused a semantic entity with something that *must* be
mirrored in the implementation. I feel confident based on my work with
Quasimodo and the Csound opcodes in saying that this is not
true. SAOL, for example, will absolutely not allow the following kind
of expression:

   if (control_signal < audio_signal) 
         audio_signal = value;
      
the complaint will be that the value of the conditional takes the
lowest rate of its elements, and the body cannot have a rate greater
than that of the conditional. Ack. C and C++ let you do this just
fine, and so should a sound synthesis/processing language.

--p

From - Mon Dec 20 02:04:42 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA02228
	for <slinkp@ulster.net>; Sun, 19 Dec 1999 06:49:38 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA22260 for linux-audio-dev-list; Sun, 19 Dec 1999 06:33:28 -0500
Received: from em.gardena.net ([212.11.71.70]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA22257 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 19 Dec 1999 06:33:22 -0500
Received: from smp.localnet.it (IDENT:root@[194.242.217.45])
	by em.gardena.net (8.9.1/8.9.0) with ESMTP id MAA20028;
	Sun, 19 Dec 1999 12:26:30 +0100
Received: from smp.localnet.it (IDENT:benno@localhost [127.0.0.1])
	by smp.localnet.it (8.9.3/8.9.3) with SMTP id MAA01329;
	Sun, 19 Dec 1999 12:29:12 +0100
From: Benno Senoner <sbenno@gardena.net>
To: Roger Larsson <roger.larsson@norran.net>,
        "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] mucos client/server implementation issues , I need opinions
Date: Sun, 19 Dec 1999 11:58:21 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <99121714451502.00660@smp.localnet.it> <385C21C3.F7643CBB@norran.net>
In-Reply-To: <385C21C3.F7643CBB@norran.net>
MIME-Version: 1.0
Message-Id: <99121912291200.00766@smp.localnet.it>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 04c6c06ba28ffa2cb2733454ad99c087

On Sun, 19 Dec 1999, Roger Larsson wrote:
> > The API should be fullduplex, and allow a tree-like client/server
> > structure. That means every client can be the "server" of other clients.
> >
> ok,
> if by fullduplex you mean to/from audio board(s)/HDs...

By fullduplex I mean that every process can talk each other in both directions,
that means that every client can read and write data to his "server".
That leads to a flexible enviroment, since you can let pre-process and
post process data to a tree of interdependent clients.
Not always needed but somewhere very useful


> > An other issue is whether to use a pipelined approach or not,
> > that means introduce addtional latencies by adding buffers
> > (but not introducing addidional CPU load, because there is no memory ping-pong
> > copying).
> > The pipelined approach has the advantage that you can parallelize (run on
> > multiple CPUs) sequential datapaths since the audio is a data stream.
> >  (parallel datapaths can be parallelized anyway without pipelining)
> > It is very simple to implement in the case of one
> > single server and many clients at the same level.
> 
> by pipelined do you mean - using a pipe?
> I have been playing with that idea for communication in the large.
> (Not plugin -> plugin, but engines to engines)

no by pipelined approach I don't mean using pipes (unix fifos etc),
but using one or more intermediate buffers in order to parallelize operations.
That means during a simple clients/server communication the clients
doesn't wait that the server samples his  audio fragment,
but uses the previous buffered fragment (in the startup case the
intermediate buffer is zero filled).
It increases latency by one or more fragments but makes the 
buffer interdependency in a tree-like structure quite complex.

But as stated before since our DAW enviroment is composed of
many parallel paths, even with my proposed approach
there are enough parallel paths to be easily parallelized.

> 
> > for example:
> > 
> > client1  <---->-+
> >                          +---<----> server
> > client2  <---->-+
> > 
> > But IMHO this flat design is not flexible enough for us.
> > 
> > ( David wants to feed his softsynth output into quasimodo and then send
> > the result to the mucos server, where at this moment an an external mp3 player
> > is sending his output too)
> 
> Ahh, each client/plugin has only two pipes... That would be a problem...
> But if the engine assigns pipes?

clients and server do not talk each other through pipes but only shared mem.
shared mem = zero copy overhead, and with several clients running
you can save quite a bit of bandwidth.

> > In the above example we have about 5-6 context switches per processing cycle:
> > 
> > server -> client2 -> client1 ->  client2 ->  client3 -> etc. ....
> 
> But shouldn't we be able to do a lot better than that?

you missed the point .. keep reading below  :-)

> 
> Suppose you have a server/engine that loads plugins as shared libraries
> (DLL)
> and makes a table of the script/drawn scheme/... of how the plugins are
> connected, then it can call each plugin JIT, no context switches! no
> need
> to do 'wait_for_...', no need to know that the memory is shared - it can
> local, you only get the pointer.
> 
> Or it could be a simple engine that only handles one plugin, that is
> loaded by
> specifying a command line option - then you get one process per plugin.
> 
> Or it could be a multi-instance-multithreaded-engine a mix between the
> two -
> you may start as many engines as you like. In your user process, in a
> daemon,
> as a kernel thread, as a RT-Thread.

The goal of the client/server implementation is to provide
interapplication communication, not inter-plugin communication.

Of course we run an app which hosts 20 plugins in one single
thread (or in order to take advantage of SMP in 2-4 threads).

But my goal is to let separate audio apps communicate each other
in realtime, with as little as latency possible.

Assume you have a softsynth which doesn't give you the possibility
to run as plugin of another app.
Assume you want to record the softsynth output in your HD recording app.

With my proposed client/server model, the softsynth sees a virtual
audio device where it can write the data to, and the HDrecorder
records from this audio device with as low as possible latency.


> 
> The problem I have with your code are:
> * that it requires one thread per plugin-instance 'while(1) {...}'

Yes this is because you misinterpreted that the client/server runs
every plugin in a separate thread.

No, just as Paul pointed out is a mix of both:

assume there are a few  monolithic apps running:
softsynth , HD recorder , FX rack.
Each app runs a set on plugins in his own thread,
but the 3 apps communicate through the client/server API,
in "real-time".

This approach lets integrate even old binary-only (through
LD_PRELOAD wrapper) apps into Mucos.

Of course the recommendation is to use a number of threads
as little as possible.
That means if an app can act as plugin, the "master" should
run the "plugin" in his thread in order to minimize scheduling overhead.
But sometime this isn't possible or desired.
And here the client/server approach comes handy.

I hope that the concepts are a bit clearer.
(sorry for my superficial explanations  :-) )

Anyone that disagrees with my ideas.


> (Note that Ingo has recently patched a latency bug in this area...)

do you have the BH (botton half) patch ?
maybe this will even cut down latency further, because it might eliminate
the peaks of  fragmentsize len)

Benno.

From - Mon Dec 20 02:04:45 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA18184
	for <slinkp@ulster.net>; Sun, 19 Dec 1999 10:36:51 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA22488 for linux-audio-dev-list; Sun, 19 Dec 1999 10:25:55 -0500
Received: from nic.funet.fi (nic.funet.fi [193.166.0.145]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA22485 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 19 Dec 1999 10:25:53 -0500
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S28982AbPLSPS6>; Sun, 19 Dec 1999 17:18:58 +0200
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Cool synth patches?
Message-Id: <19991219151909Z28982-5344+1176@nic.funet.fi>
Date:   Sun, 19 Dec 1999 17:18:58 +0200
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: b045992f274eb8ebddc2becbece06de1

Hello. In writing dsp functions/effects I find it a major problem that
I don't know how to exactly make 303, razors, vocal sounds, etc. found
from synths and which would be great in testing if the effects works
correctly. Recently, I tried to get info on how Kurzweil's Talk Talk sound
is made so that I could tune my filters etc., but no hope.

The irony is that getting information on the patch/sound in a synth
is the easiest part of the whole process if you own a synth. Now it is
the most difficult part of the process because I don't have any synths
and I actually don't know how to make cool sounds.

If anyone is interested in to have a text describing in detail some
cool sounds, then that would be great. We should document the algorithm
of the instrument, what oscillators are and how they are changing
within the time, what filters are and how they are changing within time.
The detailed information seems to be must, but once done, everybody can
use them to test their system, I believe. Naturally we should have
a recorded version of the sound as it comes from the particular synth.

Specially I'm interested in Kurzweil's Talk Talk sound and Novation
Supernova's "razor" sounds as found from ChatDemo (www.novationusa.com).
But anything interesting from any synth, analog or digital, would be
great.

Are there any guides on how to build great sounds available from net
or bookshop?

Yours,

Juhana

From - Mon Dec 20 02:04:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA00653
	for <slinkp@ulster.net>; Sun, 19 Dec 1999 18:32:06 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA22988 for linux-audio-dev-list; Sun, 19 Dec 1999 18:18:53 -0500
Received: from sreal.and.av.com ([205.229.83.46]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA22985 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 19 Dec 1999 18:18:51 -0500
From: div@sreal.and.av.com
Received: from localhost (div@localhost)
	by sreal.and.av.com (8.9.3/8.9.3) with ESMTP id SAA01655;
	Sun, 19 Dec 1999 18:58:59 -0500
Date: Sun, 19 Dec 1999 18:58:58 -0500 (EST)
To: Juhana Sadeharju <kouhia@nic.funet.fi>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Cool synth patches?
In-Reply-To: <19991219151909Z28982-5344+1176@nic.funet.fi>
Message-ID: <Pine.LNX.4.10.9912191641320.1575-100000@sreal.and.av.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 447f8b11fd743c3a62ace52470012de4

On Sun, 19 Dec 1999, Juhana Sadeharju wrote:

> Are there any guides on how to build great sounds available from net
> or bookshop?

Hi Juhana --

   Most of the "synthetic" sounds (ie: not trying to imitate real-world
instruments) were created by more-or-less random experimentation from
what I've heard.  

   If you don't have a synth but would like a flexible tool for doing 
this type of experimentation, you might want to try the program called 
Ein (short for Ein Kleine Filter Editor) from Princeton.  A very good book 
to go along with it is "A Digital Signal Processing Primer" by Ken Steiglitz, 
the same guy who wrote the program.  Don't necessarily take my word for
it though; I'm biased, since he was my professor, and we used Ein in class.
However, the program is free, and has been ported to Linux.  

Div.

P.S.  Yes, I've been missing from the list for a number of months, but
I finally got access to my email again.  Thank goodness the heated discussion
about what's now called MUCOS died down a little; it would have overrun my
quota if we continued to get a hundred messages per week!

   In case anyone is curious as to what I've been doing, I've halted work
on Songpad, and transferred my effort to a new project I'm calling Pegs
(Portable Event Graphing System).  Like Songpad, Pegs is a sequencer, but
it has two very important fundamental differences.  

   First, Pegs is only half of what is traditionally called a sequencer, 
the part which displays and edits events.  It relies on a separate sequencing 
engine like ALSAseq or MUCOS to handle the realtime recording and playback.  
This lets me concentrate on the stuff I enjoy without duplicating the effort
of those other fine projects.  It helps with portability too.

   Second, Pegs has no built-in notions of what are the properties of an 
event, nor how to display it.  Instead, Pegs provides display primatives
that the user hooks up to events via callbacks written in a scripting 
language (remember I said that the realtime stuff is handled separately).  
This means it is not limited to MIDI, but can also handle CSound or any 
other event-based system you can think of. 

   I'm making nice headway on Pegs (believe it or not, it's a lot simpler
than Songpad), but it's still not ready for its first release.  Besides,
I temporarily lost my website, and haven't yet arranged another place to
provide downloads.  I'll keep everybody posted, though.


     ("`-''-/").___..--''"`-._
      `6_ 6  )   `-.  (     ).`-.__.`)        ---== David Slomin ==---
      (_Y_.)'  ._   )  `._ `. ``-..-'
    _..`--'_..-_/  /--'_.' ,'           mailto:dgslomin@alumni.princeton.edu
   (il),-''  (li),'  ((!.-'       http://patriot.altavista-software.com/~div

From - Mon Dec 20 02:04:59 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA21480
	for <slinkp@ulster.net>; Sun, 19 Dec 1999 21:26:37 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA23214 for linux-audio-dev-list; Sun, 19 Dec 1999 21:16:28 -0500
Received: from hme0.smtp04.sprint.ca (hme0.smtp04.sprint.ca [207.107.250.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA23211 for <linux-audio-dev@ginette.musique.umontreal.ca>; Sun, 19 Dec 1999 21:16:25 -0500
Received: from vektor.div8.net (root@spc-isp-ktc-uas-8-66.sprint.ca [209.148.133.117])
	by hme0.smtp04.sprint.ca (8.8.8/8.8.8) with ESMTP id VAA12684;
	Sun, 19 Dec 1999 21:09:38 -0500 (EST)
Received: by div8.net
	via sendmail from stdin
	id <m11zqea-000965C@vektor.div8.net> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Sun, 19 Dec 1999 19:26:20 -0500 (EST) 
Date: Sun, 19 Dec 1999 19:26:20 -0500
From: Billy Biggs <vektor@DIV8.NET>
To: div@sreal.and.av.com
Cc: Juhana Sadeharju <kouhia@nic.funet.fi>,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Cool synth patches?
Message-ID: <19991219192619.A8166@div8.net>
References: <19991219151909Z28982-5344+1176@nic.funet.fi> <Pine.LNX.4.10.9912191641320.1575-100000@sreal.and.av.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <Pine.LNX.4.10.9912191641320.1575-100000@sreal.and.av.com>; from div@sreal.and.av.com on Sun, Dec 19, 1999 at 06:58:58PM -0500
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 2bb404871e0a3839e1b7e175399dd8ec

div@sreal.and.av.com (div@sreal.and.av.com):

>    Most of the "synthetic" sounds (ie: not trying to imitate real-world
> instruments) were created by more-or-less random experimentation from
> what I've heard.  

  Sure it's through experimentation, but usually within a certain set of
parameters.  If I sit down at a synth to create a lush pad sound, I can usually
do it.  And given a set pf parameters a synth lets me edit, I can usually think
of what sorts of sounds I could make.

  If you're looking to learn how to create sounds, it is difficult to figure it
all out without being able to hear your changes in realtime.  However, what you'd
want to look for would be articles or books on different types of synthesis.

  Interesting forms of sound synthesis would be:
    - Analog synthesis (old synths, and now lots of new digital emulations)
    - FM synthesis (like an Adlib card.. or an old DX7)
    - Additive synthesis (really strange, maybe you can find a Kawai K5 cheap)

  There doesn't seem to be many good softsynths for Linux though, but fear not,
since there aren't many good softsynths anywhere.  The best way to learn about
synthesis is to buy a synth, and preferably one that's good for editing.

-- 
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

From - Mon Dec 20 12:15:02 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA26647
	for <slinkp@ulster.net>; Mon, 20 Dec 1999 07:27:01 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id HAA27908 for linux-audio-dev-list; Mon, 20 Dec 1999 07:13:25 -0500
Received: from nic.funet.fi (nic.funet.fi [193.166.0.145]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA27905 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 20 Dec 1999 07:13:23 -0500
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S42345AbPLTKjb>; Mon, 20 Dec 1999 12:39:31 +0200
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <19991219192619.A8166@div8.net> (message from Billy Biggs on Sun,
	19 Dec 1999 19:26:20 -0500)
Subject: Re: [linux-audio-dev] Cool synth patches?
References: <19991219151909Z28982-5344+1176@nic.funet.fi> <Pine.LNX.4.10.9912191641320.1575-100000@sreal.and.av.com> <19991219192619.A8166@div8.net>
Message-Id: <19991220103942Z42345-5344+1235@nic.funet.fi>
Date:   Mon, 20 Dec 1999 12:39:31 +0200
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 3a87007954f0cf89fcc7704018dfec6a

Hello. Thank you for the replies so far. I will check if I find books
but so far I have found only books which tells how synths works but
not how to make cool razor (or any) sounds, for example.

I actually have a plenty of user manuals for synths found from the net.
They tell what is inside the synth but they don't tell preset's parameters.
Useful for making emulators... sure.

I remember as teenager we went to local shop to play with DX7 but the sounds
we made were absolute grap. Maybe I'm able to tweak parameters of soft
synths but I think I don't get it that good as some professional person.
And, maybe one reason would be that soft synths have poor filters or such;
I really don't know it because my Csound has no preset sounds at all!
Would Csound be able to produce commercial quality sounds? Were from
I could obtain preset sounds? I have some very simple sounds but nothing
great; 303 sounds nothing like Supernova.

Yours,

Juhana

From - Mon Dec 20 12:14:56 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA24730
	for <slinkp@ulster.net>; Mon, 20 Dec 1999 06:55:59 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA27848 for linux-audio-dev-list; Mon, 20 Dec 1999 06:35:18 -0500
Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA27845 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 20 Dec 1999 06:35:14 -0500
Received: from d1o43.telia.com (d1o43.telia.com [194.22.195.241])
	by mailg.telia.com (8.9.3/8.9.3) with ESMTP id MAA12936
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 20 Dec 1999 12:28:30 +0100 (CET)
Received: from norran.net (roger@t3o43p37.telia.com [194.22.195.157])
	by d1o43.telia.com (8.8.8/8.8.8) with ESMTP id MAA23346
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 20 Dec 1999 12:28:27 +0100 (CET)
Message-ID: <385E18F5.191C6D28@norran.net>
Date: Mon, 20 Dec 1999 12:54:29 +0100
From: Roger Larsson <roger.larsson@norran.net>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
MIME-Version: 1.0
CC: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] mucos client/server implementation issues , I need 
 opinions
References: <99121714451502.00660@smp.localnet.it> <385C21C3.F7643CBB@norran.net> <99121912291200.00766@smp.localnet.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: ccc8057e945df2b081dae89231d17f85

Benno Senoner wrote:
> 
> On Sun, 19 Dec 1999, Roger Larsson wrote:
> > > The API should be fullduplex, and allow a tree-like client/server
> > > structure. That means every client can be the "server" of other clients.
> > >
> > ok,
> > if by fullduplex you mean to/from audio board(s)/HDs...
> 
> By fullduplex I mean that every process can talk each other in both directions,
> that means that every client can read and write data to his "server".
> That leads to a flexible enviroment, since you can let pre-process and
> post process data to a tree of interdependent clients.
> Not always needed but somewhere very useful
>
ok
 
> > > [ - - - ]
> >
> > by pipelined do you mean - using a pipe?
> > I have been playing with that idea for communication in the large.
> > (Not plugin -> plugin, but engines to engines)
> 
> no by pipelined approach I don't mean using pipes (unix fifos etc),
> but using one or more intermediate buffers in order to parallelize operations.
> That means during a simple clients/server communication the clients
> doesn't wait that the server samples his  audio fragment,
> but uses the previous buffered fragment (in the startup case the
> intermediate buffer is zero filled).
> It increases latency by one or more fragments but makes the
> buffer interdependency in a tree-like structure quite complex.

Does it really (have to) increase latency by one fragment???

The process that samples data will take its time but does it mean
that that is what have to drive the other processess to take another
turn? (I use my terms since I am not really sure what Bennos server
stands for)

unit->A->B->C->unit

A samples
B waits
C waits

A has got a fragment.
A writes to shared mem and notifies the engine.

engine swaps buffers between A and B
engine can now run A and B (A with empty buffer and B with data)

A samples
B calculates
C waits

B finishes its calculation and notifies the engine.

engine swaps buffers between B and C
engine can now run C (C has data but Bs buffer is empty)

A still samples second buffer is not full yet.
B waits
C outputs first buffer

A has a 'processing' time of 'tfA' for every buffer
C has a 'processing' time of 'tfC' for every buffer.
B has a processing time of tB(n) since the processing time
  might vary depending on data received.

Note: tfA == tfC

And all works well as long as tB(n) <= max(tB(0:n-1))

Since C started at tfA + tB(0)
And requires more data at every
 tfA + tB(0) + n*tfC

C would have to wait for data, with slips, if tB(x) gets
bigger than tB(0). After that slip C will need data at
 tfA + tB(x) + n*tfC

But any approach will have the same problem. And it has
to be delt with.

[ Even a simple
while (1)
{
  read(...)
  process(...)
  write(...)
}
Will get into serious trouble if process will take different
time to run depending on the processed data. ]


As you can see this is my trial plugin API again running at a
larger scale :->

This is a user(!) process (lets call it U) running a engine
with plugins to support communication with a audio app
(lets call it Q :-) written by someone else. And depending
on how well behaved that app is there are several alternative
plugins.

1) Communicating via a loopback device that present itself as
    /dev/dsp and or /dev/audio for Q
   using loopback-device-plugin in U

2) Communicating via an alternative device, configuring Q to
   use it.
   using alternative-device-plugin in U.

3) Communication via generic plugin support in Q, having
   a script that uses a generic-peer-plugin.
   using a generic-peer-plugin in U.

4) Communicating via any of Qs supported external interfaces,
   using a special-Q-interface-plugin in U.

5) Loading Qs calculation part as any other plugin.
   using Q-plugin in U.

> > > [communication application to application deleted]
> > > 
> > > In the above example we have about 5-6 context switches per processing cycle:
> > >
> > > server -> client2 -> client1 ->  client2 ->  client3 -> etc. ....
> >
> > But shouldn't we be able to do a lot better than that?
> 
> you missed the point .. keep reading below  :-)

Yes, I realized that a little to late. After turning my computer off and
almost
at sleep in my bed :-)

> 
> >
> > Suppose you have a server/engine that loads plugins as shared libraries
> > (DLL)
> > and makes a table of the script/drawn scheme/... of how the plugins are
> > connected, then it can call each plugin JIT, no context switches! no
> > need
> > to do 'wait_for_...', no need to know that the memory is shared - it can
> > local, you only get the pointer.
> >
> > Or it could be a simple engine that only handles one plugin, that is
> > loaded by
> > specifying a command line option - then you get one process per plugin.
> >
> > Or it could be a multi-instance-multithreaded-engine a mix between the
> > two -
> > you may start as many engines as you like. In your user process, in a
> > daemon,
> > as a kernel thread, as a RT-Thread.
> 
> The goal of the client/server implementation is to provide
> interapplication communication, not inter-plugin communication.
> 
> Of course we run an app which hosts 20 plugins in one single
> thread (or in order to take advantage of SMP in 2-4 threads).

And if your computer has 128 processors...
The engine need to be configurable to be able to USE your hardware...

> 
> But my goal is to let separate audio apps communicate each other
> in realtime, with as little as latency possible.
> 
> Assume you have a softsynth which doesn't give you the possibility
> to run as plugin of another app.
> Assume you want to record the softsynth output in your HD recording app.
> 
> With my proposed client/server model, the softsynth sees a virtual
> audio device where it can write the data to, and the HDrecorder
> records from this audio device with as low as possible latency.
>

Yes, but the softsynt will need to support a "virtual audio device".
Will it be as easy as opening "/dev/virtual_dsp" instead of
"/dev/dsp" then any softsynt programmer will support it in weeks.
But suppose there would be a lot more to do...

If there is a driver that intercept the standard /dev/dsp and loops
it back into shared memory, it would be ok. But you get one copy
that you can not get rid of. (only one copy is quite good, BTW  :-)

But I still think that a pipe-file approach could have its merits, if
you want to connect two none shared memory avare applications.
(The 'ioctl' will be different. Or not, with a special pipe-fs...)

You basically has these choices (as a writer of an audio app):
- Do nothing
- Add support to write to different types of files (devices, pipes, ...)
- And/or add support of external audio plugins (MuCoS plugins)
- And/or add support of client/server with shared mem (Bennos)
- Rewrite your whole app to fit perfectly.

I think I have ordered the options from easy to hard, but that will
of cause depend on the application itself.

Note: there is also the choice (as an audio app integrator):
- Write a plugin that can communicate with the other application
  in the way it supports.

> >
> > The problem I have with your code are:
> > * that it requires one thread per plugin-instance 'while(1) {...}'
> 
> Yes this is because you misinterpreted that the client/server runs
> every plugin in a separate thread.
> 
> No, just as Paul pointed out is a mix of both:
> 
> assume there are a few  monolithic apps running:
> softsynth , HD recorder , FX rack.
> Each app runs a set on plugins in his own thread,
> but the 3 apps communicate through the client/server API,
> in "real-time".
> 
> This approach lets integrate even old binary-only (through
> LD_PRELOAD wrapper) apps into Mucos.
> 
> Of course the recommendation is to use a number of threads
> as little as possible.
> That means if an app can act as plugin, the "master" should
> run the "plugin" in his thread in order to minimize scheduling overhead.
> But sometime this isn't possible or desired.
> And here the client/server approach comes handy.
> 
> I hope that the concepts are a bit clearer.
> (sorry for my superficial explanations  :-) )
> 
> Anyone that disagrees with my ideas.
> 

What do you think of my idea using a 'engine' and communication plugins?
With an app that supports shared memory, the plugin only have to
notify the client app about the address to 'connectors'.

> > (Note that Ingo has recently patched a latency bug in this area...)
> 
> do you have the BH (botton half) patch ?
> maybe this will even cut down latency further, because it might eliminate
> the peaks of  fragmentsize len)

The one I was thinking of is when sending a signal to another higher
prio
process it was not checked if the sending process needed to reshedule
afterwards. Resheduling was done at next timer interupt.

> 
> Benno.

--
Home page:
  http://www.norran.net/nra02596/


From - Mon Dec 20 12:15:05 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id JAA05080
	for <slinkp@ulster.net>; Mon, 20 Dec 1999 09:13:31 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA28019 for linux-audio-dev-list; Mon, 20 Dec 1999 08:58:02 -0500
Received: from renoir.op.net (renoir.op.net [207.29.195.4]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA28016 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 20 Dec 1999 08:58:00 -0500
Received: from someip.ppp.op.net (d-bm3-08.ppp.op.net [209.152.194.72]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id IAA22112; Mon, 20 Dec 1999 08:42:47 -0500 (EST)
Message-Id: <199912201342.IAA22112@renoir.op.net>
To: Juhana Sadeharju <kouhia@nic.funet.fi>
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Cool synth patches? 
In-reply-to: Your message of "Mon, 20 Dec 1999 12:39:31 +0200."
             <19991220103942Z42345-5344+1235@nic.funet.fi> 
Date: Mon, 20 Dec 1999 08:43:09 -0500
From: Paul Barton-Davis <pbd@Op.Net>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: e3b15402422032847b33cef10c5f5f90

Juhana - in case you haven't seen it yet, you might want to read:

http://www.neuroinformatik.ruhr-uni-bochum.de/ini/PEOPLE/heja/sy-prog/sy-prog.html

its not really quite what you are looking for, but it does have some
good hints on getting good and/or interesting sounds from the SY77
synth, and much of the advice applies to other synths. A lot of the
document is more general stuff on how synthesis works, but i thought
that some of the hints were pretty good.

>Would Csound be able to produce commercial quality sounds? Were from
>I could obtain preset sounds? I have some very simple sounds but nothing
>great; 303 sounds nothing like Supernova.

Csound can produce any sound! The questions are (1) can you
write the instrument definition and (2) will it run in real-time ?
The real time part gets really hard when you want to run it under MIDI
control, because many of the most interesting opcodes tend to require
knowledge of the note duration, which is not available. 

Note that on several current digital synths, including those that want
to pretend to be analog, there is a bit of tendency to route the outs
from the "vca" through an FX unit. I know that a lot of the coolest
sounds on my Kawai K5000S (at just under $400 on sale, this is one of
the best purchases I ever made) sound very flat when i cancel the FX
routing. I read about a band recently who use only old analog gear and
they made some comment about not wanting to do any FX processing on it
"to allow the sound to really come through". These people are NOT
noise addicts, clearly. For me, its all about the quality of the sound
too but I don't differentiate between synthesis and processing, or
analog and digital: if it sounds right, it is right!

--p

From - Mon Dec 20 13:24:52 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA07860
	for <slinkp@ulster.net>; Mon, 20 Dec 1999 13:12:22 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA28309 for linux-audio-dev-list; Mon, 20 Dec 1999 12:51:07 -0500
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA28306 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 20 Dec 1999 12:51:04 -0500
Received: from ulster.net (port87.ts2.ulster.net [208.242.164.87])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id MAA03690;
	Mon, 20 Dec 1999 12:45:20 -0500
Message-ID: <385E6D88.1898F95E@ulster.net>
Date: Mon, 20 Dec 1999 12:55:20 -0500
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-audio-dev@ginette.musique.umontreal.ca
CC: Juhana Sadeharju <kouhia@nic.funet.fi>
Subject: Re: [linux-audio-dev] Cool synth patches?
References: <19991219151909Z28982-5344+1176@nic.funet.fi> <Pine.LNX.4.10.9912191641320.1575-100000@sreal.and.av.com> <19991219192619.A8166@div8.net> <19991220103942Z42345-5344+1235@nic.funet.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 52f6036b4f49e8b0cd3f4522c4c4958c

Juhana Sadeharju wrote:
> 
> Hello. Thank you for the replies so far. I will check if I find books
> but so far I have found only books which tells how synths works but
> not how to make cool razor (or any) sounds, for example.
(snip)
> I really don't know it because my Csound has no preset sounds at all!
> Would Csound be able to produce commercial quality sounds? Were from
> I could obtain preset sounds? I have some very simple sounds but nothing
> great; 303 sounds nothing like Supernova.



One book that's interesting is Charles DOdge's "Computer Music", 2nd
edition, published by Simon & Schuster. It describes in detail the
various kinds of synthesis (FM, waveshaping, subtractive, etc.) and
outlines how instruments are put together in the music-N family
(which includes Csound), and gives flowcharts for some pretty
interesting examples. It doesn't give you actual csound code for the
examples, though; you have to understand csound well enough to
translate the flowcharts into instruments. And then you still have
to do a lot of experimentation to find parameters that sound
interesting.
 
But your best bet may be to download lots of example orcs and scores
and just run them, then see if you can figure out what's going on in
the ones you like and modify them as you wish.
My favorite csound sites:

http://mitpress.mit.edu/e-books/csound/fpage/instr/instr.html
--this links to all the following.

http://www.haint.com/sounds/
--Sean Costello has some really impressive orcs.

http://members.tripod.com/csound/
--The JMC Csound Repository by Josep M Comajuncosas, includes MP3s
of instruments. Many woodwinds, some cool synths.

http://www.babcom.u-net.com/csound.html
--Steven Cook's stuff, some very very good orcs here.

http://www.werewolf.net/~hljmm/csound/
--Hans Mikelson has some really good ones too.


-- 
................    paul winkler    ..................
slinkP arts:   music, sound, illustration, design, etc.
A member of ARMS    ----->    http://www.reacharms.com
or http://www.mp3.com/arms or http://www.amp3.com/arms
personal page   ---->    http://www.ulster.net/~abigoo

From - Tue Dec 21 22:02:12 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA07211
	for <slinkp@ulster.net>; Mon, 20 Dec 1999 19:48:14 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA28960 for linux-audio-dev-list; Mon, 20 Dec 1999 19:33:06 -0500
Received: from nic.funet.fi (nic.funet.fi [193.166.0.145]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA28957 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 20 Dec 1999 19:33:03 -0500
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S4427AbPLUA02>; Tue, 21 Dec 1999 02:26:28 +0200
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <199912201342.IAA22112@renoir.op.net> (message from Paul
	Barton-Davis on Mon, 20 Dec 1999 08:43:09 -0500)
Subject: Re: [linux-audio-dev] Cool synth patches?
References:  <199912201342.IAA22112@renoir.op.net>
Message-Id: <19991221002632Z4427-5344+1963@nic.funet.fi>
Date:   Tue, 21 Dec 1999 02:26:28 +0200
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 46d06c77591af1b3c2eafa1127a7f129

>From:   Paul Barton-Davis <pbd@Op.Net>
>
>http://www.neuroinformatik.ruhr-uni-bochum.de/ini/PEOPLE/heja/sy-prog/
>sy-prog.html

It is looking great. I will read it.

>from the "vca" through an FX unit. I know that a lot of the coolest
>sounds on my Kawai K5000S (at just under $400 on sale, this is one of
>the best purchases I ever made) sound very flat when i cancel the FX
>routing.

I will look for the manuals if they have them on-line.
I think stereo chorus does pretty good for the sound. But I still
wonder if some 303 clone sounds use any chorus or is there just
some oscillator interferences or anything else. Those academic books
(thanks for the hint anyway) are quite useless in this sense.

Perhaps this needs for bigger project: a library of preset sounds.
All synths seems to have plenty of presets, and we should not be any
less better.

Juhana

From - Tue Dec 21 22:02:15 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id BAA16316
	for <slinkp@ulster.net>; Tue, 21 Dec 1999 01:14:16 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id AAA29337 for linux-audio-dev-list; Tue, 21 Dec 1999 00:44:45 -0500
Received: from smtp.mail.yahoo.com (smtp.mail.yahoo.com [128.11.68.32]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id AAA29334 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 21 Dec 1999 00:44:42 -0500
Received: from modem28-tc5.sinectis.com.ar (HELO yahoo.com) (216.244.203.28)
  by smtp.mail.yahoo.com with SMTP; 20 Dec 1999 21:38:13 -0800
X-Apparently-From: <luispagasparotto@yahoo.com>
Message-ID: <385F107C.774E741C@yahoo.com>
Date: Tue, 21 Dec 1999 02:30:36 -0300
From: Luis Pablo Gasparotto <luispagasparotto@yahoo.com>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>,
        Red Hat List <redhat-list@redhat.com>
Subject: [linux-audio-dev] Multitrack recorder For Fiji
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 2449999625c02b0f484e5d44a8e6eff6

Hi all,

Do anybody know some multitrack recorder for use with TB Fiji soundcard?

Thank you very much.

Luis Pablo Gasparotto




__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one place.
Yahoo! Shopping: http://shopping.yahoo.com

From - Tue Dec 21 22:02:18 1999
Received: from toad.mindrot.org (IDENT:postfix@intern12.lnk.telstra.net [139.130.53.38])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id JAA16293
	for <slinkp@ulster.net>; Tue, 21 Dec 1999 09:31:01 -0500
Received: by toad.mindrot.org (Postfix)
	id 6117426F82; Wed, 22 Dec 1999 01:29:27 +1100 (EST)
Delivered-To: csound-unix-dev-list@mindrot.org
Received: by toad.mindrot.org (Postfix, from userid 91)
	id 1368826F84; Wed, 22 Dec 1999 01:29:27 +1100 (EST)
Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.5])
	by toad.mindrot.org (Postfix) with ESMTP id 9DF5D26F82
	for <csound-unix-dev@ilogic.com.au>; Wed, 22 Dec 1999 01:29:16 +1100 (EST)
Received: from bright.net (find-cas1-cs-45.dial.bright.net [209.143.26.148])
	by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id JAA18194;
	Tue, 21 Dec 1999 09:29:05 -0500 (EST)
Message-ID: <385F94AE.176112E7@bright.net>
Date: Tue, 21 Dec 1999 09:54:39 -0500
From: Dave Phillips <dlphilp@bright.net>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Csound Linux Development Mail <csound-unix-dev@ilogic.com.au>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [CUD] various & sundry
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-unix-dev@mindrot.org
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 9e5cef0ebdeb1bea704f254b605639d5

Greetings:

  I have recently updated the Linux Sound & Music Applications site,
including the 1-page format. My apologies to those folks who have been
patiently waiting for this edition.

  I've been busy writing a book about Linux music and sound apps. It's
kicking my ass to get it finished, but it's fun and very educational.

  Also, does anyone have a P266 or better motherboard they want to get
rid of for ultracheap ?? I missed the VA Linux IPO, Xmas is cleaning me
out, etc, etc, etc...

  Anyway, I wanted to thank everyone for their wonderful software,
ideas, and commentary. I wish the very best of the holiday season to you
all !!

  PS: If you're in Findlay OH USA on Dec. 31 we'll be jamming the night
away at Rena's Greek Restaurant. Big musicians' jam session, all night
'til we drop !

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
       http://www.bright.net/~dlphilp/linuxsound/

From - Tue Dec 21 22:02:26 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA25759
	for <slinkp@ulster.net>; Tue, 21 Dec 1999 17:15:17 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA04699 for linux-audio-dev-list; Tue, 21 Dec 1999 17:02:33 -0500
Received: from cummings.uol.com.br (cummings.uol.com.br [200.230.198.69]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA04696 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 21 Dec 1999 17:02:28 -0500
Received: from 200-191-148-84-as.acessonet.com.br (200-191-148-84-as.acessonet.com.br [200.191.148.84])
	by cummings.uol.com.br (8.9.1/8.9.1) with SMTP id TAA16124
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 21 Dec 1999 19:55:54 -0200 (BRST)
Received: by 200-191-148-84-as.acessonet.com.br with Microsoft Mail
	id <01BF4BED.A04B8760@200-191-148-84-as.acessonet.com.br>; Tue, 21 Dec 1999 19:57:35 -0200
Message-ID: <01BF4BED.A04B8760@200-191-148-84-as.acessonet.com.br>
From: Rafael Flister Monteiro <flister@uol.com.br>
To: "linux-audio-dev@ginette.musique.umontreal.ca"
	 <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] SoundBlaster PCI 128
Date: Tue, 21 Dec 1999 19:49:32 -0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nerf.ulster.net id RAA25759
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: fb61f96a2acd69719016e49f597361dc

Hi,

I bought a SoundBlaster PCI 128 but I wasn't able to install it using the sndconfig.
I am using Linux RedHat 6.0. I have already check if the modules are installed and I saw at RedHat website that RedHat 6.0 supports this soundcard.

If someone has this soundcard and know how to install it I will be very grateful if you help me.

Thanks.

Rafael.

From - Tue Dec 21 22:02:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA09026
	for <slinkp@ulster.net>; Tue, 21 Dec 1999 18:18:34 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA04813 for linux-audio-dev-list; Tue, 21 Dec 1999 18:03:38 -0500
Received: from miranda.tx.fnc.fujitsu.com (miranda.tx.fnc.fujitsu.com [167.254.254.199]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA04810 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 21 Dec 1999 18:03:35 -0500
Received: from tddwd084.tx.fnc.fujitsu.com (tddwd084.tddeng00.fnts.com [167.254.239.84])
	by miranda.tx.fnc.fujitsu.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26610;
	Tue, 21 Dec 1999 16:57:04 -0600 (CST)
Received: from tddtx.fujitsu.com (localhost [127.0.0.1])
	by tddwd084.tx.fnc.fujitsu.com (8.8.8+Sun/8.8.8) with ESMTP id QAA04032;
	Tue, 21 Dec 1999 16:57:03 -0600 (CST)
Message-ID: <386005BE.1BFC3935@tddtx.fujitsu.com>
Date: Tue, 21 Dec 1999 16:57:03 -0600
From: Chris Bagwell <cbagwell@tx.fnc.fujitsu.com>
Organization: Fujitsu Network Communications
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
CC: Rafael Flister Monteiro <flister@uol.com.br>,
        "linux-audio-dev@ginette.musique.umontreal.ca" 
 <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] SoundBlaster PCI 128
References: <01BF4BED.A04B8760@200-191-148-84-as.acessonet.com.br> <386019A2.31280381@alphalink.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 8f349844486c87e3856b65dd218b0789

If I remember correctly, there was a bug in RedHat 6.0 (and Mandrake's
similar version) with this card.  Did you get an error message saying
something like "effect unknown"?

If so then you will want to download and install the latest RPM's for
sndconfig and sox.

Another warning for you is that this card tends to support standard
sample rates by + or - 1.  For instances, if you ask to use 44100 the
card will report using 44101.  Not a big deal but it tends to confuse
some software.

Chris

Rafael Flister Monteiro wrote:
> I bought a SoundBlaster PCI 128 but I wasn't able to install it using the
sndconfig.
> I am using Linux RedHat 6.0. I have already check if the modules are
installed and I saw at RedHat website that RedHat 6.0 supports this
soundcard.

From - Tue Dec 21 22:02:27 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA27717
	for <slinkp@ulster.net>; Tue, 21 Dec 1999 17:22:33 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA04730 for linux-audio-dev-list; Tue, 21 Dec 1999 17:11:24 -0500
Received: from mail.alphalink.com.au (mail.alphalink.com.au [203.24.205.7]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA04727 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 21 Dec 1999 17:11:19 -0500
Received: from alphalink.com.au (IDENT:andrew@d03-as14-mel.alphalink.com.au [202.161.98.34])
	by mail.alphalink.com.au (8.9.3/8.9.3) with ESMTP id JAA09044;
	Wed, 22 Dec 1999 09:04:18 +1100
Message-ID: <386019A2.31280381@alphalink.com.au>
Date: Tue, 21 Dec 1999 19:21:54 -0500
From: Andrew Clausen <clausen@alphalink.com.au>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.10 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Rafael Flister Monteiro <flister@uol.com.br>
CC: "linux-audio-dev@ginette.musique.umontreal.ca" 
 <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] SoundBlaster PCI 128
References: <01BF4BED.A04B8760@200-191-148-84-as.acessonet.com.br>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: b7f8e949ae55e30996fe7c89aee7ec1a

Rafael Flister Monteiro wrote:
> I bought a SoundBlaster PCI 128 but I wasn't able to install it using the sndconfig.
> I am using Linux RedHat 6.0. I have already check if the modules are installed and I saw at RedHat website that RedHat 6.0 supports this soundcard.

It works OK with the vanilla OSS with Redhat 6.1.  Haven't tried 6.0

sndconfig detects it ok, and it configures automagically for me...

Andrew Clausen

From - Wed Dec 22 00:12:06 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA11948
	for <slinkp@ulster.net>; Tue, 21 Dec 1999 23:58:59 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id XAA05229 for linux-audio-dev-list; Tue, 21 Dec 1999 23:45:44 -0500
Received: from zhora.replicant.apana.org.au (replicant.apana.org.au [203.12.238.34]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA05226 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 21 Dec 1999 23:45:39 -0500
Received: (from smap@localhost)
	by zhora.replicant.apana.org.au (8.8.5/8.8.5) id PAA08270;
	Wed, 22 Dec 1999 15:38:59 +1100
Received: from hexdance.replicant.apana.org.au(192.168.200.126) by zhora.replicant.apana.org.au via smap (V1.3)
	id xmaa08265; Wed, 22 Dec 99 15:38:45 +1100
Received: (from jlittler@localhost)
	by localhost.localdomain (8.9.3/8.9.3) id OAA00601;
	Wed, 22 Dec 1999 14:44:38 +1100
From: John Littler <linuxmusic@crosswinds.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14432.18693.703959.125242@localhost.localdomain>
Date: Wed, 22 Dec 1999 14:44:05 +1100 (EST)
To: Rafael Flister Monteiro <flister@uol.com.br>
Cc: "linux-audio-dev@ginette.musique.umontreal.ca"
	 <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] SoundBlaster PCI 128
In-Reply-To: <01BF4BED.A04B8760@200-191-148-84-as.acessonet.com.br>
References: <01BF4BED.A04B8760@200-191-148-84-as.acessonet.com.br>
X-Mailer: VM 6.72 under 21.1 (patch 3) "Acadia" XEmacs Lucid
X-Face: I99/`A]X7p:F"Q@8d3;)=!%o\!&^`I6m7n+1Nd%/*x4zKb_?i1[Z[0C$#;&i[+'meY)qRuiIRx}Y#Th_k1@sG,JV:)W4fO%H(%C.@$|5{8g1VN&0jh0sc$qrCrs/2\BWO&^a
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 9bc540a36ef0bdbf0e415a297b1c3013

quoting Rafael Flister Monteiro:

 > I bought a SoundBlaster PCI 128 but I wasn't able to install it using the sndconfig.
 > I am using Linux RedHat 6.0. I have already check if the modules are installed and I saw at RedHat website that RedHat 6.0 supports this soundcard.

one thing to try if you haven't already is to configure the soundcard
before the modem.
Christmas Cheers
John
-- 

http://linuxmusic.cjb.net

From - Thu Dec 23 13:38:53 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA01223
	for <slinkp@ulster.net>; Wed, 22 Dec 1999 14:37:16 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA12209 for linux-audio-dev-list; Wed, 22 Dec 1999 14:17:33 -0500
Received: from nerf.ulster.net (ulster.net [208.148.73.65]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA12206 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 22 Dec 1999 14:17:30 -0500
Received: from ulster.net (port107.ts2.ulster.net [208.242.164.107])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id OAA30139
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 22 Dec 1999 14:11:52 -0500
Message-ID: <386124AA.A1D7A755@ulster.net>
Date: Wed, 22 Dec 1999 14:21:14 -0500
From: Paul Winkler <slinkp@ulster.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] pysco 0.0.2 -- input please!
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: dd0bd92e46669c4fc2bda4093c2c7a91

Am I the only one crazy enough to try to write music (well, generate
csound scores, anyway) in pure python?

anyone who knows python please have a look at pysco 0.0.2 and tell
me what you think!! especially I am hoping anyone can see where I
might be shooting myself in the foot. See the TODO file for some
info on what I'd like to be able to accomplish.

it's at:
http://www.ulster.net/~abigoo/pw_linux/code.html

-- 
................    paul winkler    ..................
slinkP arts:   music, sound, illustration, design, etc.
A member of ARMS    ----->    http://www.reacharms.com
or http://www.mp3.com/arms or http://www.amp3.net/arms
personal page   ---->    http://www.ulster.net/~abigoo

From - Wed Dec 29 13:20:28 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA05283
	for <slinkp@ulster.net>; Thu, 23 Dec 1999 19:05:08 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA18667 for linux-audio-dev-list; Thu, 23 Dec 1999 18:45:54 -0500
Received: from zhora.replicant.apana.org.au (replicant.apana.org.au [203.12.238.34]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA18664 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 23 Dec 1999 18:45:45 -0500
Received: (from smap@localhost)
	by zhora.replicant.apana.org.au (8.8.5/8.8.5) id KAA22232
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Fri, 24 Dec 1999 10:38:54 +1100
Received: from hexdance.replicant.apana.org.au(192.168.200.126) by zhora.replicant.apana.org.au via smap (V1.3)
	id xma022228; Fri, 24 Dec 99 10:38:47 +1100
Received: (from jlittler@localhost)
	by localhost.localdomain (8.9.3/8.9.3) id KAA00644;
	Fri, 24 Dec 1999 10:44:04 +1100
From: John Littler <jlittler@nirvanet.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14434.46019.462184.747093@localhost.localdomain>
Date: Fri, 24 Dec 1999 10:44:03 +1100 (EST)
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] soundcard sythns
X-Mailer: VM 6.72 under 21.1 (patch 3) "Acadia" XEmacs Lucid
X-Face: I99/`A]X7p:F"Q@8d3;)=!%o\!&^`I6m7n+1Nd%/*x4zKb_?i1[Z[0C$#;&i[+'meY)qRuiIRx}Y#Th_k1@sG,JV:)W4fO%H(%C.@$|5{8g1VN&0jh0sc$qrCrs/2\BWO&^a
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8003
X-Mozilla-Status2: 00000000
X-UIDL: e95a714085d1ddfc25b4eaf20170e5dc

Hi,
Would anyone like to recommend a supported soundcard with
nice-sounding onboard patch set? I've been using an ES1371
in conjunction with an sb16 - timidity is nice for playback but
it would ne nice to get that stuff onto hardware and have more
system resources free for other things.

Christmas Greetings and a Happy Y2K to all!
Cheers
John

-- 

http://linuxmusic.cjb.net

From - Wed Dec 29 13:21:19 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA25131
	for <slinkp@ulster.net>; Mon, 27 Dec 1999 14:18:30 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA05639 for linux-audio-dev-list; Mon, 27 Dec 1999 14:02:05 -0500
Received: from smtp.mail.yahoo.com (smtp.mail.yahoo.com [128.11.68.32]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id OAA05622 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Dec 1999 14:02:01 -0500
Received: from modem64-cisco20.sinectis.com.ar (HELO yahoo.com) (216.244.194.184)
  by smtp.mail.yahoo.com with SMTP; 27 Dec 1999 10:55:13 -0800
X-Apparently-From: <luispagasparotto@yahoo.com>
Message-ID: <3867B56E.EC8D8D4E@yahoo.com>
Date: Mon, 27 Dec 1999 15:52:30 -0300
From: Luis Pablo Gasparotto <luispagasparotto@yahoo.com>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>,
        Red Hat List <redhat-list@redhat.com>
Subject: [linux-audio-dev] Multitrack recorder for Fiji
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 49f8aa35af6342594f679be703dd792c

Hi all,

Do anybody know a multitrack recorder and a sound editor (like
SoundForge) for use with TB Fiji soundcard?

Thank you very much.

Luis Pablo Gasparotto



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

From - Wed Dec 29 13:21:20 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA25132
	for <slinkp@ulster.net>; Mon, 27 Dec 1999 14:18:31 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA04449 for linux-audio-dev-list; Mon, 27 Dec 1999 13:59:21 -0500
Received: from smtp.mail.yahoo.com (smtp.mail.yahoo.com [128.11.68.32]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA04425 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Dec 1999 13:59:17 -0500
Received: from modem64-cisco20.sinectis.com.ar (HELO yahoo.com) (216.244.194.184)
  by smtp.mail.yahoo.com with SMTP; 27 Dec 1999 10:52:29 -0800
X-Apparently-From: <luispagasparotto@yahoo.com>
Message-ID: <3867B56E.EC8D8D4E@yahoo.com>
Date: Mon, 27 Dec 1999 15:52:30 -0300
From: Luis Pablo Gasparotto <luispagasparotto@yahoo.com>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linux Audio Dev." <linux-audio-dev@ginette.musique.umontreal.ca>,
        Red Hat List <redhat-list@redhat.com>
Subject: [linux-audio-dev] Multitrack recorder for Fiji
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 8f1f48486d725708553fb6bab5c958fc

Hi all,

Do anybody know a multitrack recorder and a sound editor (like
SoundForge) for use with TB Fiji soundcard?

Thank you very much.

Luis Pablo Gasparotto



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

From - Wed Dec 29 13:21:22 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA30992
	for <slinkp@ulster.net>; Mon, 27 Dec 1999 15:05:40 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA28627 for linux-audio-dev-list; Mon, 27 Dec 1999 14:52:49 -0500
Received: from nic.funet.fi (nic.funet.fi [193.166.0.145]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA28608 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Dec 1999 14:52:45 -0500
Received: (from localhost user: 'kouhia', uid#241) by nic.funet.fi
	id <S8759AbPL0Tps>; Mon, 27 Dec 1999 21:45:48 +0200
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-audio-dev@ginette.musique.umontreal.ca, luispagasparotto@yahoo.com
In-reply-to: <3867B56E.EC8D8D4E@yahoo.com> (message from Luis Pablo Gasparotto
	on Mon, 27 Dec 1999 15:52:30 -0300)
Subject: Re: [linux-audio-dev] Multitrack recorder for Fiji
References:  <3867B56E.EC8D8D4E@yahoo.com>
Message-Id: <19991227194554Z8759-5344+3099@nic.funet.fi>
Date:   Mon, 27 Dec 1999 21:45:48 +0200
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 38cb5a496f2b3b4d7c199eaa75b82513

>Do anybody know a multitrack recorder and a sound editor (like
>SoundForge) for use with TB Fiji soundcard?

Why are you refering to your soundcard? Is it some special 16 track
audiocard and needs a special software?

I recently installed new Linux and Alsa drivers. I would like to know
a few "must have" programs which I should install. Anyone?

I have now these:
  arecord -for simple recording
  shmrec  -my own simple recorder (hey, it _is_ reliable! :-)
  mpg123  -mp3 player
  lame    -mp3 encoder

How should I continue in collecting audio programs? What is the status
of everything out there?

Yours,

Juhana

From - Wed Dec 29 13:21:23 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA06329
	for <slinkp@ulster.net>; Mon, 27 Dec 1999 16:16:12 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA28065 for linux-audio-dev-list; Mon, 27 Dec 1999 15:58:22 -0500
Received: from mail.netbrick.com ([216.190.149.5]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA28041 for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Dec 1999 15:58:18 -0500
Received: from localhost (crowderb@localhost)
	by mail.netbrick.com (8.9.3/8.9.3) with ESMTP id NAA02105
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Mon, 27 Dec 1999 13:57:11 -0700
Date: Mon, 27 Dec 1999 13:57:11 -0700 (MST)
From: Ben Crowder <crowderb@netbrick.com>
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Multitrack recorder for Fiji
In-Reply-To: <19991227194554Z8759-5344+3099@nic.funet.fi>
Message-ID: <Pine.LNX.4.10.9912271355430.1721-100000@mail.netbrick.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 1a28fd3769a0491ae8aa6907c9ea9e64

On Mon, 27 Dec 1999, Juhana Sadeharju wrote:

> I recently installed new Linux and Alsa drivers. I would like to know
> a few "must have" programs which I should install. Anyone?
> 
> I have now these:
>   arecord -for simple recording
>   shmrec  -my own simple recorder (hey, it _is_ reliable! :-)
>   mpg123  -mp3 player
>   lame    -mp3 encoder

Personally, I use krecord for recording and snd for any editing.  (Though
snd is a bit hard to learn how to use.)  One thing I've been wondering is
if there's anything that can do basic noise reduction.  (For Linux, of
course.)  Does anyone know anything about this?

Thanks,
Ben

From - Wed Dec 29 13:21:29 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id GAA15670
	for <slinkp@ulster.net>; Tue, 28 Dec 1999 06:19:29 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA12448 for linux-audio-dev-list; Tue, 28 Dec 1999 06:00:53 -0500
Received: from aino.wakkanet.fi (aino.wakkanet.fi [194.157.35.1]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA12427 for <linux-audio-dev@ginette.musique.umontreal.ca>; Tue, 28 Dec 1999 06:00:48 -0500
Received: from aino (IDENT:kaiv@aino [194.157.35.1])
	by aino.wakkanet.fi (8.9.3/8.9.3) with ESMTP id MAA15179;
	Tue, 28 Dec 1999 12:53:57 +0200
Date: Tue, 28 Dec 1999 12:53:55 +0200 (EET)
From: Kai Vehmanen <kaiv@wakkanet.fi>
To: Juhana Sadeharju <kouhia@nic.funet.fi>
cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Multitrack recorder for Fiji
In-Reply-To: <19991227194554Z8759-5344+3099@nic.funet.fi>
Message-ID: <Pine.LNX.4.10.9912281249150.15047-100000@aino.wakkanet.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 47b4593dbd98b48573d39a0b1ee20148

On Mon, 27 Dec 1999, Juhana Sadeharju wrote:

> I recently installed new Linux and Alsa drivers. I would like to know
> a few "must have" programs which I should install. Anyone?
[...] 
> How should I continue in collecting audio programs? What is the status
> of everything out there?

As for ALSA, I maintain ALSA-support for SoundTracker and ecasound.
Currently supported ALSA versions are 0.3.x and 0.4.x. I'll add
0.5.x support as soon as the first public version is released. In 
addition to normal pcm, ecasound also supports ALSA's loopback 
device so you can capture output from other programs.

--
 Kai Vehmanen (kaiv@wakkanet.fi)
 Webmaster, Wakkanet Oy

From - Wed Dec 29 13:21:41 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA02024
	for <slinkp@ulster.net>; Wed, 29 Dec 1999 07:13:10 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA10152 for linux-audio-dev-list; Wed, 29 Dec 1999 06:49:35 -0500
Received: from mout1.01019freenet.de (mout1.01019freenet.de [62.104.201.3]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA10130 for <linux-audio-dev@ginette.musique.umontreal.ca>; Wed, 29 Dec 1999 06:49:30 -0500
From: depet@gmx.de
Received: from [62.104.201.6] (helo=mx0.01019freenet.de)
	by mout1.01019freenet.de with esmtp (Exim 3.12 #2)
	id 123HV3-0007OX-00
	for linux-audio-dev@ginette.musique.umontreal.ca; Wed, 29 Dec 1999 12:42:41 +0100
Received: from [212.81.222.60] (helo=Nirvana.Saustall)
	by mx0.01019freenet.de with esmtp (Exim 3.12 #2)
	id 123HV2-000263-00
	for linux-audio-dev@ginette.musique.umontreal.ca; Wed, 29 Dec 1999 12:42:41 +0100
Message-ID: <XFMail.991229125627.depet@gmx.de>
X-Mailer: XFMail 1.3 [p0] on Linux
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <Pine.LNX.4.10.9912271355430.1721-100000@mail.netbrick.com>
Date: Wed, 29 Dec 1999 12:56:27 +0100 (CET)
To: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Multitrack recorder for Fiji
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: d2d6db851afc96c9148e1c157cd229eb

> One thing I've been wondering is
> if there's anything that can do basic noise reduction.  (For Linux, of
> course.)  Does anyone know anything about this?
> 
> Thanks,
> Ben

checkout dnr, anoi and denoi, all of them use different methods and do good work
anoi is used as plugin in snd too.

From - Fri Dec 31 01:00:08 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA07054
	for <slinkp@ulster.net>; Thu, 30 Dec 1999 10:36:51 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA02962 for linux-audio-dev-list; Thu, 30 Dec 1999 10:18:57 -0500
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA02942 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Dec 1999 10:18:52 -0500
Received: from debian (d212-151-169-159.swipnet.se [212.151.169.159]) 
          by mb04.swip.net (8.8.8/8.8.8) with ESMTP 
          id QAA18755 for <linux-audio-dev@ginette.musique.umontreal.ca>; 
          Thu, 30 Dec 1999 16:10:29 +0100 (MET)
Received: from debian.mbox314.swipnet.se (really [127.0.0.1]) by debian
	via in.smtpd with esmtp (ident root using rfc1413)
	id <m123hIx-0017oYC@debian> (Debian Smail3.2.0.101)
	for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Dec 1999 16:15:55 +0100 (CET) 
Message-Id: <m123hIx-0017oYC@debian>
Date: Thu, 30 Dec 1999 16:15:51 +0100 (CET)
From: reine@mbox314.swipnet.se
Reply-To: reine@mbox314.swipnet.se
Subject: [linux-audio-dev] Is there a program to do this? 
To: linux-audio-dev@ginette.musique.umontreal.ca
MIME-Version: 1.0
Content-Type: TEXT/plain; CHARSET=US-ASCII
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 4106e3d40cd9454c2e4ea49667b10370


I would like to something like this: 
  
play a sound

while (go on for a long (reasonably ;) time) {

   //event is mousebutton,keypress whatever
   if (event within 1 to 5 secs) {  
      start to play sound-x2 after xxx sec   
   }
   else if (another event) {
      start to play sound-x3 after xxx sec  
   }   
   else {
      start to play sound-x4 after xxx sec 
   }
}

// playing sounds may include starttime and endtimes

Are there a Linux program to do this or
shall I try to do something myself. 
I have a mixbas source to be found at
http://home.swipnet.se/roses/sound.html


Reine
http://home.swipnet.se/roses/

From - Fri Dec 31 01:00:10 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA09669
	for <slinkp@ulster.net>; Thu, 30 Dec 1999 10:55:22 -0500
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA10021 for linux-audio-dev-list; Thu, 30 Dec 1999 10:40:09 -0500
Received: from flophouse.localnet (grib.customer.jump.net [216.30.103.2]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA10005 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 30 Dec 1999 10:40:05 -0500
Received: by flophouse.localnet (Postfix, from userid 1000)
	id C4B168DCD; Thu, 30 Dec 1999 09:33:13 -0600 (CST)
To: reine@mbox314.swipnet.se
Cc: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Is there a program to do this?
References: <m123hIx-0017oYC@debian>
From: Bill Gribble <grib@cs.utexas.edu>
Date: 30 Dec 1999 09:33:13 -0600
In-Reply-To: reine@mbox314.swipnet.se's message of "Thu, 30 Dec 1999 16:15:51 +0100 (CET)"
Message-ID: <87aemssati.fsf@flophouse.localnet>
Lines: 24
User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.5
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: c34fad25796973c774290d9e76159bb7

reine@mbox314.swipnet.se writes:
> while (go on for a long (reasonably ;) time) {
> 
>    //event is mousebutton,keypress whatever
>    if (event within 1 to 5 secs) {  
>       start to play sound-x2 after xxx sec   
>    }
>    else if (another event) {
>       start to play sound-x3 after xxx sec  
>    }   
>    else {
>       start to play sound-x4 after xxx sec 
>    }
> }
> 
> // playing sounds may include starttime and endtimes

Have a look at quasimodo (http://www.quasimodo.org).  It's not 
quite ready for release, but it's quite functional right now and
you can construct a graphical "patch panel" that could do what
you describe above.

Bill Gribble

From - Fri Oct 15 03:05:37 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA32412
	for <slinkp@ulster.net>; Thu, 14 Oct 1999 10:49:07 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA16900 for linux-audio-dev-list; Thu, 14 Oct 1999 10:12:02 -0400
Received: from zed.access.net.au (zed.access.net.au [203.13.25.3]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA16897 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 14 Oct 1999 10:11:52 -0400
Received: from response.cx (d085.meldas4.access.net.au [210.8.214.86])
	by zed.access.net.au (8.9.3/8.9.3) with ESMTP id AAA30828;
	Fri, 15 Oct 1999 00:06:42 +1000
Message-ID: <3870BF54.E9C7E4C9@response.cx>
Date: Tue, 04 Jan 2000 02:25:08 +1100
From: josh <josh@response.cx>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Barton-Davis <pbd@Op.Net>
CC: linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] atomic xchg
References: <199910131741.NAA03650@op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
X-UIDL: 885a6207526dc374bcf368c3d35b8725

Why do u wish to do this -- is it a concurrency issue ??

josh

Paul Barton-Davis wrote:
> 
> can someone point me to a gcc asm macro to do atomic pointer swaps
-- 
---
josh@reponse.cx
www.response.cx

From - Fri Aug 13 01:46:43 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA08458
	for <slinkp@ulster.net>; Thu, 12 Aug 1999 14:25:59 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA05746 for linux-audio-dev-list; Thu, 12 Aug 1999 13:41:42 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA05743 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 12 Aug 1999 13:41:38 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m1iBqww-000dyqC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Sun, 22 Sep 2019 03:46:06 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Sun, 22 Sep 2019 03:46:06 +0200 (CEST)
To: Dave Phillips <dlphilp@bright.net>
Cc: Guenter Geiger <geiger@epy.co.at>,
        LAD Mail <linux-audio-dev@ginette.musique.umontreal.ca>
Subject: [linux-audio-dev] Mix and recording
In-Reply-To: <37A9DCD4.117E74A6@bright.net>
References: <37A9DCD4.117E74A6@bright.net>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <23942.53762.210914.209567@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 5b94a54fed7106b9850d338dcf289529

Dave Phillips writes:
 > Greetings:
 > 
 >   I tried recording, it doesn't appear to work. The docs aren't
 > enthusiastic about recording in Mix, but it seems another one of those
 > things we ought to have. What do you think ?
 > 

 Yes, I have done some forework already .. this will work pretty soon
 I hope.

 Guenter 

>   I recorded both with and without the audio monitor. Both times the
 > program ceased accepting keyboard or mouse input. I will keep working on
 > this, but fixing the code is likely to be beyond me.
 > 
 > == Dave Phillips
 > 
 >        http://www.bright.net/~dlphilp/index.html
 >    http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html
 > 

From - Fri Aug 13 01:46:45 1999
Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA [132.204.178.34])
	by nerf.ulster.net (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA10135
	for <slinkp@ulster.net>; Thu, 12 Aug 1999 14:38:58 -0400
Received: (from majordom@localhost) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA05790 for linux-audio-dev-list; Thu, 12 Aug 1999 14:03:59 -0400
Received: from gige ([62.116.9.27]) by ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA05787 for <linux-audio-dev@ginette.musique.umontreal.ca>; Thu, 12 Aug 1999 14:03:54 -0400
Received: by epy.co.at
	via sendmail from stdin
	id <m1iBrIb-000dyqC@gige> (Debian Smail3.2.0.102)
	for linux-audio-dev@ginette.musique.umontreal.ca; Sun, 22 Sep 2019 04:08:29 +0200 (CEST) 
From: Guenter Geiger <geiger@epy.co.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Sun, 22 Sep 2019 04:08:28 +0200 (CEST)
To: Dave Phillips <dlphilp@bright.net>
Cc: reine@mbox314.swipnet.se, geiger@epy.co.at,
        linux-audio-dev@ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Mix update
In-Reply-To: <37AC6E7C.EAC5FB84@bright.net>
References: <m11D8Rk-0017r0C@debian>
	<37AC6E7C.EAC5FB84@bright.net>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <23942.54164.238395.909191@gige>
Sender: owner-linux-audio-dev@ginette.musique.umontreal.ca
Precedence: bulk
Status: U
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 338a8b14a53ce6a679f57d0b2968ada7

Dave Phillips writes:
 > Greetings:
 > 
 >   I added Reine's code to my copy here of Guenter's sources, everything
 > seems to work fine. Should it go in as a fixture ?
 > 
 >   A few more observations:
 > 
 > 	1. The mixed file (track 10) is drawn rather poorly on my machine, with
 > no x axis visible. Reine, didn't you fix that once before ?
 > 
 > 	2. The PAN button in track 10 reads PAR. Where can that be repaired ?
 > 

  That's because it doesn't mean panning, but I don't know what it
  means. In the effect box you can set the filter frequency to follow 
  this "par graph" somehow.

 > 	3. WAV files load fine, but now AIFF files are unrecognized.
 
 Will look into that, as already said, it works on the Alpha.

 > 
 >   Guenter, it appears that you've made some more features available for
 > customization via the resource file. Is it possible to set the screen
 > size that way ? 

 Would be nice. The problem is, that mix is not really resizable at
 all, and as I'm  not an Xt programmer I can only imagine which values
 can be set in the resources andhow they will affect the application.
 I already started to get rid of the hardcoded settings somehow, but
 this is hard work, and, honestly said, I would like to leave it fixed
 at 1024x768.

 >   The LessTif version seems to be somewhat critical too. I'm not sure
 > what version I'm using, though the Xm lib is libXm.so.1.2 _not_
 > libXm.so.1.0.2 (which will cause the flashing radio buttons and segfault
 > in the file browser box).

 This version numbers reflect Motiv compatibility. 
 Motiv 1.2 is the standard mix was written in I guess.

 Will keep you posted if I have new versions to test.

