Re: [linux-audio-dev] Low-latency audio over IP

[Fernando Pablo Lopez-Lezcano]

On Fri, 2004-11-12 at 01:25, Asbjørn Sæbø wrote:
> I am working on what is called "distributed multimedia interaction", one 
> purpose of which is to investigate possibilities for ensemble playing 
> by remote parties, distributing the audio over IP networks.
> 
> A crucial point is to achieve audio transmission with very low latency.  
> If anyone could provide me with information on, or pointers to, 
> open-source software for doing this, I would be grateful.  (I have 
> started to roll my own, but I can hardly defend duplicating work 
> unnecessarily.)
> 
> Other comments are of course also appreciated.

See: http://ccrma.stanford.edu/groups/soundwire/

I see this has not been updated in a while, but Chris Chafe is actively
working on the project, see a recent event (AES demo) here:

http://ccrma.stanford.edu/~cc/soundwire/aes04/demo.html
Or more stuff in Chris's page at:
http://ccrma.stanford.edu/~cc

-- Fernando

Re: [linux-audio-dev] 3D fft analysis program

[Fernando Pablo Lopez-Lezcano]

On Sun, 2004-10-03 at 08:02, Fons Adriaensen wrote:
> On Sun, Oct 03, 2004 at 09:56:24AM -0400, Dave Phillips wrote:
> 
> > I'm hoping that you're thinking of a realtime display, in which the 
> > peaks roll off to create a true waterfall effect.
> 
> I've been thinking of adding such a mode to JAAA. How do you think it
> should look ? 

Hmmm, Fons, as long as you are adding things, a time domain view (ie:
old style oscilloscope display) would be handy to have every once in a
while, specially for teaching...

-- Fernando

Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch

[Fernando Pablo Lopez-Lezcano]

On Wed, 2004-07-21 at 03:53, Florian Schmidt wrote:
> On Tue, 20 Jul 2004 20:32:37 -0400
> Lee Revell <[EMAIL PROTECTED]> wrote:
> > Yes, this is important.  One problem I had recently with the Via EPIA
> > board was that unless 2D acceleration was disabled by setting 'Option
> > "NoAccel"' in /etc/X11/XF86Config-4, overloading the X server would
> > cause interrupts from the soundcard to be completely disabled for tens
> > of milliseconds.  Users should keep in mind that by using 2D or 3D
> > hardware acceleration in X, you are allowing the X server to directly
> > access hardware, which can have very bad results if the driver is
> > buggy.  I am not sure the kernel can do anything about this.
> 
> Hi,
> 
> interesting that you mention the Xserver. I use a dual graphics card setup atm 
> [Nvidia GF3 TI and some matrox pci card]. The nvidia card seems to work flawlessly 
> even with HW accelleration [i use nvidias evil binary only drivers]. The matrox 
> card OTH disturbs the soundcard severely. Whenever i have activity on my second 
> monitor i get sound artefacts in jack's output [no cracklling, it's rather as 
> if the volume is set to 0 for short moments and then back to normal]. There's 
> a certain chance that this artefact produces an xrun. I suppose it's because 
> the card is on the pci bus.

The mga dri kernel driver shares a problem with the radeon (which I use
a lot) and the r128 drivers. They have high latency points that reach
10-15 msecs in normal operation[*]. I have a very old patch (not mine, I
don't quite remember where I got it from) that solves this, but it is
not a "legal" patch in the sense that in schedules with a lock held. It
seems to work but it will lock the computer at some point. AFAIK there
is no proper patch for this latency point at this time. Turning off
acceleration should get rid of the latency spikes with the usual
tradeoff of slow video performance. 

-- Fernando

[*] with the (bad) patch:
http://ccrma.stanford.edu/~nando/latencytest/20040323/2.6.4-1.279.ll.ccrma.radeon/
without the patch:
http://ccrma.stanford.edu/~nando/latencytest/20040323/2.6.4-1.279.ll.ccrma/

Re: [linux-audio-dev] NPTL/2.6 (was snd-hdsp oddities)

[Fernando Pablo Lopez-Lezcano]

On Mon, 2004-07-05 at 09:24, Michael Ost wrote:
> On Thu, 2004-07-01 at 19:16, Paul Davis wrote:
> > When the dust settles from the kernel and NPTL, 2.6 will be more
> > viable. Right now, even though it works for some people, its not a
> > generally viable platform for realtime audio.
> 
> What sort of issues are you seeing with NPTL and the 2.6 kernel? Are
> there stability problems? Functionality problems? I thought I had heard
> the NPTL/2.6 was working fine.

What I'm seeing is, sometimes, xrun storms (this is using 2.6.7 + some
extra patches, lsm for realtime as non-root, recent alsa, qjackctl for
starting and running jack). One of them I think I have tracked to an app
running into denormal problems on a PIV. I still don't know for sure
which part of the system is contributing to the problem (jack / nptl /
alsa). On the same hardware with an older glibc and 2.4.x with low
latency patches I don't see the same problems (but the whole distro is
different, FC1 vs FC2). 

Some users have had good experiences with 2.6.x by turning off nptl with
the LD_ASSUME_KERNEL trick, but they get lousy performance (ie: lots of
xruns) with nptl on. 

-- Fernando

Re: [linux-audio-dev] [ANN] New releases of Aeolus and Jaaa

[Fernando Pablo Lopez-Lezcano]

On Tue, 2004-06-15 at 13:52, Jesse Chappell wrote:
> Fons Adriaensen wrote on Tue, 15-Jun-2004:
>  > The file $AEOLUS_DIR/aeolusrc' must be writeable for [Save] to work.
>  > This is one reason to put the stops directory in the user's home
>  > dir, and not in one of the standard lib directories.
> 
> [MUNCH]
>
> Also, what are your thoughts about disk caching the generated waveforms
> that is done at startup?  These could be written into the ~/.aeolus/
> dir based on whatever settings (samplerate, etc) and loaded instead
> of always re-generating them.  I haven't looked at the internals,
> so if there is some fundamental thing preventing that, ok.  I
> just want to instantly *play* it, you know?  :)

He he he, no instant satisfaction :-) I don't know, how big would be the
whole thing? (As a sysadmin) I would not want something replicated all
over the user home directories that is not really necessary. 

-- Fernando

Re: [linux-audio-dev] [ANN] New releases of Aeolus and Jaaa

[Fernando Pablo Lopez-Lezcano]

> First of all, if you package Aeolus and Jaaa  please use the most recent
> versions that I released only yesterday evening (libclthreads-0.0.3
> and jaaa-0.1.1).

Yes, that's what I currently have packaged...

> > I noticed something different. I used to be able to start
> > Aeolus and click on [Next] and then I would get a preset (you know,
> > instant satisfaction - who wants to spend time turning on stops? :-). It
> > does not seem to happen anymore. Is this something in the packaging I
> > did, or is it something different in Aeolus?
> 
> The current version comes with no defined presets, but you can easily
> create your own. There are 10 banks of 100 presets. Click on [Memory]
> and you'll see something like
> 
> [<][>]  a:b c  [<][>]   and some other buttons.
> 
> a = memory bank #  0..9
> b = preset #, 0..99
> c = U, *, L, S
> 
>U = undefined (empty)
>* = defined
>L = loaded
>S = stored
> [MUNCH]
>
> The file $AEOLUS_DIR/aeolusrc' must be writeable for [Save] to work.
> This is one reason to put the stops directory in the user's home
> dir, and not in one of the standard lib directories.

I see... you may consider for a future version to write a ~/.aeolusrc
alternative file (ie: if $AEOLUS_DIR/aeolusrc is not writable just write
to ~/.aeolusrc), and read from it if available. I'm installing the
presets in a shared lib directory so that there is only one copy for all
users and obviously that directory is not world writable :-)

> The [Preset] button works as follows: while it is 'on', changing
> the registration has no effect until [Preset] is switched off again.
> This allows your registration assistant to prepare a new registration
> and then switch to it :-)
> 
> (So I've finally started to write a manual...)

Yes, indeed, and thanks a lot for the explanations!

> Enjoy !

I surely will!
-- Fernando

Re: [linux-audio-dev] [ANN] New releases of Aeolus and Jaaa

[Fernando Pablo Lopez-Lezcano]

On Sun, 2004-06-13 at 14:58, Fons Adriaensen wrote:
> New releases of Aeolus and Jaaa are now available at
>   

> Aeolus-0.2.0
> 

Hi Fons... I noticed something different. I used to be able to start
Aeolus and click on [Next] and then I would get a preset (you know,
instant satisfaction - who wants to spend time turning on stops? :-). It
does not seem to happen anymore. Is this something in the packaging I
did, or is it something different in Aeolus?

-- Fernando

Re: [linux-audio-dev] [OT] marketing hype

[Fernando Pablo Lopez-Lezcano]

On Wed, 2004-06-09 at 17:50, Marek Peteraj wrote:
> On Thu, 2004-06-10 at 00:24, Fernando Pablo Lopez-Lezcano wrote:
> > On Wed, 2004-06-09 at 15:26, Marek Peteraj wrote:
> > > On Wed, 2004-06-09 at 13:17, Dave Griffiths wrote:
> > > > Personally speaking, as a free software developer I don't care if my
> > > > programs are deemed as sucessful, they work for me, and handful of other
> > > > people - this makes me happy :)
> > > 
> > > I'd like to see what other developers of the most popular linux audio
> > > projects think. 
> > 
> > Most probably you will find out (when/if other developers care to speak
> > out) that this view is shared by many, if not all, developers, and not
> > just in the audio world. Great projects in the open source community
> > usually happen when a motivated individual or group _needs_ something.
> > It is not the needs of the world (usually), or "user demand", or the
> > desire to fill or create a marketing niche, it is their need.
> 
> That is very untrue, and evolution and the motivations behind that app
> prove that.

Awh, rats. Sorry. I read "and _the_ evolution and the motivations
behind" :-)

There are always going to be exceptions you can point to, the open
source world is not monolithic. That does not invalidate what the
developers on lad have said so far of their motivations. So far it is a
small sample, of course. 

-- Fernando

Re: [linux-audio-dev] [OT] marketing hype

[Fernando Pablo Lopez-Lezcano]

> > > On Thu, 2004-06-10 at 00:24, Fernando Pablo Lopez-Lezcano wrote:
> > > > On Wed, 2004-06-09 at 15:26, Marek Peteraj wrote:
> > > > > On Wed, 2004-06-09 at 13:17, Dave Griffiths wrote:
> > > > > > Personally speaking, as a free software developer I don't care if my
> > > > > > programs are deemed as sucessful, they work for me, and handful of other
> > > > > > people - this makes me happy :)
> > > > > 
> > > > > I'd like to see what other developers of the most popular linux audio
> > > > > projects think. 
> > > > 
> > > > Most probably you will find out (when/if other developers care to speak
> > > > out) that this view is shared by many, if not all, developers, and not
> > > > just in the audio world. Great projects in the open source community
> > > > usually happen when a motivated individual or group _needs_ something.
> > > > It is not the needs of the world (usually), or "user demand", or the
> > > > desire to fill or create a marketing niche, it is their need.
> > > 
> > > That is very untrue, and evolution and the motivations behind that app
> > > prove that.
> > 
> > I'm missing something. Which app? What is untrue?
> 
> The email client. Which one are you using?

Evolution. I may be in the wrong thread, was there a discussion about
email clients?

> > What I just wrote? Let the developers speak, please. 
> 
> The devs are themselves users.

And they are speaking. 
-- Fernando

Re: [linux-audio-dev] [OT] marketing hype

[Fernando Pablo Lopez-Lezcano]

On Wed, 2004-06-09 at 17:50, Marek Peteraj wrote:
> On Thu, 2004-06-10 at 00:24, Fernando Pablo Lopez-Lezcano wrote:
> > On Wed, 2004-06-09 at 15:26, Marek Peteraj wrote:
> > > On Wed, 2004-06-09 at 13:17, Dave Griffiths wrote:
> > > > Personally speaking, as a free software developer I don't care if my
> > > > programs are deemed as sucessful, they work for me, and handful of other
> > > > people - this makes me happy :)
> > > 
> > > I'd like to see what other developers of the most popular linux audio
> > > projects think. 
> > 
> > Most probably you will find out (when/if other developers care to speak
> > out) that this view is shared by many, if not all, developers, and not
> > just in the audio world. Great projects in the open source community
> > usually happen when a motivated individual or group _needs_ something.
> > It is not the needs of the world (usually), or "user demand", or the
> > desire to fill or create a marketing niche, it is their need.
> 
> That is very untrue, and evolution and the motivations behind that app
> prove that.

I'm missing something. Which app? What is untrue? What I just wrote? Let
the developers speak, please. So far they are saying what I stated, more
or less. Now, if what the developers themselves say does not matter, or
if you know their (our) minds better than ourselves then this is all
rather pointless. 

-- Fernando

Re: [linux-audio-dev] [OT] marketing hype

[Fernando Pablo Lopez-Lezcano]

On Wed, 2004-06-09 at 15:26, Marek Peteraj wrote:
> On Wed, 2004-06-09 at 13:17, Dave Griffiths wrote:
> > Personally speaking, as a free software developer I don't care if my
> > programs are deemed as sucessful, they work for me, and handful of other
> > people - this makes me happy :)
> 
> I'd like to see what other developers of the most popular linux audio
> projects think. 

Most probably you will find out (when/if other developers care to speak
out) that this view is shared by many, if not all, developers, and not
just in the audio world. Great projects in the open source community
usually happen when a motivated individual or group _needs_ something.
It is not the needs of the world (usually), or "user demand", or the
desire to fill or create a marketing niche, it is their need. They work
on the project because it is fun. Because they want to learn. Sometimes
they do it because they want to give back to the community. If they feel
like it, they will consider suggestions as well, but not always. Their
view of what is best may be completely different from yours, and from
what today's "market" finds fashionable and cool. 

> Because if they share your opinion, i'd rather save some
> bucks and buy myself a mac.

Perhaps you should start saving now? :-)

I have to echo other comments in that I also like the freedom of the
linux or - more generally - open source (audio) world, the
non-hierarchical non-centralized nature of it, the chaos, the lack of
hype, marketing techno-speak and half truths if not outright lies, and
all that. 

You seem to consider all these attributes big failures. 

