On Monday 29 January 2007 18:22, Steve Harris wrote:
> > http://tapas.affenbande.org/lv2/ext/fixed-buffersize
> > http://tapas.affenbande.org/lv2/ext/power-of-two-buffersize
> Great idea. I've got some plugins that will benefit a lot by this. We
> should link to known extensions on the http://lv
On Monday 29 January 2007 09:08, Steve Harris wrote:
> Ah, well the host is not supposed to change port values during run()
> anyway, the idea in LADSPA (and LV2) is that the host should chop the
> run() block where port values change. In practice not all hosts do
> that, some just pick a suitably
On Monday 08 January 2007 15:51, Nedko Arnaudov wrote:
> jack_mixer version 2 released.
>
> jack_mixer is GTK (2.x) JACK audio mixer with look similar to it`s
> hardware counterparts. It has lot of useful features, apart from being
> able to mix multiple JACK audio streams.
>
> Changes since versio
On Friday 15 December 2006 21:24, Jens M Andreasen wrote:
> On Fri, 2006-12-15 at 22:00 +0200, Jussi Laako wrote:
> > Jens M Andreasen wrote:
> > > Now that mingo's (et al) RT patches are coming into mainstream, what is
> > > the corporate rationale behind it and the running order of urgency?
> > >
On Wednesday 25 October 2006 15:19, Clemens Ladisch wrote:
> Mulyadi Santosa wrote:
> > I also read that not all Linux kernel sound card driver enable the
> > internal card timer, thus the software must rely on system timer.
>
> Most sound cards don't have an internal timer that could be used for
>
On Wednesday 25 October 2006 18:28, Chris Cannam wrote:
> Me:
> > I'm not aware of anyone these days successfully
> > using Rosegarden with snd-rtctimer - if anyone out
> > there is, do say so.
>
> To test:
>
> * start RG (version 1.0 or newer)
> * go to Settings -> Configure Rosegarden -> Sequence
On Tuesday 26 September 2006 15:34, stefan kersten wrote:
> Florian Schmidt wrote:
> > And here's the question: A user suggested (and i'd like
> > this idea very much) that kontroll be able to make use of
> > other input devices attached to the computer (additional
&
On Tuesday 26 September 2006 14:20, Nicola Larosa wrote:
> Florian Schmidt wrote:
> > And here's the question: A user suggested (and i'd like this idea very
> > much) that kontroll be able to make use of other input devices attached
> > to the computer (addition
On Sunday 24 September 2006 22:26, Florian Schmidt wrote:
> On Sunday 24 September 2006 20:36, Florian Schmidt wrote:
> > P.S.: Ah, LASH support is still missing. Will add it right away (or at
> > least try) ;)
>
> done. have fun.
Ok and since i was bored, i also added OSC me
On Sunday 24 September 2006 20:36, Florian Schmidt wrote:
> P.S.: Ah, LASH support is still missing. Will add it right away (or at
> least try) ;)
done. have fun.
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
Hi,
this is a small announcement for a minor update for a minor piece of software,
and at the same time a question :) So here it goes:
Kontroll is a small utility that generates midi cc messages from the mouse
position. It is inspired by the MouseX and MouseY UGens in Supercollider. It
simply
On Wednesday 06 September 2006 16:30, nescivi wrote:
> On Wednesday 06 September 2006 16:25, Alfons Adriaensen wrote:
> > Any chance of this ever being supported in Linux ?
> >
> > http://www.marian.de/en/products/ucon_cx
>
> I believe they just need someone to write the drivers
>
> they did
On Sun, 23 Apr 2006 13:39:52 +0100
Steve Harris <[EMAIL PROTECTED]> wrote:
> On Sun, Apr 23, 2006 at 01:10:55 +0200, Florian Schmidt wrote:
> > thanks for taking the initiative on this! I would like to see a way for
> > the host to pass its native buffer size to the
On Sat, 22 Apr 2006 10:53:58 +0100
Steve Harris <[EMAIL PROTECTED]> wrote:
> Almost two years ago at the LA conference a bunch of us agreed that
> something need to be done to improve LADSPA, and on the approximate
> direction it should take.
>
> Anyway, I finally got round to making a sketch plu
On Mon, 17 Apr 2006 12:08:19 +0100
Gordonjcp <[EMAIL PROTECTED]> wrote:
> What's the consensus? Implement patch storage for plugins that don't
> really have that many controls, or just let the host worry about it?
Dunno, if there's concencus, but i'd say, let the host worry about it.
There's ma
On Tue, 04 Apr 2006 15:10:36 -0400
Lee Revell <[EMAIL PROTECTED]> wrote:
> On Tue, 2006-04-04 at 12:27 +0200, Alfons Adriaensen wrote:
> > For me:
> >
> > * operate at 48 and 96 kHz.
>
> Many users also demand 44.1 support, although I don't quite understand
> why.
errm, to be able to play au
On Tue, 28 Mar 2006 18:43:06 +0100
Robert Jonsson <[EMAIL PROTECTED]> wrote:
> On Tuesday 28 Mar 2006 10:13, Florian Schmidt wrote:
> <...>
> >
> > thing and now it _seems_ to build. We'll see..
> >
> > Flo
>
> Just curious, did it work out?
On Tue, 28 Mar 2006 10:44:08 +0200
Florian Schmidt <[EMAIL PROTECTED]> wrote:
> I _do_ have cvs lash installed and debian's ladcca package, too. I
> asssumed that because of the differing naming schemes i wouldn't run
> into trouble. Seems i was wrong.
Oh well, it se
On Tue, 28 Mar 2006 00:31:03 -0500
Dave Robillard <[EMAIL PROTECTED]> wrote:
>
> > What lash is this anyway? is the modern, useful, actually handy for
> > stuff lash as in http://www.nongnu.org/lash/ or the ladcca from dawn
> > of time one?
>
> 0.5.0+ versions of LASH do not contain the phrase "
On Mon, 27 Mar 2006 22:52:49 +0100
Robert Jonsson <[EMAIL PROTECTED]> wrote:
> This release note is for MusE 0.8.1.
> It is basically a bug fix release for a note-off bug that crept into 0.8.
> [Known issues]
> See the errata section on the homepage for the latest:
> http://www.muse-sequencer.org
On Mon, 27 Mar 2006 00:49:04 +0200
Florian Schmidt <[EMAIL PROTECTED]> wrote:
> http://tapas.affenbande.org/?page_id=42
Oh and i forgot to ask a question:
What is the canonical way for a gtk app to receive hotkey press events
regardless of window focus?
Flo
--
Palimm Pal
On Fri, 24 Mar 2006 00:24:07 +0100
Frank Neumann <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> this mail is just to inform you that registration for the 4th International
> Linux Audio Conference (or "LAC2006" for short), APril 27th-30th, in
> Karlsruhe,
> Germany, is possible as of now by visitin
On Wed, 15 Mar 2006 10:17:49 +0100
"Tobias Scharnberg" <[EMAIL PROTECTED]> wrote:
> Hello List,
> this might really be a dumb question, but anyway: When I have an
> Audio-Source on Line-In or MIC, what do I have to do to directly
> output it to LineOut?
>
> Is it possible to directly put it throu
On Mon, 6 Mar 2006 16:34:05 +0100 (CET)
Julien Claassen <[EMAIL PROTECTED]> wrote:
> Hi!
> Florian: What can such a lib do?I already have toggle-buttons, progressbars,
> labels and I'm working on text-entry-fields. Next thing is menus and
> mutiple-choice-buttons (radio-buttons, lists) and slide
On Sun, 5 Mar 2006 17:15:04 +0100 (CET)
Julien Claassen <[EMAIL PROTECTED]> wrote:
> Hi!
> First of all: Thanks for you prompt responses.
> Second: the lib is written in c++. Is it ok for my toggle(on/off)-buttons to
> just have a function that returns either 1/0 (true/false)?
> Third: Chris
On Sun, 12 Feb 2006 20:46:08 -0800 (PST)
"Kjetil S. Matheussen" <[EMAIL PROTECTED]> wrote:
> Das_Watchdog
>
>
> ABOUT
> -
> Das_Watchdog is a program heavily and shamefully inspired by the
> rt_watchdog program made by Florian Schmidt:
>
On Fri, 27 Jan 2006 10:02:06 -0800
[EMAIL PROTECTED] wrote:
> I would do it so that I have a potentially viable alternative to the
> current state of affairs, which is that I boot windows to do music.
>
> eXT is a decent program. The reason we don't get commercial apps on Linux
> is because no o
On Fri, 27 Jan 2006 08:29:51 -0800
[EMAIL PROTECTED] wrote:
> in another thread, Jorgen said that the input/output part of eXT on Linux
> will be Open Source, so the JACK wizards can JACKify it as soon as it is
> released.
Why would anyone do this? To generate more revenue for the author? This
is
On Sun, 15 Jan 2006 10:46:14 +0100
[EMAIL PROTECTED] wrote:
> Does someone have a very simple sequencer example?
> Something sending one note in 4/4?
> I don't get along with the timing of the alsa sequencer.
> I hope you can help me.
> Scar
Hi,
i don't know whether you want to send midi events
On Wed, 04 Jan 2006 17:42:44 +
Melanie <[EMAIL PROTECTED]> wrote:
> Been there, done that.
>
> IT actually enumerates _hardware_ sound cards - nothing in .asoundrc
> is recognized by this app.
Broken app. Every sane ALSA app should use the pcm device "default" by
default and should allow the
On Fri, 30 Dec 2005 17:04:24 +0100
Florian Schmidt <[EMAIL PROTECTED]> wrote:
> I also stumbled across some problems with sleep() and especially waking
> up when the sleep time has expired in the course of writing my
> rt_watchdog program. Sometimes the high prio SCHED_FIFO thread
On Tue, 3 Jan 2006 15:44:12 +0100 (CET)
Cedric Roux <[EMAIL PROTECTED]> wrote:
> Hello Linux Audio People,
>
> sverb is a CFDN order 15 reverb.
> It is available at:
> http://sed.free.fr/sverb
>
> 0.9 is the first public release.
>
> Any help/hacking/whatever is very welcome.
build failure rep
On Sun, 1 Jan 2006 13:18:09 +0100
[EMAIL PROTECTED] wrote:
> > in a low latency *live* system, "timing" doesn't really exist outside of
> > the current period. there is no concept of "when" that exists beyond the
> > end of the current period.
> to remove jitter i would delay all events i reciv
On Fri, 30 Dec 2005 19:01:46 +0100
Werner Schweer <[EMAIL PROTECTED]> wrote:
> higher priority thread can interrupt lower priority threads. What do
> you gain if the soundcard can interrupt the jack thread? I believe
> it does not matter.
Midi input is generating IRQ's, too (at least it appears
On Fri, 30 Dec 2005 18:40:20 -0500
Lee Revell <[EMAIL PROTECTED]> wrote:
> The relative priorities of the JACK and soundcard IRQs really don't
> matter because they never contend - one is woken up by the other.
This is true for the audio only case. Imagine for now, that MIDI
activity i shandled b
On Fri, 30 Dec 2005 20:54:53 +0100
"Ralf Beck" <[EMAIL PROTECTED]> wrote:
> Suppose a jack thread is running and your midiin device irq comes in but not
> through,
> because the device's irq thread has lower priority and does not get
> scheduled!
This is an interesting question: How is midi activ
On Fri, 30 Dec 2005 15:17:04 + GMT
"Chris Cannam" <[EMAIL PROTECTED]> wrote:
> - ALSA sequencer can sync to RTC, but the
> associated module (snd-rtctimer) appears to hang
> some kernels solid when loaded or used. I don't have
> much information about that, but I can probably find
> out
On Fri, 30 Dec 2005 11:54:56 -0500
Paul Davis <[EMAIL PROTECTED]> wrote:
> you don't know the correct priority to use. i imagine an api along the
> lines of:
true.
>
> jack_create_thread (pthread_t*, void* (thread_function)(void*),
> void* arg, int relative_to
On Fri, 30 Dec 2005 17:37:13 +0100
Werner Schweer <[EMAIL PROTECTED]> wrote:
> its right that MusE uses a RT midi thread to schedule midi
> events. ALSA is used only to deliver (route) midi events.
> I think this is the easiest possible solution and gives the app
> the best control over timing.
On Fri, 30 Dec 2005 10:41:46 -0500
Paul Davis <[EMAIL PROTECTED]> wrote:
> several people have wanted JACK to export a thread create call that
> would take care of the RT-ness. that way, if you can run JACK with RT
> scheduling, you can run a MIDI thread too, with no extra steps. it would
> also b
On Fri, 30 Dec 2005 15:17:04 + GMT
"Chris Cannam" <[EMAIL PROTECTED]> wrote:
Hi Chris,
> > and midi events are not queued
> > for future delivery but always delivered immediately.
>
> but this isn't -- Rosegarden always queues events
> from a non-RT thread and lets the ALSA sequencer
> kern
On Fri, 30 Dec 2005 16:03:44 +0100
Jens M Andreasen <[EMAIL PROTECTED]> wrote:
> Flo!
>
> Is it important for the midi thread priority to be above the soundcard
> IRQ, or is it enough to be above jackd?
This is not 100% clear to me. I'd figure it should be above soundcard
irq, too, just to be sa
On Fri, 30 Dec 2005 01:52:10 +0100
Florian Schmidt <[EMAIL PROTECTED]> wrote:
> On Fri, 30 Dec 2005 00:47:46 +0100
> Florian Schmidt <[EMAIL PROTECTED]> wrote:
>
> [snip]
>
> Hmm,
>
> forget this post :) I need to do some more testing first..
Ok,
my synth
On Fri, 30 Dec 2005 00:47:46 +0100
Florian Schmidt <[EMAIL PROTECTED]> wrote:
[snip]
Hmm,
forget this post :) I need to do some more testing first..
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
Hi,
i was wondering:
With the new shiny -rt kernels and realtime scheduling available to non
root users via the usual mechanisms, there's the possibility of really
finetuning an audio/midi system.
The main issue i am interested in is the interplay between midi and
audio in such a system. How to
On Wed, 7 Dec 2005 09:30:28 +0100
Stéphane Letz <[EMAIL PROTECTED]> wrote:
> jackd (of jackdmp in "synch" mode) where the server waits for all
> clients to finish in a given cycle require the used synchronization
> primitive to have a "wait with time-out" operation. Fifo can do that
> (us
On Fri, 25 Nov 2005 11:10:05 +1030 (CST)
Jonathan Woithe <[EMAIL PROTECTED]> wrote:
> One thing I will try next is recompiling ardour; perhaps there's something
> funny there. In any case though, does any of this ring a bell with anyone?
Did you try the --unlock jack switch?
Flo
--
Palimm Pal
On Wed, 23 Nov 2005 16:41:35 +1100
Dave Robillard <[EMAIL PROTECTED]> wrote:
> > This remains though :) So basically apps who save state to files should
> > ignore state files specified on the commandline when in LASH mode,
> > except for those apps that are unable to change the state file selecti
On Tue, 22 Nov 2005 20:01:05 +0100
Florian Schmidt <[EMAIL PROTECTED]> wrote:
> I ardour i try to hack around this by stripping "offending" commandline
> options from argv before passing it to lash_init..
Actually this doesn't work right.
> so the docs should
On Tue, 22 Nov 2005 15:34:14 +1100
Dave Robillard <[EMAIL PROTECTED]> wrote:
> > this line seems to be the culprit (liblash/loader.c):
> >
> > #define XTERM_COMMAND_EXTENSION "&& sh || sh"
> I don't know of anyone else actually using the terminal client stuff
> anyway, so I might just remove tha
On Sun, 20 Nov 2005 16:32:21 +0100
Florian Schmidt <[EMAIL PROTECTED]> wrote:
> The problem i see is: when the client in the term exits (either by means
> of LASH telling it to, or by sending i.e. a SIGINT), it just drops to a
> bash prompt instead of exiting the terminal.
Hmm,
Hi,
in the course of LASH'ifying jack_convolve i stumbled across the
LASH_Terminal client flag which specifies to LASH that the client wants
to be run in its own terminal when the session is restored.
The code for this is in
liblash/loader.c:121
The problem i see is: when the client in the t
On Tue, 15 Nov 2005 14:49:01 +0100
Alfons Adriaensen <[EMAIL PROTECTED]> wrote:
> The only place where I've seen prefetch used explicitly is in Brutefir's
> sse and 3dnow routines which I recently modified for use in one of my own
> projects.
I think libDSP does prefetch and cache alignment, SIMD
On Fri, 4 Nov 2005 20:21:51 +0100
Florian Schmidt <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> here
>
> http://affenbande.org/~tapas/rt_watchdog.tgz
Hi again.
Something is fishy. It just stopped working. And i don't know why. Maybe
something with kernel timer priori
Hi,
here
http://affenbande.org/~tapas/rt_watchdog.tgz
you find a small program which acts as a watchdog daemon that kills
runaway SCHED_FIFO tasks. It does so by setting up two threads:
- one high priority (99) consumer that runs every 3 seconds
- one low priority (1) producer that runs every
On Wed, 2 Nov 2005 18:46:03 +0100
conrad berhörster <[EMAIL PROTECTED]> wrote:
>
> Am Mittwoch, 2. November 2005 18:38 schrieb Florian Schmidt:
> >
> > Just for completeness sake: You can use the realtime lsm for 2.6.13 and
> > above, too. I would even recommend
On Wed, 2 Nov 2005 14:25:45 +0100
conrad berhörster <[EMAIL PROTECTED]> wrote:
> Am Mittwoch, 2. November 2005 14:02 schrieb Paul Davis:
> thanks paul,
> > > bash-3.00# chmod ugo+s /usr/local/bin/jackd
> > > bash-3.00# exit
> > > bash-3.00$ ls -la /usr/local/bin/jackd
> > > -rwsr-sr-x 1 root r
On Wed, 2 Nov 2005 15:30:49 +0100
conrad berhörster <[EMAIL PROTECTED]> wrote:
> Hello list,
> well i try to understand the reason of xruns. when will they appear?
>
> for me it's curious, that , while copy a big file (> 50MB ) or many small
> one,
> there are xruns. so, it seems, that it has
On Wed, 2 Nov 2005 11:05:34 +0100
Stéphane Letz <[EMAIL PROTECTED]> wrote:
> In Jackdmp we have tested 2 system for inter-process synchronization:
> fifo (the way it was done in regular jackd) and POSIX named semaphore
> (which are built on top of futex on recent system version)
>
> In both c
On Mon, 31 Oct 2005 10:57:46 -0500
Lee Revell <[EMAIL PROTECTED]> wrote:
> > Btw: i just discovered that pthread mutexes and condvars can have a
> > "process shared" flag which makes it possiblo to synchronize threads
> > across processes as it seems. Could be useful for jack, no?
> >
> > pthread
On Sun, 30 Oct 2005 14:14:19 +0100
fons adriaensen <[EMAIL PROTECTED]> wrote:
> On Sun, Oct 30, 2005 at 01:53:48PM +0100, Florian Schmidt wrote:
>
> > Oh i thought i read somewhere that when pthread_cond_wait it is not
> > guaranteed that anyone actually signalled. W
On Sun, 30 Oct 2005 13:36:41 +0100
fons adriaensen <[EMAIL PROTECTED]> wrote:
> This can still be so if the access to the shared data structure is
> regulated by the same mutex that protects the condition variable,
> provided that the operation on the shared data is very simple and fast.
True..
On Sun, 30 Oct 2005 14:03:39 +1100
Dave Robillard <[EMAIL PROTECTED]> wrote:
> On Sun, 2005-30-10 at 00:42 +0200, Richard Spindler wrote:
> > I read the tutorial at http://userpages.umbc.edu/~berman3/ , it uses
> > mutex+condition, is it okay to do this? Are there better ways?
>
> That's a wonder
On Fri, 28 Oct 2005 02:16:16 +0200
fons adriaensen <[EMAIL PROTECTED]> wrote:
> You could indeed make some processor that would regenerate
> a Morse signal (and also decode it on the fly). But you would
> have a difficult time trying to outperform human hearing in
> that application. For example,
On Fri, 30 Sep 2005 21:38:17 +0300
Jussi Laako <[EMAIL PROTECTED]> wrote:
> Hmmh, at least the documentation didn't state anything like that a while
> back (if I remember correctly). And at least my applications won't
> expect anything about the buffer size.
http://jackit.sourceforge.net/docs/ref
On Fri, 30 Sep 2005 01:02:47 +0300
Jussi Laako <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-09-29 at 23:14 +0400, Dmitry S. Baikov wrote:
> > Jackd needs buffers to be power of 2, and usb-audio - multiples of 1ms.
>
> I just verified jack to work with any buffer size using OSS backend.
Hi,
i think
On Wed, 14 Sep 2005 08:16:26 -0600
Hans Fugal <[EMAIL PROTECTED]> wrote:
> That's good to know about, thanks. I googled and found your page
> http://tapas.affenbande.org/?page_id=6 which shows me how to set the irq
> handler prio, however my soundcard seems to be sharing with my video
> card. Do y
On Wed, 14 Sep 2005 16:01:12 +0200
Florian Schmidt <[EMAIL PROTECTED]> wrote:
> > Ok, I understand that. So I take it if you set qjackctl priority to 0,
> > it will not specify it and therefore use the JACK default which is >=2?
> > I tried setting -P to 2 in qjackctl
On Wed, 14 Sep 2005 07:55:16 -0600
Hans Fugal <[EMAIL PROTECTED]> wrote:
> > there's no priority 0 for SCHED_FIFO threads AFAIK, thus, as jackd runs
> > at the prio specified via the comandline, the watchdog at prio +10 and
> > the clients at prio -1, you effectively get a prio of 0 for the client
On Wed, 14 Sep 2005 07:33:58 -0600
Hans Fugal <[EMAIL PROTECTED]> wrote:
> So you're saying jackd should run at priority 1 or higher, and we ought
> to check for that? I could probably manage such a patch, but running at
> priority 1 is what was causing this error for me with jack apps. Is
> there
On Wed, 17 Aug 2005 20:32:17 +0100
James Stone <[EMAIL PROTECTED]> wrote:
> Problem with libconvolve: doesn't automatically create libconvolve.a with
> resulting problems from ld not being able to find it.
>
> I had to manually do:
>
> ar cru libconvolve.a libconvolve.so.0.0.4
>
> ranlib libco
On Wed, 17 Aug 2005 19:30:00 +0100
James Stone <[EMAIL PROTECTED]> wrote:
>
> > I cannot build libconvolve though because it depends on libdsp which is
> > not available for Debian any more (AFAIK) and the source tarball seems to
> > depend on NPTL headers (which do not seem to exist on my machin
Hi,
this is the first public tarball of dssi_convolve, a DSSI wrapper around
libconvolve.
grab here:
http://affenbande.org/~tapas/jack_convolve/dssi_convolve-0.0.2.tgz
you need libconvolve-0.0.5.tgz for this, too (fixed some minor bugs)
http://affenbande.org/~tapas/jack_convolve/libconvolve-0.
s. subject. down for me for quite a while already.
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
On Wed, 10 Aug 2005 14:09:55 +0200
Alfons Adriaensen <[EMAIL PROTECTED]> wrote:
Hi,
thanks for your answer.
> Sorry, I didn't express myself correctly. There is indeed more delay,
> but what I'd wanted to say is: there is no need for copying your signal
> into one more layer of intermediate buff
On Wed, 10 Aug 2005 12:01:17 +0200
Alfons Adriaensen <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 10, 2005 at 11:34:39AM +0200, Florian Schmidt wrote:
>
> > a] is it possible to use threading in a DSSI?
>
> I've done this in some LADSPAs, it works.
Great..
>
>
Hi,
i played around with extra buffering the input/output of libconvolve
(new tarball [1] and updated jack_convolve [1] (understands the
--partitionsize=frames argument now which makes it use the specified size
for the partition size instead of the jack buffersize), and like
expected this doesn't
Let's hope for the best :)
Begin forwarded message:
Date: Fri, 05 Aug 2005 03:35:40 -0700
From: [EMAIL PROTECTED] (Debian Bug Tracking System)
To: Florian Schmidt <[EMAIL PROTECTED]>
Subject: Bug#266507 acknowledged by developer (Bug#266507: fixed in
glibc 2.3.5-3)
On Fri, 05 Aug 2005 11:52:44 +0200
Mario Lang <[EMAIL PROTECTED]> wrote:
> Reusability of code is a quite valid point, and I thought the OP's
> question was quite interesting.
>
> We shouldn't define ourselves in terms of what windows does. Frankly, I don't
> care anymore, its now 8 years since
On Fri, 29 Jul 2005 13:45:09 -0400
Lee Revell <[EMAIL PROTECTED]> wrote:
> Disk IO priorities have been discussed on the list before, and they are
> now in the mainline kernel (search LKML for "IO priorities" for
> details). I think they're only supported by the CFQ scheduler.
>
> This might be
latency. Though,
> somehow I think that everyone needs a good balance between the two.
I suppose to make everyone happy this should be runtime configurable.
Incorporating which would be quite a task :)
Regards,
Florian Schmidt
--
Palimm Palimm!
http://affenbande.org/~tapas/
On Wed, 13 Jul 2005 10:49:11 -0400
Eric Dantan Rzewnicki <[EMAIL PROTECTED]> wrote:
> > Correct, it's not an issue for apps driven by hardware interrupts like
> > JACK, because the sound card consumes data at a constant rate. But for
> > MIDI or video where you have to periodically push data to t
ltime processes that depend on events that are
triggering interrupts (like soundcards' irqs) the timer interrupt really
doesn't matter. I'm not sure at all though this applies to midi handling
(and especially to alsa_seq when routing from one app to another) or is
even correct in any se
On Wed, 6 Jul 2005 22:43:39 +0200
Christoph Eckert <[EMAIL PROTECTED]> wrote:
>
> > I know my opinion is unpopular, but afaik OSS is more of a
> > standard in the unix (not linux) world than ALSA is.
> > There's no way around providing an OSS emulation that works
> > (i mean sw mixing, etc.) for
On Sat, 02 Jul 2005 00:17:38 -0400
Lee Revell <[EMAIL PROTECTED]> wrote:
> No!!! That's exactly the wrong approach, it will only encourage
> applications to use the OSS API. Do you really still want to be using
> the same ancient binary-only flashplayer/realplayer plugin for 5 more
> years?
>
>
On Wed, 29 Jun 2005 23:07:24 +0200
fons adriaensen <[EMAIL PROTECTED]> wrote:
> > Another very useful feature would be tail extension (combine convolution
> > with traditional reverb processing to lighten the CPU load)
>
> I don't think this requires special support from the convolution
> engine
On Wed, 29 Jun 2005 16:19:34 +0200
Alfons Adriaensen <[EMAIL PROTECTED]> wrote:
> I wrote a convolver library / JACK app similar to Florian's at
> about the same time (which is why it was never released).
> Main differences are that the API is a bit more general, it's C++,
> and it has the require
On Wed, 29 Jun 2005 13:20:31 +0200
Benno Senoner <[EMAIL PROTECTED]> wrote:
> assume we run convolution at 512 samples.
>
> process(float *input,float *output, int numframes) {
>
> if(numframes == 512) {
> convolve(input, output, 512);
> return;
> }
This has a subtle bug afaict. L
On Tue, 28 Jun 2005 21:38:32 +0100
Chris Cannam <[EMAIL PROTECTED]> wrote:
> It does seem a shame not to end up with a DSSI plugin as well, then,
> given that it would then have much the same structure already.
Yeah, you definetly are right. I wonder though:
Why stop at garanteeing a fixed buff
On Mon, 27 Jun 2005 14:24:36 + GMT
"Chris Cannam" <[EMAIL PROTECTED]> wrote:
> Florian Schmidt:
> > P.S.: I am also currently working on a qt app which
> > uses libconvolve
>
> Any interest in making a DSSI plugin?
There are some problems with wrapping
On Mon, 27 Jun 2005 16:06:54 +0200
fons adriaensen <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 27, 2005 at 01:57:34PM +0200, Florian Schmidt wrote:
>
> > Assume a samplerate of 96khz, then there's quite a bit of signal which
> > doesn't need to be processed since
On Mon, 27 Jun 2005 13:57:34 +0200
Florian Schmidt <[EMAIL PROTECTED]> wrote:
> i added an experimental feature to libconvolve/jack_convolve which might
> be able to preserve some of those precious cpu cycles from being burnt.
nyuk nyuk, link here:
jack_convolve:
http://www.af
Hi,
i added an experimental feature to libconvolve/jack_convolve which might
be able to preserve some of those precious cpu cycles from being burnt.
jack_convolve now has commandline switches --min_bin=bin_no and
--max_bin=bin_no which can be used to specify which bins of the fourier
transformed
On Mon, 20 Jun 2005 22:26:54 +0200
Tim Orford <[EMAIL PROTECTED]> wrote:
> > Now there's Apps B and C. B should be in sync with A's first track and C
> > should be in sync with A's second track.
> >
> > Don't know if this is really overkill though. I would find it useful..
>
> i wouldnt use it p
On Mon, 20 Jun 2005 20:49:36 +0200
Tim Orford <[EMAIL PROTECTED]> wrote:
> > The reason for this opinion of mine is that musical time is simply too
> > complex to be handled by one general mechanism. Think of different apps
> > using different meters, etc.. Or even a single app using different
> >
On Mon, 20 Jun 2005 11:57:24 -0300
Juan Linietsky <[EMAIL PROTECTED]> wrote:
> I talked with florian schmidt on irc about this, some time ago.
> But my impression from what he said is that most jack
> developers wanted to keep tempo map sharing in a
> separate library, not in
On Mon, 20 Jun 2005 09:50:53 -0400
Paul Davis <[EMAIL PROTECTED]> wrote:
> > -Jack lack of OSC or any way to do parameter automation from the sequencer
>
> name one platform that allows this. just one.
There's none that i know of, but it would be cool to have anyways :)
> > -It is Impossible to
On Thu, 16 Jun 2005 23:54:01 +0200
fons adriaensen <[EMAIL PROTECTED]> wrote:
> Strange... If you would program a timer using the info available from
> jackd's DLL, it would never generate its interrupt before the HW is
> ready (i.e. has at least a period available). It would actually trigger
> j
On Thu, 16 Jun 2005 20:20:41 +0200
fons adriaensen <[EMAIL PROTECTED]> wrote:
> > The price for this is afaik an extra period worth of latency. I'm not
> > sure this is the way to go. Sure it makes handling of devices easier
> > that do not generate irq's like pci soundcards do (all this USB and
>
On Thu, 16 Jun 2005 10:30:29 -0400
Paul Davis <[EMAIL PROTECTED]> wrote:
> true, but i take it you get the way CoreAudio is doing it: it means you
> can drive audio processing from a different interrupt source (e.g.
> system timer) because you have very accurate idea of the position of the
> h/w f
1 - 100 of 221 matches
Mail list logo
