Re: [linux-audio-dev] Low-latency audio over IP
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
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] NPTL/2.6 (was snd-hdsp oddities)
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
On Sun, 2004-06-13 at 14:58, Fons Adriaensen wrote: New releases of Aeolus and Jaaa are now available at http://users.skynet.be/solaris/linuxaudio 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] [ANN] New releases of Aeolus and Jaaa
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
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] [OT] marketing hype
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] [OT] marketing hype
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
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] re: [linux-audio-user] A bit of good news--paper now available for your viewing pleasure and/or comments
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] re: [linux-audio-user] A bit of goodnews--paper now available for your viewing pleasure and/or comments
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: [a-devel] Re: [Agnula-Developers] Re: [linux-audio-dev] Request to audio
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: [linux-audio-dev] regarding mobos and CPUs
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
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
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
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 DescriptorT::autogen() [with T = Cabinet]': Cabinet.cc:168: instantiated from here Descriptor.h:36: type `Cabinet' is not a base type for type ` DescriptorCabinet' make: *** [Cabinet.o] Error 1 -- Fernando
Re: [linux-audio-dev] caps 0.1.0
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] swh-plugins, freqtweak, fftw3 and the planet
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
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
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
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
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: linux-audio-dev Digest, Vol 2, Issue 24
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
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
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
[linux-audio-dev] Re: [Jackit-devel] Re: POSIX caps/realtime/root processes
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] Re: linux-audio-dev Digest, Vol 2, Issue 24
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
Re: [linux-audio-dev] Just for fun - Hearnet
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?
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 ...
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] calling all planet ccrma users ...
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] calling all planet ccrma users ...
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] New form of GPL licence that protects Linuxfrom proprietary world [was: New powermacs?]
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?]
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?
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
Re: [linux-audio-dev] latency and P4 hyperthreading?
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] Linux Audio Hardware Selection
(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
[linux-audio-dev] Re: [Jackit-devel] hangs with 2.4.20, jack and clients... one tinypatch latter
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?
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
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
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
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] 2.4.20 + lowlat +preempt +alsa + jack = dead computer
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
[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] 2.4.20 + lowlat +preempt +alsa + jack = dead computer
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] Re: [Jackit-devel]2.4.20 + lowlat +preempt + alsa + jack = dead computer
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, altsysrq-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
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
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: [linux-audio-dev] Re: [Jackit-devel] 2.4.20-rc1 + lowlat +preempt + alsa + jack = dead computer
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] Re: [Jackit-devel] 2.4.20-rc1ÂÂ + lowlat +preempt + alsa + jack = deadcomputer
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: [Jackit-devel] Re: [linux-audio-dev] Re: [Jackit-devel]2.4.20 + lowlat +preempt + alsa + jack = dead computer
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, altsysrq-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] Please test my MidiSport firmware loader
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 http://www.informatik.uni-halle.de/~ladischc/midisport_linux_firmware.html. 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
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 http://www.informatik.uni-halle.de/~ladischc/midisport_linux_firmware.html. 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: [Jackit-devel] Re: [linux-audio-dev] Re: [Jackit-devel] 2.4.20-rc1 +lowlat + preempt + alsa + jack = dead computer
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] Interesting USB MIDI master keyboards, do theywork with Linux ?
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] Re: [Jackit-devel] 2.4.20-rc1 + lowlat + preempt + alsa + jack = dead computer
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 the work with Linux ?
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 ?
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
Re: [linux-audio-dev] Re: The Image (usablity) problem from aMusicians point of view
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
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
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
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
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] App metadata intercomunication protocol..
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
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
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
> 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
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
Re: [linux-audio-dev] LAAGA vs ALSA ... silent for a while
[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