I don't agree. We don't _have_ to be big, take over the world and "sell"
our "products"[*] like everyone else in the music software and hardware
industry.  

Which does not mean all software and projects are perfect, of course. I
can think of many that could use some improvement :-) 

-- Fernando

[*] there are exceptions, of course, as in everything. Some developers
seem to have the need to push their software and demostrate that it is
better than everything else. To each his/her own. 

RE: [linux-audio-dev] re: [linux-audio-user] A bit of goodnews--paper now available for your viewing pleasure and/or comments

[Fernando Pablo Lopez-Lezcano]

> Hmm, it would be a fun project then to come up with a profiler of various
> audio cards by recording and then capturing a specific buffer of audio data.
> Then by comparing them (assuming that this drift is constant) see how many
> empty samples there are (or if the playback is slower, how many samples are
> missing), and then create a framework that allows real-time resampling in
> order to compensate for that discrepancy whenever multiple soundcards are
> being used :-D

Yes, of course that is doable. I don't think you need to profile them.
Just measure the drift between the hardware pointers for both cards as
you play. 

> Of course this would be relatively pointless as for any serious work one
> should always resort to a better card rather than experimenting with this.
> Nonetheless it may prove to be a fun project sometime down the road ;-)

A long time ago (98/98 or so) I _have_ used two sb128 soundcards without
sample sync to play back four channel pieces under linux. If the cards
are of the same model and manufacturing batch the drift will be small.
Small enough to play a 10 or 15 minute 4 channel piece without clicks[*]
:-)

Guilty :-)
-- Fernando

[*] but either the front or back speakers will slowly drift away from
you as the piece progresses, not a real problem :-)

RE: [linux-audio-dev] re: [linux-audio-user] A bit of good news--paper now available for your viewing pleasure and/or comments

[Fernando Pablo Lopez-Lezcano]

On Fri, 2004-05-28 at 10:55, Ivica Ico Bukvic wrote:
> Hmm, so just for my own understanding of this, if let's say 2 soundcards A
> and B lack sync between themselves, yet are being fed in appropriate
> intervals small buffers of audio data from JACK, what is preventing them
> from staying in sync?

The slower card will have to be fed something other than the source
material from time to time to be able to catch up to the faster one (the
"source" is coming at only one speed from only one place and going to
two different places that need to be fed at slightly different rates).
The "something to be fed" will be probably silence, that is, a click :-)
The size of the buffer and the amount of drift between cards will
determine how often you get a click (if the software would support doing
this at all, of course). 

-- Fernando

Re: [linux-audio-dev] [ANN] 3. Linux Audio Conference 2005

[Fernando Pablo Lopez-Lezcano]

On Sun, 2004-05-16 at 06:53, martin rumori wrote:
> o.k. let's complete it step by step...
> On Sun, May 16, 2004 at 02:32:35AM -0400, Paul Davis wrote:
> > >On Saturday 15 May 2004 16:53, Jack O'Quin wrote:
> > >
> > >> Can you (or anyone) name all the people in this group picture?
> > >>
> > >> http://www.linuxdj.com/audio/lad/contrib/zkm_meeting_2004/photos/frank_neum
> > OK, in the interest of public education here's my still-incomplete
> > list:
> > 
> > BACK ROW:
> >   , Orm Finnedahl
> > 
> > NEXT ROW: 
> >   > harris> >  der pol> >  dipper>
> >  
> > MIDDLE ROW:
> >
> > 
> > FRONT ROW:
> > >neumann> >nettingsmeier>
> > 
> > PENGUIN PROP: 
> 
> just two names more...

three more (I think I'm getting them right)... getting there...
(regretfully many participants had already left by the time the picture
was taken)

-- Fernando

Re: [a-devel] Re: [Agnula-Developers] Re: [linux-audio-dev] Request to audio

[Fernando Pablo Lopez-Lezcano]

On Wed, 2004-05-12 at 10:13, Jack O'Quin wrote:
> Takashi Iwai <[EMAIL PROTECTED]> writes:
> > IMO, the only concern about saying "it's a part of hardware" is that
> > you can redistribute the firmware while you cannot do the hardware.
> > this is the basic difference between hardware and software.
> 
> Depending on how you define the term, I suppose one can freely
> "redistribute" the hardware (give or sell it to someone else).  
> 
> The problem is that you can't easily make a copy.  :-)

And while you can make and distribute copies of the firmware, it has
absolutely no value without the hardware it belongs to (which you have
to own somehow for the firmware to be useful). 

-- Fernando

Re: [Agnula-Developers] Re: [linux-audio-dev] Request to audio related LiveCD packagers

[Fernando Pablo Lopez-Lezcano]

> let me clarify the situation.  there are a couple of different
> questions regarding this:
> 
> 1. is the firmware binary is a program or a data?
> 2. can we force the h/w vendor to show the source code under GPL (if
>exists) in practice?
> 3. if not, shouldn't we change the license to the non-restrictive one?
>which license would be feasible?
> 
> so far, alsa-firmware package is released from the understanding of 1
> as "data".  but if someone insists it as program, yes, it can be a
> problem.

I tend to look at it (very conveniently, of course) as neither. I view
it as part of the hardware device we're dealing with. Without it the
device does not work. It is distributed as a separate file (inside the
driver disk that actually comes with the device) because it is
convenient for the manufacturer for updates, avoiding a flash rom in the
device, and so on and so forth. 

Most probably very few people will agree with this viewpoint :-)
-- Fernando

Re: [linux-audio-dev] regarding mobos and CPUs

[Fernando Pablo Lopez-Lezcano]

On Thu, 2004-05-06 at 07:53, Taybin Rutkin wrote:
> Yes, that was just an autotools problem.  It could have happened to a P4 if jack 
> was built on an AMD box.  It was more of a cross-compilation issue.

Yes, there is no problem with the AMD processors that I know of. This
was a packaging problem triggered by the autotools problem. In essence
the package itself was saying "I can run on any i386 cpu" so that
apt/rpm was happily installing it on a Duron processor (which is
compatible with the i386 instruction set). _But_ the contents of the
package did not agree with the label and I did not catch that before
releasing it :-) The executable itself had instructions that could _not_
execute in the Duron processor (but, for example, they would have worked
fine on more recent AMD processors). So the program segfaulted on
startup with an "illegal instruction" fault. Anyway, just to clarify
things...

-- Fernando

> -Original Message-
> From: Dave Phillips <[EMAIL PROTECTED]>
> Sent: May 6, 2004 11:20 AM
> To: 
>   The Linux Audio Developers' Mailing List <[EMAIL PROTECTED]>, 
>   LAU Mail <[EMAIL PROTECTED]>
> Subject: Re: [linux-audio-dev] regarding mobos and CPUs
> 
> Taybin Rutkin wrote:
> 
> >What is the problem with JACK and AMD cpus?  I haven't heard of one.
> >
> >  
> >
> Not so long ago a release of qjackctl in Planet C failed due to (IIRC) 
> JACK getting compiled with an SSE call (or calls) that killed it 
> completely on my Duron. The problem was simply and quickly solved, and 
> I'm perhaps off-base accusing JACK but that's where the problem came 
> from. Maybe it was a bad make ?
> 
> Anyway, if it's the opinion of the LAD developers that AMD is OK then 
> that's what I need to know. As I stated, I've had only that one 
> difficulty with AMD and Linux audio software, so I think I'm just being 
> paranoid.
> 
> Best,
> 
> dp
> 

Re: [linux-audio-dev] Latest release of FreqTweak

[Fernando Pablo Lopez-Lezcano]

> Anouncing version 0.6.0 of FreqTweak.
> 
>http://freqtweak.sourceforge.net
> 
> New in this release are spectral filter Modulators, which can animate
> and modulate any of the filters automatically in several ways.
> If you thought FreqTweak was fun before, be prepared for hours of
> audio mayhem. 

Arg! I have tons of things I _have_ to do and you come up with this
NOW? :-) :-P :-) 

>  See the webpage (and the software) for details.
> 
> Just in time for the ZKM/LAD conference in Karlsruhe :) 

Yeah, and now I will have less time to prepare... :-)

> Please report any problems compiling this release on your various
> platforms to me, and as always report any bugs or feature requests to
> [EMAIL PROTECTED] (you must subscribe first).

Feature request... an option to make the randomization +/- to what the
current curve is set to (so that bringing "Max Val" down to 0 leaves the
original curve untouched). 

Very neat... will be in the Planet CCRMA repository very soon. 
-- Fernando

Re: [linux-audio-dev] jack_fst: a JACK client to run VST's

[Fernando Pablo Lopez-Lezcano]

On Mon, 2004-04-19 at 13:11, Paul Davis wrote:
> Torben Hohn and I are pleased to announce the initial release of
> jack_fst, a small JACK client designed to run VST FX and VST/i's with
> connections to the rest of the JACK world, and, for VST/i's the ALSA
> sequencer. 
> 
> Tarball is available at: 
> 
>   http://linuxaudiosystems.com/fst/jack_fst-1.2.tar.gz
> 
> You will need the recently announced FST, a recent version of Wine,

Can you elaborate in terms of which version of wine you have used
successfully? (ie: wine = x.y.z or wine >= x.y.z?)

-- Fernando

Re: [linux-audio-dev] caps 0.1.0

[Fernando Pablo Lopez-Lezcano]

On Wed, 2004-02-18 at 12:50, Tim Goetze wrote:
> >I read:
> >> can you try the attached patch please?
> >
> >works with gcc-3.2, but not 3.3:
> >In file included from Eq.h:4,
> > from Eq.cc:31:
> >dsp/Eq.h:167:46: missing terminating " character
> >dsp/Eq.h:181:57: missing terminating " character
> >dsp/Eq.h:185:46: missing terminating " character
> >dsp/Eq.h:194:57: missing terminating " character
> >dsp/Eq.h:199:38: missing terminating " character
> >dsp/Eq.h:205:82: missing terminating " character
> >make: *** [Eq.o] Error 1
> 
> ah, glad to hear it gets better, thanks.
> 
> to cure this, can you try the patch attached please?

With the two patches (patch and patch-two) it builds on RH9, RH8.0,
RH7.3 and FC1 (woohoo! :-)

I get this warning:
Reverb.cc: In constructor `Plate::Plate(double)':
Reverb.cc:232: warning: passing `double' for argument 2 of `void
   ModLattice::init(int, int)'
Reverb.cc:233: warning: passing `double' for argument 2 of `void
   ModLattice::init(int, int)'

Two details. A "make clean" leaves the sources in a non-compilable
state, a subsequent make gets me this:

make: *** No rule to make target
`/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include/stddef.h', needed by
`Cabinet.o'.  Stop.

The location of ladspa.h is assumed to be /usr/local/include, that is
not true on my systems (/usr/include). Not a big deal, easily fixed by
redoing the link at build time. 

-- Fernando

Re: [linux-audio-dev] caps 0.1.0

[Fernando Pablo Lopez-Lezcano]

> >>pleased to announce the initial release of the caps audio plugin
> >>suite under the GNU public license.
> >>
> >>quoting http://quitte.de/dsp/caps.html :
> >
> >% make
> >make: *** No rule to make target `ladspa.h', needed by `dep'.  Stop.
> 
> sorry, and thanks.
> 
> $ cd caps-0.1.0
> $ wget -O - http://www.ladspa.org/ladspa_sdk/ladspa.h.txt > ladspa.h
> 
> or download version 0.1.1 (up now).

Using 0.1.1 (tried on redhat 9 and fedora core 1):

g++ -Wall -O6 -ffast-math -funroll-loops -march=`uname -m` -mcpu=`uname
-m`  -I/usr/local/include -DVERSION=\"0.1.1\" -I/usr/local/include -c
Cabinet.cc
Descriptor.h: In member function `void Descriptor::autogen() [with T
=
   Cabinet]':
Cabinet.cc:168:   instantiated from here
Descriptor.h:36: type `Cabinet' is not a base type for type `
   Descriptor'
make: *** [Cabinet.o] Error 1

-- Fernando

Re: [linux-audio-dev] swh-plugins, freqtweak, fftw3 and the planet

[Fernando Pablo Lopez-Lezcano]

> i was trying to install swh-plugins and freqtweak on my new laptop and
> ran into some problems with the planet's rpms. 

Using apt? Weird...

> they seem to depend on
> a feature "libfftw3f.so.3" that isn't being supplied by any other
> package. i have fftw3 installed, and it gave me the file
> /usr/lib/libfftw3.so.3, but not the "f" version. 

Hmmm, the Planet CCRMA package? Probably not... do an rpm -q fftw3 and
post the result. Or rpm -q -i fft3 to see a bit more about the package's
origin. 

> the same problem
> exists for the planet's freqtweak package.

Freqtweak wants:
  $ rpm -q --requires freqtweak|grep fft
  libfftw3f.so.3

And that is provided by:
  [EMAIL PROTECTED] nandol]$ rpm -q --whatprovides libfftw3f.so.3
  fftw3-3.0.1-1.rhfc1.ccrma

(or the equivalent rh90|rh80|rh73 package). 
Could you send me the output of "apt-get install freqtweak"? It should
download and install the proper package. Unless the fftw3 package you
have has a "higher" version number and then I would recommend force
erasing it and reinstalling from the Planet CCRMA repository only
(unless that breaks something - welcome to the multiple packagers for
the same package hell :-). 

-- Fernando

Re: [linux-audio-dev] Linux Security Module for realtime audio

[Fernando Pablo Lopez-Lezcano]

> > The load time access is not so bad.  You can rmmod and then reload the
> > LSM if you want to change its parameters.  I've been doing that a lot
> > for testing.  This has no effect on processes that are already
> > running.
> 
> thats why i dont consider it necessary. what do you need the proc entry
> for fernando ?

Just asking, I guess it is not really needed, just unloading and loading
should be enough. It would be nice to have some sort of confirmation
from /proc that the module is there and which options are active. Maybe
that information is available somewhere after the module is loaded. 

-- Fernando

Re: [linux-audio-dev] Linux Security Module for realtime audio

[Fernando Pablo Lopez-Lezcano]

> > The "sgid approach" is in addition to having a realtime group or
> > instead? I have the feeling I have missed something in the thread. 
> 
> The setgid approach *is* a match on the realtime group.  The question
> is which of several group IDs to you actually match against.  Torben's
> jackcaps-0.2 checked only the effective group ID of the exec file.
> 
> My current version checks others, too: the user's real and
> supplementary groups.  Note that these are set by login, newgrp,
> etc. and are independent of the actual program being loaded.

