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
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
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
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
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]
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.
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
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
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
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?
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
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.
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
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.
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:
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 -
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
(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
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
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
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:
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
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
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
[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 +
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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).
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
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
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
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
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
> 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
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
[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
69 matches
Mail list logo
