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 audi

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 JAA

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

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

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 so

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. >

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 [

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 > > 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

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 s

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

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 s

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 l

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 s

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?

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

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? > > >> > > >> h

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.

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

> 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 no

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

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 ma

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

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 terminati

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

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 >

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

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

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... > > > > > >

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-grou

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

> 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 in

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 > > > > monit

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 > >

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.

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

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 t

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 sysad

[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 > > >

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

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 os

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 pi

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

> > >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 collecte

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. > > ye

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 def

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 acce

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 wo

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

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

an 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] >

[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

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

> 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

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 ju

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

> 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 > n

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

>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

[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 thi

[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 -

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

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

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 >

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 lin

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

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 som

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

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. > >

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

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 > > sy

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 som

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

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

> > 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

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 j

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, know

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,

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 minu

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.

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). >

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 > > . > > > > There are some di

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 > . > > There are some differences to

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

> >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 implementa

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). >

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

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

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 sh

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'

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

[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

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 (profess

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. >

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).

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,

[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

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

> > 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 go

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

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 unde

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 mon

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

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 samp

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

> >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 channe

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 hard