Thanks for the clarification, I was getting confused... so the GTK
problem only happens if you try to tag executables only for realtime
access. 

> I'll append a copy to this message, so you can look at it.  It's not
> ready to release yet.  But, it seems to work for me.

I'm not yet testing 2.6.0 (well, I just booted it once a couple of days
ago). Is there anything being done for 2.4.x?

> My current prototype is called `realtime', not `jackcapabilities', and
> has the following load-time options..
> 
>   # modprobe realtime   # `jackstart' capabilities only

Meaning?

>   # modprobe realtime any=1 # option a)
>   # modprobe realtime gid=29# options b) and c)
> 
> I plan to to add another option, mlock=0, for people who don't feel
> the need for locking storage.  With this option, I would only grant
> CAP_SYS_NICE. 

Sounds good to me. Is it possible to control the options through /proc
as well? Or just at load time?

-- Fernando

Re: [linux-audio-dev] Linux Security Module for realtime audio

[Fernando Pablo Lopez-Lezcano]

> > > So, I modified Torben's LSM to check supplementary groups, and this
> > > seems to work fine.  From a system admin perspective it's pretty good.
> > > I'm a member of group `audio', which was accomplished by adding my
> > > user ID (joq) to the appropriate entry in /etc/group...
> > > 
> > > [...]
> > 
> > well this is an alternative but i would be happier to explicitely give
> > away the DOS privilege to programs. rather than enabling it for my
> > account.
> 
> I completely agree that my supplementary groups idea is less secure
> than the setgid approach.

The "sgid approach" is in addition to having a realtime group or
instead? I have the feeling I have missed something in the thread. 

I would prefer to have the option of:

a) no protection: I turn on "realtime" (/proc control and/or loading the
   realtime module, right?) and any user can run any program and crash
   the system by hogging the cpu in a tight loop :-)

b) a group of users: only users in a designated group can crash the
   system. 

c) a group of programs: only writers of realtime "approved" programs get
   a chance (through the help of any user or users in a group) to crash
   the system. 

Most probably in my environment I would use a), maybe b), most probably
not c). 

-- Fernando

Re: [linux-audio-dev] Linux Security Module for realtime audio

[Fernando Pablo Lopez-Lezcano]

> > > attached is what i have done today works, but needs to
> > > be checked by someone who can judge about the sideeffects.
> > > 
> > > i am not so sure about them.
> > 
> > Encouraged by your success, I plan to modify this LSM to implement the
> > `kernel/realtime' and `kernel/realtime-group' interfaces we discussed
> > recently.  I'll keep you posted on how that progresses.
> 
> the most simple way would be parameters given to the module for the
> realtime group and user. There are nice macros for module parameters.
> 
> i believe that adding to the currently overridden function
> 
> if( bprm->e_gid == realtime_gid ) {
>   bprm->cap_effective = CAP_IPC_LOCK | CAP_SYS_NICE | CAP_SYS_RESORCE
>   bprm->cap_permitted = CAP_IPC_LOCK | CAP_SYS_NICE | CAP_SYS_RESORCE
> }
> 
> should work fine.
> 
> although i am not happy with CAP_SYS_RESOURCE ( needed for RTC interrupts > 64Hz )
> which also allows a process to Override quota limits.

This was needed to make mlockall work (on 2.4.x). CAP_IPC_LOCK was not
enough, I don't know why. We tried removing it and memory locking broke.
Is this on 2.6? Maybe it is different. 

Re: the rtc clock, in 2.4 there is a /proc/sys/dev/rtc/max-user-freq
control file that can be used to rise the maximum rtc clock frequency a
normal user can set. 

> But because in drivers/char/rtc.c the check is
> if ( capable( CAP_SYS_RESOURCE ) ) { allow higher freq }
> 
> it seems like its not possible with the current implementation.
> but we could however provide a jackrtc module which checks for a
> new CAP_RTC_INTS. 

-- Fernando

Re: [linux-audio-dev] Re: POSIX caps/realtime/root processes

[Fernando Pablo Lopez-Lezcano]

> The Linux Security Module (LSM) interface is a standard part of 2.6.
> There actually is a backport of the security modules patch to 2.4 on
> the NSA site for SELinux.  But, it is quite large and I doubt many
> people would want to apply it for running realtime audio.

It depends on whether it interacts with other patches... But yes, I
would prefer not to have to add YAP (yet another patch? :-)

> Your small patch is probably safer and more secure.
> So, my feeling is that the best approach is...
> 
>   (1) LSM for 2.6.  
>
>   (2) An interface-compatible variant of your patch for 2.4.  

I agree, looks good to me. 

> I intend to continue experimenting along these lines until I prove to
> myself that all this really works and is useful.  So, far it looks
> encouraging.

Indeed... thanks for working on this! A LOT!
-- Fernando

Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

[Fernando Pablo Lopez-Lezcano]

On Mon, 2003-11-17 at 23:22, Roger Larsson wrote:
> On Tuesday 18 November 2003 02.41, Jack O'Quin wrote:
> > Fernando Pablo Lopez-Lezcano <[EMAIL PROTECTED]> writes:
> > > > - Can not provide mlockall since it has no pid parameter - the
> > > > monitor can't do it for another process. (I would say that it is
> > > > unlikely that pages used in a tight audio loop would be thrown out
> > > > - big buffers might...  Add additional page reads?)
> > >
> > > Well, I'd say this is the showstopper. We really need this. "Unlikely"
> > > is not enough. Eventually memory will run out and the wrong page will
> > > fault and we get a click. We have to be able to lock memory..
> >
> > Agreed.  IMHO, mlock() is mandatory, certainly for JACK applications.
> 
> Problem is - why doesn't most distributions even ship with wrappers suid
> to be able to start the application with SCHED_FIFO/RT/mlock?
> - It is due to risks of local Denial Of Service attacks (intentional or
>   unintentional)

That's one reason why you won't see this done on any general purpose
distribution. Another reason: most (all?) mainstream distributions do
not cater to the "pro audio" users that need very reliable and very low
latency operation. Yet another: it is difficult :-)

> So with any scheme that opens up these holes you have to deliver a way
> to protect from the downsides.

Or not. Sometimes you have to learn to live with them...

> My monitor protects from CPU overuse, but what about memory?
> How to protect from an application that mlockall(MCL_FUTURE) and
> has a memory leak?

Good point. Probably you can't :-(

> One important thing to remember - if you like to get broad acceptance
> you have to suggest a solution that solves these problems. I would say
> that the rt_monitor or some other means to do the same thing is
> mandatory to get that kind of acceptance.

I don't (personally) want or need at this point in time for the solution
to have "broad acceptance", although that would be real nice. I want
something that enables me to run applications with real time priority
and memory lock as a normal user. So far the options that target both
aspects (scheduler and memory lockdown) involve a kernel patch. 

> > The big difference between realtime and most other kinds of
> > performance work is that it focuses on tuning the "worst case", not
> > the average.  Paging works fine on average, but in the worst case your
> > recording session gets blown.
> 
> SCHED_FIFO does not make ANY guarantees on "worst case"!

Correct. We do have xruns every once in a while, it depends a lot on the
hardware and how the system is tuned. If we get real serious, from the
point of view of "worst case", linux is the wrong tool to do realtime
audio processing. Something like QNX would be better (a _real_ realtime
operating system). 

> > Otherwise, a good solution.  Perhaps adequate for some applications.
> 
> But at the same time SCHED_FIFO is adequate for most applications.
> See my point? :-)

I see your point. There is no clearly marked dividing line in either
case. For a certain very high latency requirement SCHED_OTHER, in the
average, is just fine. For the latency expectations of most people in
this list SCHED_FIFO is a good solution (if the kernel is patched for
low latency operation - otherwise it does not work either). If you
really go down in latency, SCHED_FIFO is no longer good enough. This
part at least is clear to me (we _need_ SCHED_FIFO), but equally clear
is the fact that it will not _always_ work (100% of the time). 

So the question about mlockall would be, is it something akin to
SCHED_OTHER? (ie: with it the whole thing is unusable?). Or is it like
SCHED_FIFO? (ie: not 100% perfect but we really need to have it?). 

My feeling is that we need it, but I don't have experimental data to
back it up. 

Any one out there doing experiments with this? Something like: start a
critical audio app with and without mlockall, subject the machine to
high memory loads to force paging (ie: start a lot of applications), see
what happens. 

Of course there does not have to be just _one_ answer to the question!
Let's implement both and let the user choose according to his/her/its
needs :-)

-- Fernando

Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

[Fernando Pablo Lopez-Lezcano]

On Mon, 2003-11-17 at 19:59, Jack O'Quin wrote:
> To summarize, my proposal is:
> 
>   sysctl -w kernel/realtime=0   # disable realtime privileges
> 
>   sysctl -w kernel/realtime=1   # enable realtime privileges
> #   for `root' group
> 
>   sysctl -w kernel/realtime=1   # enable realtime privileges
>   sysctl -w kernel/realtimegroup=-1 #   for every process
> 
>   sysctl -w kernel/realtime=1   # enable realtime privileges
>   sysctl -w kernel/realtimegroup=29 #   for `audio' group
> 
> Only root can write these variables.  If possible, let's agree on a
> standard gid to use for group `realtime', there isn't one now.

Sounds good to me...

Here's a list of uids/gids as used in RedHat (courtesy of Matthias):
  http://freshrpms.net/packages/res/uidgid.html
I seem to remember having read somewhere of an initiative to standarize
all these numbers, can't remember where or when. 

-- Fernando

Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

[Fernando Pablo Lopez-Lezcano]

> > > i'd be interested to hear from fernando about this kind of thing. many
> > > of us on LAD work on what are to all effects and purposes single user
> > > machines. i'd like to hear how policies like 1-4 above, or others,
> > > appear in the context of an academic "shared resource" environment.
> >
> > ["academic" is probably irrelevant, a commercial studio should see the
> > advantages of the security model if educated]
> >
> > As far as I understand these are the current options:
> >
> > a) capabilities
> > b) simple sysctl patch to the kernel (like the one that Kjetil posted)
> > c) security module, with possible additional control through sysctl
> 
> What about:
> d) redefining sched_setscheduler using LD_PRELOAD with running rt_monitor

Yes, sorry, I forgot about this one... (you posted it no long ago). 

> + No change in kernel.
> + No change in application code. (Like capabilities - do not check uid, 
>   but it can fake uids too!)
> + Can use whatever kernel provides
> + Only requires the rt_monitor to be started by root - can be done by init

Not a problem so far (but I don't like to use LD_PRELOAD at all, just a
personal preference). 

> + Protects the system from overuse (and lockups) due to bugs in code.

Very good. 

> - Can not provide mlockall since it has no pid parameter - the monitor
>   can't do it for another process. (I would say that it is unlikely that pages
>   used in a tight audio loop would be thrown out - big buffers might...
>   Add additional page reads?)

Well, I'd say this is the showstopper. We really need this. "Unlikely"
is not enough. Eventually memory will run out and the wrong page will
fault and we get a click. We have to be able to lock memory..

BUT, I think a userspace daemon that starts at boot time and protects
against lockups (rt_monitor) would be a very good thing to have. 

-- Fernando

Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

[Fernando Pablo Lopez-Lezcano]

On Mon, 2003-11-17 at 08:17, Jack O'Quin wrote:
> Right.  There actually is a backport of the security modules patch to
> 2.4 on the NSA site for SELinux.  But, it is rather large and I doubt
> many people would want to apply it.

I would say that for 2.4 a simple patch would be easier. I'm a bit tired
of hard to (re)apply kernel patches :-)

> > I would be happy with "b" right now. A group would not be important in
> > _my_ setup, all my users are "audio users", all users can hang the
> > machine (I have too much to do to try to start categorizing users :-)
> 
> > I would say (as in Kjetil's patch):
> >   echo "0">/proc/sys/kernel/setschedandmlock
> >   --> normal behavior
> 
> I suggest picking a clearer name, like /proc/sys/kernel/realtime.

I agree, sounds better. It does not say what it does as the original
proposal, but maybe we will need something else in the future that could
be done through this as well. 

> >   echo "1">/proc/sys/kernel/setschedandmlock
> >   --> access to mlock and SCHED_FIFO and:
> >  echo "xx">/proc/sys/kernel/setschedandmlockgroup
> >  --> only users in group "xx" can access privileges
> >  default for "xx" would be "0" which means everybody
> 
> Here, I suggest something like /proc/sys/kernel/rtgroup.  

Maybe "realtimegroup"? I kind of like the same "root" for both options,
it groups them together. 

> Also, 0 is a valid group ID, `root', which might be a reasonable
> choice if groups like `audio' and `realtime' are undefined.  How about
> using -1, instead?  Or, maybe `nogroup' (65534 on my system).

Yes, probably "nogroup" is the best option. I think it is "nobody" in my
system - so we cannot rely on the same name either... yuck...

> So, I'm thinking we could provide these sysctl interfaces on both 2.4
> and 2.6, though via different mechanisms...
> 
>   (1) `kernel/realtime' works as in Kjetil's patch
>   (2) `kernel/rtgroup' further restricts access
> 
> Kjetil's patch could be expanded to include (2), providing consistent
> interfaces across kernel versions.  Assuming that's agreeable with
> him, of course.  :-)

I hope so...
Looks good to me. 
-- Fernando

Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

[Fernando Pablo Lopez-Lezcano]

On Sun, 2003-11-16 at 08:02, Paul Davis wrote:
> >> I've been thinking about ways to use this feature to improve and
> >> simplify the current security situation for Linux audio.  No
> >> conclusions, but here are some thoughts for discussion:
> >>
> >>   (1) There should a simple way for the sysadmin to reliably disallow
>[ .. ]
> >>   (2) Using sysctl, set a group id (like `audio') for which realtime
> [ ... ]
> >>   (3) We could also define a default realtime group (gid 0 maybe),
> 
> >What about this one:
> >
> >(4) Let the user that is currently physical logged in to the machine
> >get realtime privileges.
> 
> i'd be interested to hear from fernando about this kind of thing. many
> of us on LAD work on what are to all effects and purposes single user
> machines. i'd like to hear how policies like 1-4 above, or others,
> appear in the context of an academic "shared resource" environment.

["academic" is probably irrelevant, a commercial studio should see the
advantages of the security model if educated]

As far as I understand these are the current options:

a) capabilities
b) simple sysctl patch to the kernel (like the one that Kjetil posted)
c) security module, with possible additional control through sysctl

"b" is better than "a" (more general purpose)
is "b" riskier than "a"?
  you could say yes: all programs can use realtime caps
  you could say no: "a" enables additional unneeded and dangerous stuff
"c" is the same as "b" (from the point of view of a user or sysadmin)
"c" has more long term potential in the sense that it uses a recognized
kernel interface to security (but only on 2.6, right?)

I would be happy with "b" right now. A group would not be important in
_my_ setup, all my users are "audio users", all users can hang the
machine (I have too much to do to try to start categorizing users :-)

I would say (as in Kjetil's patch):
  echo "0">/proc/sys/kernel/setschedandmlock
  --> normal behavior

  echo "1">/proc/sys/kernel/setschedandmlock
  --> access to mlock and SCHED_FIFO and:
 echo "xx">/proc/sys/kernel/setschedandmlockgroup
 --> only users in group "xx" can access privileges
 default for "xx" would be "0" which means everybody

as to (4), it could be useful but I doubt you can easily determine from
inside the kernel that a user is "local" (just guessing). 

> ps. this is the kind of thing that can really distinguish *nix from
> other systems. i've heard from at least academic music department
> about the problems they've faced since being forced to switch to
> windows. 

I would not want to be in that position... 
-- Fernando

[linux-audio-dev] Re: [Jackit-devel] Re: POSIX caps/realtime/root processes

[Fernando Pablo Lopez-Lezcano]

> Paul Davis:
> > >Since mainstream capabilities support seems always to be somewhere
> > >over the horizon, I am interested in the patch Paul and Steve
> > >mentioned.  IIUC, it defines a control file in /proc which, if
> > >enabled, allows any process access to scheduling and memory locking
> > >privileges.  No other capabilities are provided.  I would love to see
> > >a copy of this patch to study exactly what it does.
> >
> > its a very simple patch, IIRC. it just short-circuits the checks on
> > uid==0 and/or capabilities when assigning SCHED_FIFO and/or locking
> > memory.
> >
> > i'm looking for it in my archives. i'm a bit worried i may have
> 
> I couldn't wait til you found it, so I wrote one from scratch instead. :)
> The url below point to a hackish patch againt 2.4.23-rc1, and yes, it is
> very simple. Works by setting /proc/sys/kernel/setschedandmlock to 1.
> http://www.notam02.no/arkiv/src/schedmlockpatch-2.4.23-rc1

Hey! Good! I'm very tempted to add it to the Planet CCRMA kernels right
away :-)

Has it seen much testing? Not that something so simple would require a
lot of testing, of course. I'm trying to think of potential problems
(over the use of capabilities) and can't think of anything. The only
that would occur to me is that access to SCHED_FIFO would be more
universal whereas with capabilities, programs like givertcap or
jackstart are required. 

-- Fernando

Re: [linux-audio-dev] Just for fun - Hearnet

[Fernando Pablo Lopez-Lezcano]

> > This is a little toy I hacked up while learning the Jack API today. It
> > is not sophisticated, it is hackish, and it is probably not really doing
> > precisely what I intended it to do.  But it's fun. It does a simple form
> > of granular synthesis: it plays a grain for every incoming packet in
> > realtime.
> > 
> > Requires libpcap and libjack (of course).
> > 
> > http://falcon.fugal.net/~fugalh/hearnet/
> > 
> > Feedback is welcome.
> 
> :-D
> 
> to further boost the uselessness of this wonderful thing, how about 
> mapping different grains to protocol, port numbers and direction?
> 
> just imagine:
> 
> # ping somehost
> ping ... pong ... ping ... pong ... ping ...pong
> or even
> # ping -f somehost
> pgniogingpgnigongpgignpgoigpnigiongpgnogignpgipgnpoingopingopngignoin
> 
> soon we will see network operators starring at contemporary music festivals.
> 
> ;)

Done by Chris Chafe :-) ;-) :-)
See http://www-ccrma.stanford.edu/~cc/sfmoma/topLevel.html
(pretty picture at:
 http://www-ccrma.stanford.edu/~cc/sfmoma/LAtimesGraphic.jpeg)
And/Or http://www-ccrma.stanford.edu/groups/soundwire/

-- Fernando

Re: [linux-audio-dev] EU software patents?

[Fernando Pablo Lopez-Lezcano]

> > Hello. Can anyone report what is going on with the EU software patents?
> > How they would affect immediately the audio and graphics development
> > we are doing? Xine? Sodipodi? Others?
> 
> I suppose you wouldn't be allowed to control one oscillator's
> frequency with the output of another oscillator using more than about
> 10 Hz because that is Frequency Modulation and Yamaha has a patent on
> that. But I'm no lawyer.

The FM patents expired a while ago... I may be _completely_ wrong but I
seem to remember they did not cover the principle of fm for audio
synthesis but a certain implementation in hardware. 

-- Fernando

Re: [linux-audio-dev] [OT] Re: KEYBOARDS: Linux is not suited for audio applications ...

[Fernando Pablo Lopez-Lezcano]

> >>Sorry, off-topic but funny.
> >>
> >>I searched for "PlanetCCRMA" in Google, and I got this suggestion:
> >>
> >>"Did you mean: Planetcrap"
>
> you _have_ to click on "I'm Feeling Lucky" button :)

I did that with some (ahem, actually a lot) hesitation. And I breathed a
sigh of relief (I had pictures of this whole thing going rapidly
downhill :-)

-- Fernando

Re: [linux-audio-dev] wxWindows and Linux distros ?

[Fernando Pablo Lopez-Lezcano]

> > >Which Linux distributions include wxWindows in their default
> > >installations ?
> > 
> > used it on Debian and Gentoo so far, works nice.
> > 
> > More here: http://www.wxwindows.org/distros.htm
> > 
> > not sure if this is up to date however
> 
> According to the responses I've collected so far it seems it's a little
> out of date.
> 
> My thanks to all who replied. It seems that it's a standard package with
> most of the mainstream distros, with the interesting exception of Red
> Hat. I haven't upgraded for quite a while, and wxWindows was not
> included with my ancient 7.2 install. Is it not in 8.0 or 9.0 either ?

Nope, it is not there either. But it is part of Planet CCRMA...
-- Fernando

Re: [linux-audio-dev] calling all planet ccrma users ...

[Fernando Pablo Lopez-Lezcano]

> >Don't run up2date, just use apt. There should be a full set of updates
> >for redhat in the apt index on CCRMA's servers.
> >
> >apt-get update
> >apt-get dist-upgrade
> >
> >Do this in between the "install apt on your RH box" and "install Planet
> >CCRMA magic kernel RPM package" steps.
> 
> yes, but i'm connected to CCRMA by a 56kB dialup, and using apt for
> this is not really feasible ... i've collected all the pieces i need
> for ardour step by step, and eventually i'll use a friend's cable
> modem to get the ISO's.

A cable modem is your friend (or is it the other way around?). Planet
CCRMA does not really work over dialup unless you are VERY patient...

-- Fernando

Re: [linux-audio-dev] calling all planet ccrma users ...

[Fernando Pablo Lopez-Lezcano]

> >From looking at the date I'd guess it comes from up2date, which is
> >included in planet.
> 
> yeah, but you can't use up2date on a machine not connected to the
> internet. so a machine configured without being updated (i.e. not
> really 8.0 anymore) doesn't have glibc 2.3. i supposed RH are defining
> 8.0 as "8.0 plus any updates we say are part of 8.0 ...". sigh.

Hmmm, no, I sort of define it that way because I build all new packages
with all the redhat updates installed (up to that point in time). 

You do not really need to have network connectivity for the updates if
you dowload the updates iso cdrom for rh8, it should include all the
needed stuff. 

> i rebuilt the RPMs from nando's SRPMs. 
> 
> and now i just found out that i have a brand new Hammerfall DSP with a
> revision number not recognized by the driver. this means i would have
> to install the entire kernel source RPM (27MB!) from the planet, plus
> the alsa kernel SRPM, edit the source code, and then rebuild ALSA (you
> can't rebuild ALSA without the relevant kernel source installed). sigh
> again, doubled.

Welcome to the club! (of people rebuilding things for the nth time and
saying "sigh"...)

> still, at least i can justify being paid to do this :) and i have to
> say that the Linux Audio Systems splash screens for Grub and for GDM
> look pretty nice! i get a warm feeling inside seeing these things on
> such a superb machine :)
> 
> i guess i should get it connected to the net, and run up2date as well,
> eh? 

Or point to the Planet CCRMA repository and get the updates from there.
All the same. 

-- Fernando

RE: [linux-audio-dev] New form of GPL licence that protects Linuxfrom proprietary world [was: New powermacs?]

[Fernando Pablo Lopez-Lezcano]

On Mon, 2003-06-23 at 10:59, Ivica Bukvic wrote:
> > It is important to note some of Apple's contributions to the open
> > source community besides darwin.
> 
> Darwin was not developed by Apple. It's originally a project that was
> developed on Intel machines. Apple took it on since it had an acceptable
> license (BSD).

I think the chain is somewhat longer (for the kernel):
  *bsd* (don't remember which one - mach kernel)
  -> NeXTstep (initially only m68k, proprietary hardware)
  -> NEXTSTEP (i386, ordinary pc's + sparc + hp + m68k)
  -> OpenStep (i386/m68k - don't remember when the others got dropped)
  -> Rhapsody (sp?)
  [NeXT is bought by Apple - or was this before Rhapsody?]
  -> Darwin

-- Fernando

RE: [linux-audio-dev] New form of GPL licence that protects Linuxfrom proprietary world [was: New powermacs?]

[Fernando Pablo Lopez-Lezcano]

> Software would remain open-source. But the assumption is if you are
> willing to part with the freedoms Linux and other GNU OS's offer, and
> pay for a costlier system, as well as a bunch of shrink-wrapped apps,
> then you might as well pay for the oss apps and help the oss community.
> No one would switch to Apache in the first place were it not better than
> the closed-source solutions. By the same token if I have a killer audio
> app, they would either pay for it for their OS or switch to Linux or any
> other oss OS and enjoy the freedom. It's a bit pushy tactics, but that's
> exactly what our competition is doing, and doing it rather well.

Do we want to _become_ what our "competition" is? I don't think so. I
don't like pushy tactics. We are (by some measure) successsfull because
we are not like the "competition".  

> > you don't put a 'no gurls allowed' sign on your clubhouse and then
> > complain about how no hot chicks ever show up. (ohhh that was probably
> > offensive, but i think it's a fantastic metaphor ... for something).
> 
> Wrong analogy. To use your context (as funny as it seems :-), I would
> put 'no gurls allowed without paying' on a clubhouse that has a
> covercharge. Then, next to it would be a clubhouse that is free for both
> boys and girls. Pop quiz: Where would the girls go?

[just to keep banging on a bad analogy :-] My guess is that they would
go to the one that is "cool" (whatever is cool at the moment). If the
one that is not free is the one where the "cool" crowd hangs out, they
will pay. And you will have a free but empty clubhouse (well, not really
empty, a few geeks will be there talking about cool software... and yes,
I would end up there as well :-). Of course it might also happen that
the cool clubhouse is the one that is free, but don't take that as a
given. 

Anyway, I don't think acceptance of the os will ever come from twisting
arms. Users will use the os that meets their need. Actually, most users
will use the os that comes with the machine they bought. Tying the use
of a free cool app to running it in the free operating system so that
users will switch will not work (I think). If the os they use does not
come with the coolest tools (BTW, their idea of cool may be different
from ours), and they are not available in "free" versions because of
licensing issues they will just not use them and will use whatever else
is available (free or not).

-- Fernando

Re: [linux-audio-dev] latency and P4 hyperthreading?

[Fernando Pablo Lopez-Lezcano]

> > The problem is not speed but latency glitches. It certainly should be
> > slower than a "real" dual cpu system but it could be slightly faster
> > than the same uniprocessor machine with ht turned off. Of course if you
> > have latency problems it is not very useful. 
> 
> I think its a better win if the kernel understands HT, 

I thought it did, obviously it does not (completely). 

> I have a smp ht
> machine and big parallel therads sometime get stuck on different threads of
> the same cpu, instead of different cpus. If I had no HT in those cases it
> would be faster.

Ha! So I was not imagining things. I had some weird problems when trying
to run jack (but I was distracted with the latency issues so I did not
pay much attention - one problem at a time) so most probably that is the
reason. 

I guess we'll have to wait till the kernel catches up...
-- Fernando

Re: [linux-audio-dev] latency and P4 hyperthreading?

[Fernando Pablo Lopez-Lezcano]

> How does the P4 machine compare against itself with hyperthreading turned
> off?

The latency is fine (when booting into a up kernel). I did not run
generic benchmarks for testing speed. There is a gain but it is not that
much (from benchmarks I've seen on the web). 

> I'm not surprised that hyperthreading is slower than a true dual CPU setup.
> Two CPUs sharing their cache?  That's got to increase cache misses.

The problem is not speed but latency glitches. It certainly should be
slower than a "real" dual cpu system but it could be slightly faster
than the same uniprocessor machine with ht turned off. Of course if you
have latency problems it is not very useful. 

-- Fernando

> ---Original Message---
> From: Fernando Pablo Lopez-Lezcano <[EMAIL PROTECTED]>
> Sent: 06/02/03 09:05 PM
> To: [EMAIL PROTECTED]
> Subject: [linux-audio-dev] latency and P4 hyperthreading?
> 
> > Hi all, has anyone tested latency on a P4 machine with Hyperthreading
> support? (HT simulates two processors on one processor using - I guess -
> the spare time available in the cpu when it is waiting for, for example,
> memory accesses). 
> 
> Anyway, on a:
> P4 2.4G 800MHz fsb, 875P chipset, 1G ram, Seagate Barracuda V 60G drive:
> 
> Booting into an smp kernel with HT enabled in the bios (kernel based on
> 2.4.21-rc6 with the usual low latency, preemptive and full acpi kernel
> patches) I see both processors, but the latency in the disk tests (using
> latencytest 0.42) has spikes that go up to 10/15 msecs, specially in the
> read/write test. 
> 
> If I boot into a up kernel, or if I boot with acpi=off I see only one
> processor and the latency for the disk tests is fine. 
> 
> Same kernel, same alsa on a dual Athlon MP 1800+ machine does not show
> any abnormal latency behavior so this seems to be confined to HT
> machines... :-(
> 
> I guess "made up" processors are not as good as real ones :-)
> -- Fernando

[linux-audio-dev] latency and P4 hyperthreading?

[Fernando Pablo Lopez-Lezcano]

Hi all, has anyone tested latency on a P4 machine with Hyperthreading
support? (HT simulates two processors on one processor using - I guess -
the spare time available in the cpu when it is waiting for, for example,
memory accesses). 

Anyway, on a:
P4 2.4G 800MHz fsb, 875P chipset, 1G ram, Seagate Barracuda V 60G drive:

Booting into an smp kernel with HT enabled in the bios (kernel based on
2.4.21-rc6 with the usual low latency, preemptive and full acpi kernel
patches) I see both processors, but the latency in the disk tests (using
latencytest 0.42) has spikes that go up to 10/15 msecs, specially in the
read/write test. 

If I boot into a up kernel, or if I boot with acpi=off I see only one
processor and the latency for the disk tests is fine. 

Same kernel, same alsa on a dual Athlon MP 1800+ machine does not show
any abnormal latency behavior so this seems to be confined to HT
machines... :-(

I guess "made up" processors are not as good as real ones :-)
-- Fernando

Re: [linux-audio-dev] new realtime scheduling policy

[Fernando Pablo Lopez-Lezcano]

> using SCHED_(USER)?FIFO makes no sense if you do not also call
> mlockall(2). both (scheduling+memory pinning) are inaccessible without
> root or CAP_SYS_RESOURCE capabilities. i think that a very useful
> patch would be one that used /proc/sys/kernel/rtperm (or some similar
> name) to turn on or off the ability of regular processes to acquire
> these "resources". this would then allow us to use SCHED_FIFO,
> mlockall(2) and any future SCHED_.+FIFO policies without the absurd
> hoops that many people have to jump through at the moment.
> 
> it would be a very simple patch, i believe, touching just 2
> non-hotspots in the kernel. and credit should be given to whoever it
> was in the audience who suggested using /proc ... that wasn't really
> my idea at all.

Wasn't it Kai Vehmanen? 
-- Fernando

Re: [linux-audio-dev] Linux Audio Hardware Selection

[Fernando Pablo Lopez-Lezcano]

> >(btw, why jackd doesn't read /etc/jackrc or ~/.jackrc ?)
> 
> because that means we have a config file, which means we need a config
> file parser, which means we need to replicate a bunch of code or link
> against another library. if jackd was a commonly executed command for
> users, i could justify that. as it is, i can't.

I would support adding another library. I think both system and user
configuration files add a lot to the usability department. 

BTW, the standalone non-jackd libjack sounds like a very good idea!
-- Fernando

Re: [linux-audio-dev] RE: [Jackit-devel] Re: k_jack v0.0.0.5

[Fernando Pablo Lopez-Lezcano]

> I'll still put Jack in the console, I think, to keep it off my desktop, and
> just look there occasionally to see how things have been going.
> 
> Actually, can I somehow take the jackstart output that goes to the F2
> console and pipe it to a file that I could look at from KDE? That would be
> nice too.

cd somedir
jackstart -R -d alsa -d hw &>jack.log
(if using the bash shell)

somewhere else:
cd somedir
tail -f jack.log
(checks at 1 second intervals for new stuff in the file)

Obviously jack.log keeps growing and growing without bounds...
-- Fernando

[linux-audio-dev] RE: [Jackit-devel] Re: k_jack v0.0.0.5

[Fernando Pablo Lopez-Lezcano]

>I have noticed that there are still a number of system oriented things
> that, on my system, absolutely guarantee an xrun. The simplest is dropping
> down to a console. (Alt-Ctl-F2) 

It is a known problem and is in the list of "things you should not do"
in Andrew Morton's low latency page (at the bottom):
  http://www.zip.com.au/~akpm/linux/schedlat.html

-- Fernando

[linux-audio-dev] Re: [Jackit-devel] hangs with 2.4.20, jack and clients... one tinypatch latter

[Fernando Pablo Lopez-Lezcano]

> > >The hang is not happening in any of these processes, as far as I can
> > >tell. It is not always in exactly the same place, although it happens
> > >always around the same area. I can see time suddenly jumping up, there
> > >are xruns printed (huge underruns, not the usual stuff - I assume this
> > >is before rt_monitor degrades the priorities and things return to
> > >normal). This usually is right after ardour's process function returns.
> > >So I have to see which process is actually interrupting all of this and
> > >hanging the whole thing. 
> > >
> > >Very confused at this point. 
> > 
> > can you check the signalled/awake/complete timestamps in the client
> > struct/debug output? these tell you whether/when:
> > 
> > (1) jackd woke the client with write()
> > (2) the client woke up from poll
> > (3) the client wrote to the next fifo
> > 
> > these are 3 critical steps that tell you whether or not the hang
> > happens between the two processes, or within one of them. each
> > situation is drastically different from the other and we need to know
> > which it is.
> 
> If I understand things correctly the problem seems to be happening in
> the alsa_driver_process function (or in alsa itself). Here a list of
> what happens just before the hang with some comments, please correct me
> if I'm wrong:

[very long printout of trace deleted]

Just by chance I stumbled on this message: 

  http://www.redhat.com/mailing-lists/ext3-users/msg08990.html

(I was looking at latency issues on a 3ware controller - no matter what
I do I get 12-18 mSec hits - google for vm.bdflush and look at the
second link)

"This patch fixes an inefficiency and potential system lockup in the 2.4
kernel's ext3 filesystem.  The problem has been present since
2.4.20-pre5."

Aha!! pre5 is when I started having problems! 
Latter Andrew tells us:

"Unless task A and task B happen to both have realtime scheduling policy
- if they do then kjournald will never run.  The state is never cleared
and your box locks up."

The problem always happens with realtime scheduling :-)

So, I patched the kernel and I've been running jack+ardour SCHED_FIFO
for more than an hour (previously it would die at most in a couple of
minutes). Even stressing the disk with a nice tar. I would hate to have
to post in 1/2 hour saying that it locked again, so this time I will
_not_ say the problem is solved :-)

Try it out. 
-- Fernando

[linux-audio-dev] this morning's cvs: via82xx build error?

[Fernando Pablo Lopez-Lezcano]

Very strange:
I'm seeing this while trying to compile the alsa drivers:

gcc -D__KERNEL__ -DMODULE=1
-I/usr/src/redhat/BUILD/alsa-driver-0.9.0/include 
-I/lib/modules/2.4.19-1.llsmp/build/include -O2
-mpreferred-stack-boundary=2 -march=i686 -D__SMP__ -DCONFIG_SMP -DLINUX
-Wall -Wstrict-prototypes -fomit-frame-pointer -pipe -DALSA_BUILD 
-DKBUILD_BASENAME=via82xx   -c -o via82xx.o via82xx.c
In file included from via82xx.c:1:
../alsa-kernel/pci/via82xx.c: In function `snd_via82xx_create':
../alsa-kernel/pci/via82xx.c:1588: structure has no member named
`rate_lock'
make[1]: *** [via82xx.o] Error 1

The error happens when compiling in an SMP host with gcc2.96, but the
same tarfile compiles fine on a UP host with gcc2.96 (same kernel) and
on another UP host with gcc3.2...

-- Fernando

Re: [Jackit-devel] Re: [linux-audio-dev] 2.4.20 + lowlat +preempt +alsa + jack = dead computer

[Fernando Pablo Lopez-Lezcano]

> > this will produce reams of output, but will provide you with the next
> > hint. 
> 
> reams of output collected...
> 
> > problem: the output will affect scheduling, which might make the
> > problem go away. i recommend outputting it to a file if possible, and
> > viewing after the fact.
> 
> I have big files for jack and ardour, and the problem did not go away. I
> have pored over the huge files but I don't seem to find anything that
> looks like a glitch. Will keep looking...

I have some data but I have no idea if it is significant. This is
running rt_monitor as a safeguard, jack and finally ardour. To speed up
the death of the patient (in my experience) a tar cvf usr.tar /usr was
also run in a separate terminal...

I looked for time transients in the cycle count of the listings. This is
the tail of it for ardour (abs cycles followed by delta cycles):

25316620570960 151478724
25314593862618 170551720
25316905845228 174448260
25283295747490 1690268954

So the last delta time is much bigger, a good candidate. Finding the time 
in the listing gives me this:

jack:27813:25281569457264 client.c:jack_client_thread:556: client polling on event_fd 
and graph_wait_fd...
jack:27813:25281605113512 client.c:jack_client_thread:664: client 27813 signalled at 
25281605055172, awake for process at 25281605109372 (delay = 32.071006 usecs) (wakeup 
on graph_wait_fd==30)
jack:27813:25281605240108 client.c:jack_client_thread:686: client finished processing 
at 25281605238028 (elapsed = 76.127811 usecs), writing on graph_next_fd==31
jack:27813:25281605450304 client.c:jack_client_thread:694: client sent message to next 
stage by 25281605450388, client reading on graph_wait_fd==30
jack:27813:25281605461784 client.c:jack_client_thread:699: reading cleanup byte from 
pipe
jack:27813:25281605472500 client.c:jack_client_thread:710: process cycle fully complete
jack:27813:25281605478536 client.c:jack_client_thread:556: client polling on event_fd 
and graph_wait_fd...

GLITCH! (this is not part of the listing :-)

jack:27813:25283295747490 client.c:jack_client_thread:556: client polling on event_fd 
and graph_wait_fd...
jack:27813:25283359653444 client.c:jack_client_thread:664: client 27813 signalled at 
25281641118776, awake for process at 25283359647196 (delay = 1016880.700592 usecs) 
(wakeup on graph_wait_fd==30)
jack:27813:25283359829424 client.c:jack_client_thread:686: client finished processing 
at 25283359827480 (elapsed = 106.676923 usecs), writing on graph_next_fd==31
jack:27813:25283360445692 client.c:jack_client_thread:694: client sent message to next 
stage by 25283360445776, client reading on graph_wait_fd==30
jack:27813:25283360457440 client.c:jack_client_thread:699: reading cleanup byte from 
pipe
jack:27813:25283360468308 client.c:jack_client_thread:710: process cycle fully complete

So there are two "client polling" in a row with nothing in between...

The second one presumably happens when rt_monitor downgrades the process to
SCHED_OTHER? Or maybe that is what is "hanging"? 

In the jack side of things:

25317681129070 143623260
25316620498912 151380488
25314593789218 170399340
25283359590208 1718469688

jack:27772:25281605266960 engine.c:jack_process:584: reading byte from 
subgraph_wait_fd==13
jack:27772:25281641074368 engine.c:jack_process:465: considering client alsa_pcm for 
processing
jack:27772:25281641107540 engine.c:jack_process:498: in-process client has no 
process() function
jack:27772:25281641114096 engine.c:jack_process:465: considering client ardour for 
processing
jack:27772:25281641120520 engine.c:jack_process:516: 

 alsa_pcm: xrun of at least 996.047 msecs

calling process() on an OOP subgraph, fd==7

GLITCH!

jack:27772:25283359590208 engine.c:jack_process:535: waiting on fd==13 for process() 
subgraph to finish
jack:27772:25283359952396 engine.c:jack_process:584: reading byte from 
subgraph_wait_fd==13
jack:27772:25283396656700 engine.c:jack_process:465: considering client alsa_pcm for 
processing
jack:27772:25283396688968 engine.c:jack_process:498: in-process client has no 
process() function
jack:27772:25283396695880 engine.c:jack_process:465: considering client ardour for 
processing

I did another test with the sleep in rt_monitor changed from 2 seconds
to 10 seconds (to keep the machine catatonic for a longer time) and the
result was not as interesting because jack timed out when it recovered
and killed itself and ardour. 

In that test I found three back to back polls with big timeouts in
between and two more somewhere else in the file. 

-- Fernando

Re: [Jackit-devel] Re: [linux-audio-dev] 2.4.20 + lowlat +preempt +alsa + jack = dead computer

[Fernando Pablo Lopez-Lezcano]

On Tue, 2003-01-07 at 19:14, Paul Davis wrote:
> >> what do you want to know? 
> >
> >Ahem, everything? :-) ;-) :-)
> 
> recompile with DEBUG_ENABLED defined at the top of engine.c and then
> if necessary client.c as well.
> 
> this will produce reams of output, but will provide you with the next
> hint. 

reams of output collected...

> problem: the output will affect scheduling, which might make the
> problem go away. i recommend outputting it to a file if possible, and
> viewing after the fact.

I have big files for jack and ardour, and the problem did not go away. I
have pored over the huge files but I don't seem to find anything that
looks like a glitch. Will keep looking...

-- Fernando

Re: [Jackit-devel] Re: [linux-audio-dev] 2.4.20 + lowlat +preempt +alsa + jack = dead computer

[Fernando Pablo Lopez-Lezcano]

> > > what do you want to know? 
> >
> >Ahem, everything? :-) ;-) :-)
> 
> recompile with DEBUG_ENABLED defined at the top of engine.c and then
> if necessary client.c as well.

There is a missing ";" in line 544 of libjack/client.c that triggers a
build error if debugging is enabled. 

Correct line is:
client->control->pid = getpid() ;

-- Fernando

Re: [Jackit-devel] Re: [linux-audio-dev] 2.4.20 + lowlat +preempt +alsa + jack = dead computer

[Fernando Pablo Lopez-Lezcano]

> >So I run that in a terminal and after playing around with a bunch of
> >jack apps got the machine to lockup... and then, after a little bit,
> >suddenly, it came back to life! (you could see that the monitor had
> >changed the priority of the hogs to SCHED_OTHER). 
> >
> >So I guess that somehow jack has a hard to trigger race condition that
> >locks up the machine when running SCHED_FIFO.
> >
> >Now I have to figure out how to trace the thing so as to determine where
> >the whole thing is locking. Help from the jack gurus appreciated. 
> 
> what do you want to know? 

Ahem, everything? :-) ;-) :-)

> can you get roger's tool to tell you which
> process (PID) is hogging the CPU? is it jackd or a client? 

I just tried it and it appears to be both (which is consistent with what
I got with the kernel debugger, I was breaking into it and the only
processes I ever saw were jackd or one of the clients). 

I was running jackd, ardour, freqtweak, qjackconnect, ams, and an
additional process doing disk i/o that pushed things over the edge.
After rt_monitor kicks in it does print pids, but I just discovered that
for some reason ps axuw is not printing all the processes (seems to miss
the SCHED_FIFO ones - never noticed this before) so it is hard to track
what is what. The SCHED_FIFO jackd process is downgraded to SCHED_OTHER,
plus a bunch of client processes. Only jackd and ardour survive after
the freeze, all other clients die or are killed (just made it happen
again, this time with only jack and ardour).

-- Fernando

Re: [Jackit-devel] Re: [linux-audio-dev] 2.4.20 + lowlat +preempt +alsa + jack = dead computer

[Fernando Pablo Lopez-Lezcano]

> >I browsed the Kernel Source and there is only one mark_inode_dirty in
> >pipe_write (in fs/pipe.c). So we know where it is hanging...
> >
> >And in __mark_inode_dirty (in fs/inode.c) there is one  
> >   spin_lock(&inode_lock)
> >call, and I guess that is where the whole thing is hanging. So something
> >is holding that lock... how do I find out who is doing that? Apparently
> >the handling of inode_lock is confined to inode.c. I'll keep reading. 

[Andrew Morton had suggested that the stack traces did not show problems
with stuck locks in the kernel...]

> >Maybe the pipe in question is one of the pipes that jack uses for ipc?
> 
> seems *damn* likely ... sorry to just be chiming in with a useless comment!

One more (small) datapoint. Roger Larsson sent me off the list a couple
of small utilities (VERY nice tools!) that monitors the cpu usage of
SCHED_FIFO processes and after a timeout actually downgrades the
persistent hogs to SCHED_OTHER. 

So I run that in a terminal and after playing around with a bunch of
jack apps got the machine to lockup... and then, after a little bit,
suddenly, it came back to life! (you could see that the monitor had
changed the priority of the hogs to SCHED_OTHER). 

So I guess that somehow jack has a hard to trigger race condition that
locks up the machine when running SCHED_FIFO.

Now I have to figure out how to trace the thing so as to determine where
the whole thing is locking. Help from the jack gurus appreciated. 

-- Fernando

Re: [Jackit-devel] Re: [linux-audio-dev] Re: [Jackit-devel]2.4.20ÂÂ + lowlat +preempt + alsa+ jack = dead computer

[Fernando Pablo Lopez-Lezcano]

On Sat, 2003-01-04 at 12:17, Fernando Pablo Lopez-Lezcano wrote:
> On Sat, 2003-01-04 at 01:49, Andrew Morton wrote:
> > 
> > There's no sign of a deadlock or a livelock in these traces.  It just
> > looks like these tasks are asleep and not waking up.
> > 
> > > Each time I break into the debugger I see one of the jack related
> > > processes as the current process. No other processes, so I assume the
> > > SCHED_FIFO ring is still running but everything else is being blocked by
> > > the mark_inode_dirty call.
> > 
> > Why do we not believe that this is an application bug? 
> 
> Last time I tried, this did not happen in 2.4.19 so I assumed it was a
> problem in 2.4.20 (boot into 2.4.19, no problems, boot into 2.4.20,
> lockups, same everything else). Other users have reported this as well
> (in 2.4.20 only AFAIK). Other users are using the exact same versions of
> jack and associated software under a 2.4.19 kernel intensively (through
> Planet CCRMA) and have not reported lockups. 

BT! Wrong answer... :-) see related thread, people are reporting
lockups on 2.4.19 as well. Paul: any suggestions on what I could look
for?

-- Fernando

Re: [Jackit-devel] Re: [linux-audio-dev] Re: [Jackit-devel]2.4.20Â + lowlat +preempt + alsa + jack = dead computer

[Fernando Pablo Lopez-Lezcano]

On Sat, 2003-01-04 at 01:49, Andrew Morton wrote:
> Fernando Pablo Lopez-Lezcano wrote:
> > 4)
> > schedule +1ab
> > sleep_on +45
> > bread +20
> > __mark_inode_dirty +d9
> > pipe_write +1b9
> > poll_freewait +44
> > sys_write +9f
> > system_call +33
> > 
> > So the system seems to be stuck in __mark_inode_dirty, whatever that is.
> 
> No, that's just stack gunk.
> 
> There's no sign of a deadlock or a livelock in these traces.  It just
> looks like these tasks are asleep and not waking up.
> 
> > Each time I break into the debugger I see one of the jack related
> > processes as the current process. No other processes, so I assume the
> > SCHED_FIFO ring is still running but everything else is being blocked by
> > the mark_inode_dirty call.
> 
> Why do we not believe that this is an application bug? 

Last time I tried, this did not happen in 2.4.19 so I assumed it was a
problem in 2.4.20 (boot into 2.4.19, no problems, boot into 2.4.20,
lockups, same everything else). Other users have reported this as well
(in 2.4.20 only AFAIK). Other users are using the exact same versions of
jack and associated software under a 2.4.19 kernel intensively (through
Planet CCRMA) and have not reported lockups. 

It could also be that 2.4.20 makes a race condition inside jack more
likely, and exposes a bug in jack. I'll test again in 2.4.19 just to
make sure I'm still seeing the same thing.

Thanks for the help, I'll try out your suggestions and report back. 
-- Fernando

Re: [Jackit-devel] Re: [linux-audio-dev] 2.4.20 + lowlat +preempt +alsa + jack = dead computer

[Fernando Pablo Lopez-Lezcano]

> >I browsed the Kernel Source and there is only one mark_inode_dirty in
> >pipe_write (in fs/pipe.c). So we know where it is hanging...
> >
> >And in __mark_inode_dirty (in fs/inode.c) there is one  
> >   spin_lock(&inode_lock)
> >call, and I guess that is where the whole thing is hanging. So something
> >is holding that lock... how do I find out who is doing that? Apparently
> >the handling of inode_lock is confined to inode.c. I'll keep reading. 
> >
> >Maybe the pipe in question is one of the pipes that jack uses for ipc?
> 
> seems *damn* likely ... sorry to just be chiming in with a useless comment!

Do you think the problem might be jack? Some race condition that only
happens (or is much more likely to happen) in 2.4.20? It does sound more
like a kernel bug, but I have not seen a hung machine without having
jack and clients running...

-- Fernando

Re: [Jackit-devel] Re: [linux-audio-dev] 2.4.20 + lowlat +preempt +alsa + jack = dead computer

[Fernando Pablo Lopez-Lezcano]

[brief description of problem: jack + several other jack clients + disk
activity - a tar process, for example - hangs the machine]

> This is what I'm currently testing:
> 
>   2.4.20 + capabilities + preempt + lowlat +
>   [from Con Koliva's page]
>   Read latency2 disk hack (Andrew Morton) + ACPI + variable HZ (1000) +
>   [from an older jl patch]
>   drm low latency +
>   [from ext3 page]
>   ext3 patches for 2.4.20
> 
> I built the icebox kernel debugger to try to get some info on where the
> program is hanging and this is what I get in terms of what's happening
> (four instances of breaking into the debugger with the Sysrq-d key),
> this is the list of tasks:
> 
> 4) [other 3 erased for brevity]
> schedule +1ab
> sleep_on +45
> bread +20
> __mark_inode_dirty +d9
> pipe_write +1b9
> poll_freewait +44
> sys_write +9f
> system_call +33
> 
> So the system seems to be stuck in __mark_inode_dirty

I browsed the Kernel Source and there is only one mark_inode_dirty in
pipe_write (in fs/pipe.c). So we know where it is hanging...

And in __mark_inode_dirty (in fs/inode.c) there is one  
   spin_lock(&inode_lock)
call, and I guess that is where the whole thing is hanging. So something
is holding that lock... how do I find out who is doing that? Apparently
the handling of inode_lock is confined to inode.c. I'll keep reading. 

Maybe the pipe in question is one of the pipes that jack uses for ipc?
-- Fernando

Re: [Jackit-devel] Re: [linux-audio-dev] Re: [Jackit-devel]2.4.20Â + lowlat +preempt + alsa + jack = dead computer

[Fernando Pablo Lopez-Lezcano]

> > I don't have the time now to analyze the results but it would seem the
> > problem is freqtweak in combination with jackd. When the system freezes
> > after starting stuff from a text console, sysrq-p prints
> > information about the current registers and the printout of repeated
> > dumps only shows the jackd and freqtweak processes over and over again.
>
> Good news (apparently - most probably the machine I'm testing on will
> freeze while I'm typing this message :-)

It eventually did after I sent the message :-(

> The problem with 2.4.20 appears to have been ext3. I finally got a trace
> of the deadlocked processes through the sysrq key (after retyping lots
> of boring numbers from the screen) and ksymoops is pointing to something
> stuck in ext3. With that clue I went to the ext3 site:
> 
>   http://www.zip.com.au/~akpm/linux/ext3/

Well, the machine keeps locking even with those patches. A sure way for
me to kill it is to run jack, ardour, freqtweak, qjackconnect and a
process doing "tar cvf usr.tar /usr" (in the home partition). Sometimes
I cannot even start all the stuff and I don't get to the tar process,
sometimes it takes a while to die. Adding some heavy disk activity to
the mix seems to help kill it faster. But I've seen it die with just
jack and ardour running. 

This is what I'm currently testing:

  2.4.20 + capabilities + preempt + lowlat +
  [from Con Koliva's page]
  Read latency2 disk hack (Andrew Morton) + ACPI + variable HZ (1000) +
  [from an older jl patch]
  drm low latency +
  [from ext3 page]
  ext3 patches for 2.4.20

Same results on a quick test with 2.4.21-pre2.

I built the icebox kernel debugger to try to get some info on where the
program is hanging and this is what I get in terms of what's happening
(four instances of breaking into the debugger with the Sysrq-d key),
this is the list of tasks:

1)
__switch_to +3e
schedule +269
sleep_on +45
__mark_inode_dirty +d9
pipe_write +1b9
sys_write +9f
system_call +33

2)
sleep_on +6f
bread +20
__mark_inode_dirty +d9
pipe_write +1b9
poll_freewait +44
sys_write +9f
system_call +33

3)
__wake_up +55
bread +20
__mark_inode_dirty +d9
pipe_write +1b9
poll_freewait +44
sys_write +9f
system_call +33

4)
schedule +1ab
sleep_on +45
bread +20
__mark_inode_dirty +d9
pipe_write +1b9
poll_freewait +44
sys_write +9f
system_call +33

So the system seems to be stuck in __mark_inode_dirty, whatever that is.
Each time I break into the debugger I see one of the jack related
processes as the current process. No other processes, so I assume the
SCHED_FIFO ring is still running but everything else is being blocked by
the mark_inode_dirty call. 

Any interested kernel hackers out there to help with this?
Awaiting instructions... :-)
-- Fernando

Re: [Jackit-devel] Re: [linux-audio-dev] Re: [Jackit-devel]2.4.20Â + lowlat +preempt + alsa + jack = dead computer

[Fernando Pablo Lopez-Lezcano]

> > qjackconnect. I'm currently trying to see if I can start the stuff from
> > the text console so that I can try to catch some register dumps through
> > the sysrq magic key...
> 
> I don't have the time now to analyze the results but it would seem the
> problem is freqtweak in combination with jackd. When the system freezes
> after starting stuff from a text console, sysrq-p prints
> information about the current registers and the printout of repeated
> dumps only shows the jackd and freqtweak processes over and over again.
> 
> Somehow they must be deadlocking. 

Good news (apparently - most probably the machine I'm testing on will
freeze while I'm typing this message :-)

The problem with 2.4.20 appears to have been ext3. I finally got a trace
of the deadlocked processes through the sysrq key (after retyping lots
of boring numbers from the screen) and ksymoops is pointing to something
stuck in ext3. With that clue I went to the ext3 site:

  http://www.zip.com.au/~akpm/linux/ext3/

And sure enough there were patches for 2.4.20 and one of them was a
deadlock condition. I applied them, rebuilt the kernel and the machine
appears to be _finally_ happy (I'm still typing and it has not
deadlocked). 

This is with 2.4.20 + lowlat + preempt + o(1) scheduler (most of Con
Koliva's patchset) plus some extras, running latest alsa cvs plus jack
and a bunch of jack clients. 

Well, it did not freeze after all... let's see if I can get to the send
message button before it does :-) 

-- Fernando

Re: [linux-audio-dev] Blockless processing

[Fernando Pablo Lopez-Lezcano]

> > What does your thingie do that sfront doesn't do?
> > sfront compiles SAOL / SASL text files (describing a 
> > processing & synthesis network) down to C which
> > compiles nicely with GCC.
> 
> SAOL is still block based AFAIK. This allows you to do some really neat
> tricks with feedback, knowing that the latency is only one sample.
> 
> In principle you can run any system with a block size of 1, but the
> performance will really suck. Maybe SAOL would be ok, anyone tried it?
> 
> > the basic idea is not new either... IIRC, Common Music
> > does much the same thing starting from a lisp dialect.
> 
> Yes, but its lisp :)

The package is Common Lisp Music (CLM), does not use blocks (ie: block
size = 1), and compiles the sample generation loop of instruments into C
from a subset of Common Lisp (instruments are written in Common Lisp).
The other parts of the instrument run in compiled lisp. It is quite
fast. It is originally based in Common Lisp but there are now two other
implementations of the same primitives (unit generators) in both Scheme
and C. The scheme port runs on guile and is getting quite close to the
Common Lisp / C based CLM in speed (factor of 2 or 3 as I recall). All
written by Bill Schottstaed. 

-- Fernando

Re: [linux-audio-dev] Re: [vst-plugins] Plugin server

[Fernando Pablo Lopez-Lezcano]

On Sun, 2002-12-08 at 16:14, Kai Vehmanen wrote:
> On Sun, 8 Dec 2002, Paul Davis wrote:
> 
> > you also haven't addressed kernel scheduling issues; the context
> > switch doesn't happen till the kernel has decided what task is going
> > to run next. if it picks the wrong one, for whatever reason, then
> > you/we lose. right now, it picks the wrong one too often, even with
> > SCHED_FIFO+mlockall.
> 
> Btw; have you tried the O(1) scheduler? It has a number of interesting
> charasteristics from an audio app developer's pov [1]:

I tried it (using the Con Kolivas patches on top of 2.4.20). I still get
xruns in jackd, although that particular patchset (plus the drm lowlat
patches) seems to keep them to more reasonable values at least in a
short test I just did. I managed to also hang the machine, after running
jackd + qjackconnect + freqtweak + ams for a while I got greedy and
started ardour - created a new session and when I went to connect things
in qjackconnect the machine stopped... it still responds to alt-sysrq-b.
BTW, with latest versions of alsa the hanging problems seems to happen
less frequently so it may be some interaction between alsa and the
kernel (hangs do not seem to happen in 2.4.19).

Besides that, it looks like the O(1) scheduler is less responsive to
user interaction in certain cases. While doing an alsa driver compile
the mouse was freezing for fractions of a second at a time (this was
during the depend phase, actually compiling the modules did not have
that effect). 

[anyone out there has a patch to schedutils to make them work with the
O(1) scheduler?, mine just report all tasks as Other]

-- Fernando

Re: [Jackit-devel] Re: [linux-audio-dev] Re: [Jackit-devel]2.4.20Â + lowlat +preempt + alsa + jack = dead computer

[Fernando Pablo Lopez-Lezcano]

> > > To add one more datapoint to the thread and (apparently good news): I'm
> > > testing 2.4.20 (final) + lowlat + preempt + acpi + alsa + jack and the
> > > computer seems to be chugging along nicely. This is with today's alsa. A
> > > slighly older alsa did lock the computer after 5 or so minutes of jack
> > > activity but I managed to reboot it with the sysrq magic key. With the
> > > newest alsa I got jack + freqtweak + ams (with the demo patch) running
> > > for 50 minutes until for some reason jack died due to a watchdog
> > > interrupt. Not bad.
> > 
> > Where are the lowlat and preempt patches for 2.4.20? 
> 
> Not on the net at this point. I have been hand tweaking the originals to
> patch cleanly (trying to fix the failing chunks). I can email them to
> you, use at your own risk :-)
> 
> BTW, results in my current tests are inconclusive, a couple of times I
> managed to freeze the machine soon after I started just jackd and
> qjackconnect. I'm currently trying to see if I can stat the stuff from
> the text console so that I can try to catch some register dumps through
> the sysrq magic key...

I don't have the time now to analyze the results but it would seem the
problem is freqtweak in combination with jackd. When the system freezes
after starting stuff from a text console, sysrq-p prints
information about the current registers and the printout of repeated
dumps only shows the jackd and freqtweak processes over and over again.

Somehow they must be deadlocking. 

I'm hoping that typing all those numbers and parsing through ksymoops
will show us exactly where things are hanging. So much fun. 

-- Fernando

Re: [linux-audio-dev] Re: [Jackit-devel] 2.4.20-rc1ÂÂ + lowlat +preempt + alsa + jack = deadcomputer

[Fernando Pablo Lopez-Lezcano]

> > > > Have you tried anything in between pre10-ac3 and pre4? I know pre4 works
> > > > fine. I probably should post to the lkml with as much detail as we can
> > > > get (unless some kernel hacker is actually reading these messages).
> > >
> > > I've tried every kernel from 2.4.20-pre5 up to 2.4.20-pre10, and again
> > > 2.4.20-pre10-ac3, which caused a lockup on my system in the past, this
> > > afternoon. And I couldn't reproduce even _one_ lockup. I use another IDE
> > > interface though: a cmd649 add-on controller. The lockups happened with
> > > the onboard IDE interface (VIA KT333 chipset, vt8235 southbridge).
> > 
> > To add one more datapoint to the thread and (apparently good news): I'm
> > testing 2.4.20 (final) + lowlat + preempt + acpi + alsa + jack and the
> > computer seems to be chugging along nicely. This is with today's alsa. A
> > slighly older alsa did lock the computer after 5 or so minutes of jack
> > activity but I managed to reboot it with the sysrq magic key. With the
> > newest alsa I got jack + freqtweak + ams (with the demo patch) running
> > for 50 minutes until for some reason jack died due to a watchdog
> > interrupt. Not bad.
> 
> Where are the lowlat and preempt patches for 2.4.20? 

Not on the net at this point. I have been hand tweaking the originals to
patch cleanly (trying to fix the failing chunks). I can email them to
you, use at your own risk :-)

BTW, results in my current tests are inconclusive, a couple of times I
managed to freeze the machine soon after I started just jackd and
qjackconnect. I'm currently trying to see if I can stat the stuff from
the text console so that I can try to catch some register dumps through
the sysrq magic key...

-- Fernando

Re: [linux-audio-dev] Re: [Jackit-devel] 2.4.20-rc1Â + lowlat +preempt + alsa + jack = dead computer

[Fernando Pablo Lopez-Lezcano]

> Fernando Pablo Lopez-Lezcano wrote:
> 
> > Have you tried anything in between pre10-ac3 and pre4? I know pre4 works 
> > fine. I probably should post to the lkml with as much detail as we can 
> > get (unless some kernel hacker is actually reading these messages). 
> 
> I've tried every kernel from 2.4.20-pre5 up to 2.4.20-pre10, and again
> 2.4.20-pre10-ac3, which caused a lockup on my system in the past, this
> afternoon. And I couldn't reproduce even _one_ lockup. I use another IDE
> interface though: a cmd649 add-on controller. The lockups happened with
> the onboard IDE interface (VIA KT333 chipset, vt8235 southbridge).

To add one more datapoint to the thread and (apparently good news): I'm
testing 2.4.20 (final) + lowlat + preempt + acpi + alsa + jack and the
computer seems to be chugging along nicely. This is with today's alsa. A
slighly older alsa did lock the computer after 5 or so minutes of jack
activity but I managed to reboot it with the sysrq magic key. With the
newest alsa I got jack + freqtweak + ams (with the demo patch) running
for 50 minutes until for some reason jack died due to a watchdog
interrupt. Not bad. 

-- Fernando

Re: [linux-audio-dev] Please test my MidiSport firmware loader

[Fernando Pablo Lopez-Lezcano]

> > I've created a package which extracts the firmware for MidiSport devices
> > from the Windows driver files and installs the hotplug script to download
> > the firmware. You can get it at
> > .
> > 
> > There are some differences to Lars Doelle's GPL firmware:
> > - it supports MidiSport 4x4/8x8/Keystation/Oxygen
> > - no configuration file editing, just 'make install'
> > - it requires ALSA because the Midiman firmware doesn't conform to the USB
> >   MIDI specification
> > 
> > I don't have a MidiSport device, so this is completely untested.
> 
> GREAT!!! It works!
> 
> Just tried it with current alsa cvs and the firmware loads and alsa
> likes it (well, almost, I still have problems with sequencer playback
> from muse, I have to try rebuilding muse from scratch). 

Well, I think it was just stale preferences in Muse that were causing
the errors. I started activating all the tracing options in Muse, got
lots of printouts and at some point I did a "Save Preferences" and after
that it was working fine, both input and output. Hmmm, I thought that at
some point I did erase all the .files related to Muse, maybe I missed
one?

Anyway, it is working now...
-- Fernando

Re: [linux-audio-dev] Please test my MidiSport firmware loader

[Fernando Pablo Lopez-Lezcano]

> I've created a package which extracts the firmware for MidiSport devices
> from the Windows driver files and installs the hotplug script to download
> the firmware. You can get it at
> .
> 
> There are some differences to Lars Doelle's GPL firmware:
> - it supports MidiSport 4x4/8x8/Keystation/Oxygen
> - no configuration file editing, just 'make install'
> - it requires ALSA because the Midiman firmware doesn't conform to the USB
>   MIDI specification
> 
> I don't have a MidiSport device, so this is completely untested.

GREAT!!! It works!

Just tried it with current alsa cvs and the firmware loads and alsa
likes it (well, almost, I still have problems with sequencer playback
from muse, I have to try rebuilding muse from scratch). 

I tested it with an Oxigen8 and a Midisport 2x2. Do you happen to know
if the Midiman Quattro midi interface could use this method as well?

Now I have to create packages for all this :-)
-- Fernando

Re: [linux-audio-dev] Looking for some PR stuff related to Jack

[Fernando Pablo Lopez-Lezcano]

> >Could this be a possible solution to the in-process xrun issue?
> >
> >http://www.onlamp.com/pub/a/onlamp/2002/11/07/linux_threads.html
> 
> there is no "in-process" xrun issue. the problem is for
> "out-of-process" clients. the problem has nothing whatsoever to do
> with the pthreads implementation, and everything to do with the kernel
> scheduler and worst-case kernel scheduling latencies. 

Would compiling the kernel with HERTZ > 100 (say, 500) help?
I imagine it would because the scheduler would run more often. 
-- Fernando

Re: [Jackit-devel] Re: [linux-audio-dev] Re: [Jackit-devel] 2.4.20-rc1 +lowlat + preempt + alsa + jack = dead computer

[Fernando Pablo Lopez-Lezcano]

> Fernando Pablo Lopez-Lezcano wrote:
> 
> > Have you tried anything in between pre10-ac3 and pre4? I know pre4 works 
> > fine. I probably should post to the lkml with as much detail as we can 
> > get (unless some kernel hacker is actually reading these messages). 
> 
> I've tried every kernel from 2.4.20-pre5 up to 2.4.20-pre10, and again
> 2.4.20-pre10-ac3, which caused a lockup on my system in the past, this
> afternoon. And I couldn't reproduce even _one_ lockup. I use another IDE
> interface though: a cmd649 add-on controller. The lockups happened with
> the onboard IDE interface (VIA KT333 chipset, vt8235 southbridge).
> 
> For now I'm too lazy to open the computer case and try with the VIA
> interface to be sure, but... I can't think of another change to my
> system, so maybe that's the reason for the lockups. What IDE interface
> do you have?

I tried 2.4.20rc1 on a laptop and lspci says:
  IDE interface Intel Corp. 82801CA< IDE U100 (rev 02)
and on an hp desktop (old...):
  IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)

I'll try again latter on different machines...
-- Fernando

Re: [linux-audio-dev] Re: [Jackit-devel] 2.4.20-rc1 + lowlat + preempt + alsa + jack = dead computer

[Fernando Pablo Lopez-Lezcano]

> Fernando Pablo Lopez-Lezcano wrote:
> 
> > If I start jackd and then use the freqtweak jack client I get a completely
> > dead machine in a very short time (from a few seconds to 10 or 20
> > seconds).
> 
> > [...]
> 
> I get exactly the same results as you. 2.4.19 works fine,
> 2.4.20-pre10-ac3, 2.5.41 - 2.5.45 lock up.

Have you tried anything in between pre10-ac3 and pre4? I know pre4 works 
fine. I probably should post to the lkml with as much detail as we can 
get (unless some kernel hacker is actually reading these messages). 

-- Fernando

Re: [linux-audio-dev] Interesting USB MIDI master keyboards, do theywork with Linux ?

[Fernando Pablo Lopez-Lezcano]

> I meant of sending midi events from the master keyboard via USB to the
> PC which runs an internal soft-synth/sampler. 

Sorry, I misunderstood. You are right, if the keyboard is connected
through usb big chords will have much better timing. The 1msec added
latency should not make any difference at all when compared to normal
midi. One midi note (no running status) takes about 1msec to be
transmitted at 31250 baud. 

-- Fernando

> In that case USB should improve timing because of the bigger bandwidth,
> (but will add 1msec of latency due to USB1 polling mechanism as far as I can
> understand). Correct me if I'm wrong.
> 
> cheers,
> Benno
> 
> You wrote:
> -
> > Ok if the Edirol keyboards support standard MIDI then there shouldn't be any 
> > problems using them under Linux, but since USB has a much bigger bandwidth 
> > than serial MIDI, I that the timing for notes that belong to large chords is 
> > more precise. Can someone confirm this ? 
> 
> Not really, unless you are spreading those chords on several separate midi 
> outputs. If it just one, then it determines the bandwidth available. 
> Getting things faster to the interface will do nothing because it still 
> has to send the bytes to the external synth at the same old slow 31250 
> baud speed. 

RE: [linux-audio-dev] Interesting USB MIDI master keyboards, do the work with Linux ?

[Fernando Pablo Lopez-Lezcano]

> > AFAIK the Oxygen8 does not behave as a standard usb midi device, it uses a 
> > "Midiman protocol" instead, so the standard drivers don't know what to do 
> > with it. If you connect it and do an lsusb -v you don't see much... 
> 
> Ok if the Edirol keyboards support standard MIDI then there shouldn't be any
> problems using them under Linux, but since USB has a much bigger bandwidth
> than serial MIDI, I that the timing for notes that belong to large chords  is
> more precise. Can someone confirm this ?

Not really, unless you are spreading those chords on several separate midi
outputs. If it just one, then it determines the bandwidth available.
Getting things faster to the interface will do nothing because it still
has to send the bytes to the external synth at the same old slow 31250
baud speed.

-- Fernando

RE: [linux-audio-dev] Interesting USB MIDI master keyboards, do the work with Linux ?

[Fernando Pablo Lopez-Lezcano]

> >   the specs say they have midi in/out (in addition to usb) so they should
> > work with linux, right?
> > 
> >   quote:
> > 
> > "MIDI Interface (in/out), USB Interface"
> 
> I have an Oxygen8 and it works fine in Linux if you use the MIDI
> interface.  You have to buy your own though.  It'd be nice to beable to
> use the USB interface, but I haven't been able to get that working.  The
> usb hotplug scripts are kinda opaque.

AFAIK the Oxygen8 does not behave as a standard usb midi device, it uses a
"Midiman protocol" instead, so the standard drivers don't know what to do
with it. If you connect it and do an lsusb -v you don't see much...

-- Fernando

[linux-audio-dev] 2.4.20-rc1 + lowlat + preempt + alsa + jack = dead computer

[Fernando Pablo Lopez-Lezcano]

[sorry for the wide distribution]
Is anyone out there trying out this combination?:

  kernel 2.4.20-rc1
  capabilities patch
  low latency patch
  preemptible kernel patch
  almost current alsa cvs [20021028.170432 usa pacific time]

If I start jackd and then use the freqtweak jack client I get a completely
dead machine in a very short time (from a few seconds to 10 or 20
seconds).

Same alsa driver, but running on 2.4.19 (up to 20-pre4) seems to be fine
and I can play around with freqtweak for as long as I want :-)

No clues are left behind... something in the kernel is deadlocking, I
guess. I tried removing first the preemptible kernel patch with the same
result.  Just a moment ago I tried again after removing the low latency
patch and I still get the same result... that pretty much leaves alsa and
the kernel. Got the same result on a laptop intel810 and an ice1712 card.

Interestingly enough just the jack server running is not enough to kill
the machine. Adding a jack client (just tried alsaplayer, same problem as
freqtweak) kills the machine really fast.

Maybe there is a problem with the scheduler when there are several
SCHED_FIFO tasks competing for the processor?

-- Fernando

Re: [linux-audio-dev] Re: The Image (usablity) problem from aMusicians point of view

[Fernando Pablo Lopez-Lezcano]

>From my experience with linux and audio I would say it is too early to
start widely promoting linux as a professional audio solution, in general.  
It is just not there at this point.

A couple of things could be "promoted", though. 

Companies or individuals that want to offer commercial (professional)  
linux audio solutions or services can promote their product(s). I think it
is _not_ impossible to assemble a turnkey solution that will work for a
given task. If it works and you want to sell it, then of course you have
to promote it somehow. But it is the company promoting a product, not the 
linux audio community as a whole promoting the platform. 

Another one would be sharing success stories. If you are using linux in a
professional audio environment successfully then by all means tell the
world (and us :-). But tell the whole story, including the painful start
(_if_ it was painful, of course :-) as well. I'm not talking here about
the more common "I finally got ardour to work and it is cool" but the "I
cut an album with ardour, it was not easy but the end result is great"
(just an example).

IMHO word of mouth from users that are happy with their systems is what
should make linux successfull in the professional audio world.

When that happens big commercial companies will probably also take notice. 
-- Fernando

Re: [linux-audio-dev] [SOURCE] rt monitor to kill runaway RT processes

[Fernando Pablo Lopez-Lezcano]

> >The only thing the sound servers need to be able to handle
> >RT audio are:
> >* one of the RT scheduling methods.
> >* locked memory. (Not protected at the moment - hard limits?)
> 
> >This can be archived with a wrapper that drops ALL other priorities
> >before running the real application.
> 
> this is, alas, not true. to use RT scheduling, you need either root
> uid or CAP_RESOURCE. if you have CAP_RESOURCE or root uid, you can do
> many, many things (such as write to /dev/kmem) that can lead to a DOS.

I think you need:
 - CAP_SYS_NICE for changing into RT_FIFO, but that also:

   /* Allow raising priority and setting priority on other (different
  UID) processes */
   /* Allow use of FIFO and round-robin (realtime) scheduling on own
  processes and setting the scheduling algorithm used by another
  process. */

   so yes, it is dangerous. 

 - CAP_IPC_LOCK for locking down memory (mlock and mlockall)

CAP_RESOURCE is only needed if you want to program the rtc clock with a
rate higher than 64Hz. And yes, if you grant it then the process can
override any limits in resource usage assigned to it, not just the rtc.  
It is very broad in what it can do.

Jackstart (the small program that can start jackd with rt capabilities)
also gets CAP_SETPCAP which enables it to give capabilities (a restricted
set) to other processes.

> the central problem is that there is no way to tell the kernel "this
> thread should get to run whenever it wants, but do nothing else that a
> normal process cannot do", and likewise, "this vm address space can
> lock down up to 128MB of memory". we don't have sufficiently
> granularity to do this

Yes, capabilities are useful but way too broad. 

-- Fernando

Re: [linux-audio-dev] a jack question

[Fernando Pablo Lopez-Lezcano]

> given kernel capability patch applied, does jackd give real-time
> capability to existing running process (normal user) that decide to
> become a jack client?

yes, it gives the needed capabilities to the audio thread that
gets created for each new client (not the whole application,
of course). You have to use jackstart (suid root) to start
jackd instead of starting jackd directly.

-- Fernando

Re: [linux-audio-dev] (not so low) low latency - acpi, dri, proc

[Fernando Pablo Lopez-Lezcano]

> > I suspect acpi might be the culprit but I cannot try to
> > disable it because on this particular laptop you need acpi to
> > make sound work (probably something to do with routing of
> > interrupts,, also tried pci=biosirq on a non-acpi kernel
> > without success). Any suggestions?
>
> Hmmh, are you confusing ACPI and APIC here?
>
> ACPI is about power saving and APIC is about routing interrupts, etc...

I'm talking about the power saving subsystem. A kernel without
the latest sourceforge acpi patch boots, but the routing of
interrupts (and maybe something else?) is broken and sound
does not work at all. With the acpi patch sound works fine,
except for the 170mSec spikes I see when running latencytest.
Obviously I cannot remove acpi to see if that is actually the
problem :-)

> > Proc: something has changed from the 2.4.18 to the 2.4.19
> > kernels (maybe the acpi proc interface is to blame?). Big
> > mess of latency spikes in the proc latency test.
>
> No problems here with 2.4.19-jl series... Steady at 0.9 ms when using 128
> byte buffers with ENS1371.

Sigh... :-)
-- Fernando

[linux-audio-dev] (not so low) low latency - acpi, dri, proc

[Fernando Pablo Lopez-Lezcano]

Hi... anybody out there testing latency on an ACPI patched
kernel? I have two kernels I'm testing:

2.4.19-x:
  2.4.19
  2.4.20-pre4
  low latency for 2.4.19 (w/a couple of tweaks to patch pre4)
  acpi-20020815 for 2.4.20-pre4

2.4.18-x:
  2.4.18
  low latency for 2.4.18-pre10
  acpi-20020726 for 2.4.18

On both 2.4.18-x and 2.4.19-x I get quite high periodic
latency peaks that hover around 170mSecs.

I suspect acpi might be the culprit but I cannot try to
disable it because on this particular laptop you need acpi to
make sound work (probably something to do with routing of
interrupts,, also tried pci=biosirq on a non-acpi kernel
without success). Any suggestions?

DRI: I was about to write something about this and then
checked and yes, the latest lowlat patch (for 2.4.19) is
missing the dri reschedules (from Jussi Lako's patch set) so
that DRI is unusable if you don't add them (at least on a
Radeon based laptop). I'm recompiling with them to do more
tests.

Proc: something has changed from the 2.4.18 to the 2.4.19
kernels (maybe the acpi proc interface is to blame?). Big
mess of latency spikes in the proc latency test.

I'll post latency graphs later... this is all using
latencytest 0.42

-- Fernando

Re: [linux-audio-dev] Playing wavs within OpenGL Performer withoutdelay

[Fernando Pablo Lopez-Lezcano]

> > I haven't updated my kernel which is 2.4.18-3 to do the low latency stuff.
>
> If this is the kernel that is included with redhat 7.3, I think it
> allready does the low latency stuff...

It has part of the patch and it is enabled by default. The
partial patch that redhat included is not as good as the full
patch, but is obviously better than nothing (in limited tests
I run while trying it).

-- Fernando

Re: [linux-audio-dev] App metadata intercomunication protocol..

[Fernando Pablo Lopez-Lezcano]

> > What about Yamaha's mLan ?
> > I thought that was some kind of midi over firewire,
> > but maybe they didn't grab it as an opportunity
> > to improve on midi ...
>
> It's midi and audio over firewire.
> I think it's plain vanilla midi messages, though.
> not sure.

mLAN is built on top of the public IEC61883 protocols,
specifically IEC61883-6 which (I believe) specifies audio and
plain midi transport over ieee1394 (aka firewire). It does not
venture into better control protocols, it is just midi. mLAN
adds (at least) word clock (sync and recovery, low jitter and
so on and so forth) and connection management to the public
standards, but it is a proprietary system - you can get a
license only after signing an NDA, I believe an open source
driver would not be possible given those constraints. At a
recent talk about mLAN here at ccrma I asked the question: so,
how would an mLAN product interact with a completely
IEC61883-6 compliant protocol stack in, let's say, linux?
After all, it is built on top of that. They did not know. At
that time it was a theoretical question, now it is a practical
one as I just noticed last week that in 2.4.19-rc2 there is
now an option to compile a IEC61883-6 protocol stack module
for ieee1394 so I'll ask the question again...

-- Fernando

Re: [linux-audio-dev] latency measuring software

[Fernando Pablo Lopez-Lezcano]

> I can't get latencytest-0.42 to run on Redhat 7.3. I would like to make
> sure that the kernels I've been building are doing what I want. Does
> anybody have this working, or are there other audio latency measuring
> tools around?

What error are you getting? I have been doing tests at home
under redhat 7.3 and they worked for me...

-- Fernando

Re: [linux-audio-dev] Low latency and X11 Direct Rendering

[Fernando Pablo Lopez-Lezcano]

> I've been running kernel with the DRM patches since January and it has been
> rock solid. However my machines are UP only, so if someone happens to be
> running kernel with the patches on SMP machine I would like to know if it
> works irl.

I've been using them with a Radeon card for about a month in a dual athlon
machine and so far it looks good. I was getting latency hits of about 18
msecs without the dri patches.

[but I'm still getting latency hits of around 8-10 mSecs when using the
3ware scsi raid driver (3w-), I tried to find out what is causing them
but eventually gave up, at least for now]

BTW, thanks a lot for the patch...
-- Fernando

Re: [linux-audio-dev] Low latency and X11 Direct Rendering

[Fernando Pablo Lopez-Lezcano]

> Running latencytest I have found a quite bad behaviour with the high
> X11 load test when the X server has the DRI module loaded and active.
> 
> Is anyone there using DRI and lowlatency-patch at the same time? 
> 
> Have you experienced this kind of problems?

There are a couple of patches that are part of the Juissi
Lako's patchset that I have used to fix that.  

I wrote on May 30 (linux-audio-user):
> I did find some problems with the dri interface and found a
> patch inside Jussi Laako's patchset ([EMAIL PROTECTED])
> that fixed it (I was testing with latencytest 0.42). See:
>   http://www.pp.song.fi/~visitor/linux/

I'm including the part of the patch that I added to my kernel
as an attachment. 

-- Fernando


linux-drm-lowlat.patch
Description: Binary data

Re: [linux-audio-dev] LADSPA

[Fernando Pablo Lopez-Lezcano]

> >I set out to package ladspa_sdk into an rpm for the upcoming GStreamer
> >Red-Carpet channel.
>
> its *extremely* important not to confuse the source code available
> from ladspa.org with the API defined by the single header file called
> ladpsa.h.
>
> the cmt plugin set is just one set of sample plugins. they are useful,
> but they are not "LADSPA".
>
> there is no packaging to be done for a LADSPA SDK - this is
> misconception i've seen here a few times. LADSPA is completely defined
> by the header file, and nothing else (at this time).

Right but that does not mean it cannot (or should not) be
packaged. A package with just that header file and any docs
that come with it would do. I do have one for ladspa as part
of the planet ccrma set of rpms but I did not at the time
split the binary examples that come with it. Will do that in
the next version, that's a good point.

-- Fernando

[linux-audio-dev] Re: [Alsa-devel] XRuns and Low-Latency

[Fernando Pablo Lopez-Lezcano]

> >Would it be possible to return better values for:
> >
> >snd_pcm_hw_params_get_channels_min / max
> >snd_pcm_hw_params_get_rate_min / max
> >
> >when the plug layer is used?:
> >min_ch: 1
> >max_ch: 1073741823
> >min_rate: 1
> >max_rate: -1
> >
> >This way the users has to enter how many channels he want's to have. And I
> >hav e no possibility to check the count or provide meaningfull defaults or
> >selecta ble ranges for the card ... - and using the hw:x directly I have to
> >provide a ll format convertions myself ...
>
> this has been discussed on alsa-devel quite a lot in the last 2
> weeks. i suggest you start by reading the archives for that list, and
> then continue the discussion there.

Yep, it has been discussed a lot :-)

> basically, the values the plug layer returns are factually correct,
> and you are asking for something that ALSA doesn't properly or fully
> support at this time (which as you observe is something like "please
> add various parts of the plug layer, but not all it"). it may be that
> jaroslav or abramo or fernando added a patch recently to cover the
> channels case specifically.

Jaroslav and Abramo have added configuration options that help
somewhat. There is currently a configuration option for the
alsa.conf file that enables you to turn the completely correct
(but completely useless as well) number of channels returned
by querying the configuration space of a plug pcm. Something
like this should do it:

pcm.testchan {
  type plug
  slave {
pcm hw
channels unchanged
  }
}

>From alsa-lib's asoundrc.doc:

[format STR]# Slave format (default nearest) or "unchanged"
[channels INT]  # Slave channels (default nearest) or "unchanged"
[rate INT]  # Slave rate (default nearest) or "unchanged"

You can also make format and/or rate reflect the slave pcm's
supported formats or rates.

You may also find that alsa-lib does "mixing" behind your back
when the number of channels opened are less than the available
channels in the hardware interface that's hidden behind the
plug layer, adding this route_policy to the plug definition
will get rid of that behavior:

pcm.testchan {
  type plug
  slave {
pcm hw
  }
  route_policy copy
}

Jaroslav has hinted that there are internal functions in
alsa-lib that would make a programmatic equivalent feasible,
but there's no access to them from the current api (I'm not
going to touch them as they might change at any time). I
believe that at some point an API will _have_ to be designed
to get around this limitation of the plug pcm api. I may be
wrong, but I suspect that more and more programmers will ask
about how to circumvent this feature as they try to use the
api in real world applications. At this point it is not
possible (AFAIK) to write a program that queries an arbitrary
pcm and works equally well with hw or plug pcms, without
relying on an external configuration file to sanitize the
query results.

-- Fernando

Re: [linux-audio-dev] LAAGA vs ALSA ... silent for a while

[Fernando Pablo Lopez-Lezcano]

[Abramo wrote]
> I think that the best solution would be the integration of
> ALSA with LAAGA (with obvious mutual benefits). This likely
> means some changes to ALSA API too.

I would like LAAGA to be a fast, lean, easy to use, higher
level (than the sound driver itself) API that _hides_ the
hardware interface completely from all clients that use it. It
seems to me that it should be kept separate from the driver
itself so that it can potentially be ported to other drivers
and or platforms.

-- Fernando