On Wed, Aug 13, 2003 at 08:09:19 -0400, Paul Davis wrote:
> >- Somewhat related to the item above, a plugin's run() method computes exactly
> >one sample at each call, not a block of samples. This is again a matter of
>
> perry cook's SDK does this too. everybody knows its cool, just as
> everybo
On Wed, Aug 06, 2003 at 09:31:17 +0300, Jussi Laako wrote:
> This performance penaly is _very_ significant on Intel CPUs and rather
> low on AMD ones.
That explains why I've been getting bug reports from P4 users, and cant
reproduce it on my athlon, thanks.
There were several serious bugs with gc
On Wed, Aug 13, 2003 at 09:40:29 -0400, Pete Yadlowsky wrote:
> Yes. I believe double-precision is the standard data type used by most
> floating-pt processors. Single-precision floats must first be converted to
> doubles at each computation, thus actually degrading performance slightly.
This is
On Thu, Aug 14, 2003 at 09:48:45AM +0100, Steve Harris wrote:
> I would activly encourage people who are interested in this subject to
> learn what they are doing before entering the fray. GMPI needs more random
> unevaluated ideas like it needs a hole in the head.
This is a bit harsh,
Its a replacement for AC97, saw it mentioned in last months
sound-on-sound, sounds like it might enable ALSA to support all the azalia
cards with one driver (hah!)
http://www.extremetech.com/article2/0,3973,901691,00.asp
http://www.eetimes.com/sys/news/OEG20030221S0043
- Steve
On Mon, Aug 04, 2003 at 07:35:42 +0300, Jussi Laako wrote:
> On Sun, 2003-08-03 at 21:42, Steve Harris wrote:
>
> > I should play with it somemore, its possibel that you can tell the 387 to
> > ignore the exceptions.
>
> See /usr/include/fpu_control.h
Thanks, and Hmmm
On Sat, Aug 02, 2003 at 11:14:25 +0300, Jussi Laako wrote:
> On Thu, 2003-07-31 at 11:45, Alfons Adriaensen wrote:
> > Do you know of a *very fast* (probably inline assembly) way to force
> > denormal FP numbers to zero ?
>
> If I remember correctly, SSE does flush-denormals-to-zero by default.
Y
On Sun, Aug 03, 2003 at 07:47:31 +0100, Simon Jenkins wrote:
> Here's where I've got to so far. Comments are welcome.
Looks fine in theory, but it forces an extra branch per MUL, which is not
really practical.
I haven't had a chance to try your fixes to FLUSH_TO_ZERO, but I'l try
this week.
- St
On Fri, Aug 01, 2003 at 11:36:22 +0100, Simon Jenkins wrote:
> There are some limitiations though:
Those are all good points, but my concerns are that I dont think it
actually does what its supposed to do :)
It could be the pointer aliasing + optimisation thing thugh, I'l check it
out.
- Steve
On Fri, Aug 01, 2003 at 05:31:27PM +0200, Frank Barknecht wrote:
> Hallo,
> Hans Fugal hat gesagt: // Hans Fugal wrote:
>
> > Is there a Csound-esque 'music compiler' that uses LADSPA plugins? It
> > need not read Csound files, just have a similar approach: describe the
> > music and sounds in tex
On Fri, Aug 01, 2003 at 01:39:29PM +0200, Fabien Costantini wrote:
> Hi, I very interested into DSP modelisation techniques
> and more precisely about Guitar preamps modelisation techniques.
>
> Anyone have some resources, any SoA / Paper related to this subject ?
There isn't very much out there,
On Thu, Jul 31, 2003 at 10:45:01 +0200, Alfons Adriaensen wrote:
> On Thu, Jul 31, 2003 at 09:26:49AM +0100, Steve Harris wrote:
> > Several people have asked me what denormal numbers are over the last few
> > weeks, well heres a much better description than my rambling head
>
Several people have asked me what denormal numbers are over the last few
weeks, well heres a much better description than my rambling head
scratching: http://www.ecs.soton.ac.uk/~swh/denormal.ps
Its an extract from David Goldberg's article, "What Every Computer
Scientist Should Know about Floating
On Fri, Jul 25, 2003 at 04:58:35 +0300, Juhana Sadeharju wrote:
> >From: [EMAIL PROTECTED] (Ingo Oeser)
> >
> >For people like you gcc supports -fvolatile.
> >
> >Your code will be really slow, but you save typing 'volatile' where the
> >C-Compiler needs it.
>
> So, there is no "do not optimize aw
The person to ask would be Fernando from CCRMA, I have an RH9 lowlat
machine, and I haven't noticed any problems, but I cant run that machine
at very low latencies anyway due to soundcard suckiness.
I think I would have noticed if SCHED_FIFO was just ignored.
- Steve
On Thu, Jul 24, 2003 at 02:0
On Tue, Jul 22, 2003 at 03:51:20PM -0400, Paul Davis wrote:
> i guess i should get it connected to the net, and run up2date as well,
> eh?
Yes, you should do that anyway for security reasons.
- Steve
On Tue, Jul 22, 2003 at 02:16:20PM -0400, Paul Davis wrote:
> i'm trying to install nando's wondrous package collection on RH8.0. it
> seems that the alsa-lib RPM has a dependency on GLIBC-2.3.2, which
> doesn't appear to exist on RH8.0.
>
> has anyone run into this?
No, my rh8 machine has glibc-
On Fri, Jul 11, 2003 at 05:18:01 +0200, Robert Ross wrote:
> I need to allow multiple programs/processes to take data from the same
> audio device at the same time.
You can do this with jack, http://jackit.sf.net/
- Steve
On Tue, Jul 08, 2003 at 12:25:36PM +0200, Robert Jonsson wrote:
[LUFS]
> But I wonder if it is that great in a LAN, it might not be that low-latency
> since it's in mainly in user-space. But then again, that might only be a
> problem if streaming audio, and that was perhaps not the primary usag
On Tue, Jul 08, 2003 at 11:53:21AM +0200, Maarten de Boer wrote:
> > http://shfs.sourceforge.net/
>
> LUFS looks quite a bit more mature.
>
> http://lufs.sourceforge.net/lufs/
Thanks, I'l have a look at that.
- Steve
On Tue, Jul 08, 2003 at 10:46:50AM +0200, Maarten de Boer wrote:
> > for the record, plain old nfs has always worked for me. any reasons you
> > are not just using that ? (ok, i know it sucks in many respects,
> > esepcially security, but then low latency audio implied a trusted
> > environment
On Mon, Jul 07, 2003 at 12:49:31PM +0200, Joost Yervante Damad wrote:
> I was thinking about having 32 input control ports that define the
> waveshape, but also about a 33th input control port that allows someone
> to select a "preset" wave-form. (e.g. 1=sound1, 2=sound2, ...)
> It would be ideal
On Mon, Jul 07, 2003 at 11:50:00AM +0200, Alfons Adriaensen wrote:
> As to internationalisation, I received a request some time ago to
> integrate gettext support in the moogvcf plugins. Thinking about
> this, my conclusion was that the code required to do this should not
> be in each and every plu
On Sun, Jul 06, 2003 at 05:12:08PM -0500, Tom Felker wrote:
> VLevel is written in C++. I have two questions. First, why do most
> other plugins allocate and free copies of their strings and structures,
> instead of just passing the literal (as I do)?
Because thats what the example one does. As
On Fri, Jul 04, 2003 at 05:26:43 +, Joern Nettingsmeier wrote:
> hi everyone !
>
> while i'm slowly getting in linuxtag mode, it occured to me it might be
> nice to direct booth visitors with very specific questions to the
> developers themselves...
> so if any of you are hanging out on #lad
On Tue, Jun 24, 2003 at 11:19:52AM -0400, Marc Lavallée wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Le 24 Juin 2003 10:35, Andrew Burgess a écrit :
> > >Also for sound limiter (compressor) algorithms .
> >
> > Sox has a compander and there is also a Dyson compressor LADSPA plugin.
Peak amplitude is just that - the largest abs sample value since you last
read it.
RMS is calculated by summing sqaured samples over some period of time then
taking the sqrt of the mean.
Limiters and compressors are much trickier.
On Mon, Jun 23, 2003 at 05:50:08 +0300, Ralfs Kurmis wrote:
> Hi
On Wed, Jun 18, 2003 at 08:54:41AM -0400, Paul Winkler wrote:
> there are more sophisicated techniques, i guess involving analysis of the signal
> and generating sine waves based on the analysis... but mine can be
> quite useful. I would love it if somebody made a LADSPA plugin out
> of this algo
On Tue, Jun 17, 2003 at 09:20:45 +0200, Joern Nettingsmeier wrote:
> >Early registrations (email either me or Frank Neumann
> >)
> >would help us to estimate the approximate scale of the event which can be
> >even larger than last time.
>
> sign me up!
Yeah, me too. It was great.
> >If you ca
On Tue, Jun 17, 2003 at 11:35:41AM -0400, Dave Phillips wrote:
> I wrote a carefully worded and encouraging message to their support
> department. They are a successful company with a broad base of users, so
Didn't they just file for chapter 11? By the power of google...
http://news.harmony-centra
On Wed, Jun 18, 2003 at 09:53:13AM -0500, happyguy wrote:
> Is this avenue worth pursuing further, or should I look beyond a $1700
> PwPulsar and find another DSP/DAW dev platform? Anyone have any leads?
> I ran into TCelectronics Powercore Firewire which seems decently
> assembled, but I do not
On Thu, Jun 12, 2003 at 09:42:40AM -0700, Tim Hockin wrote:
> > I'm new to OSS Programming, and I'm attempting to play some 8bit wav files.
> > However OSS is telling me that my sound card will not play 8bit , only 16bit.
> > If I force it. The sound changes pitch, and is very fast. ( obviously ).
On Thu, Jun 12, 2003 at 11:18:53AM -0400, Derrick wrote:
> I'm new to OSS Programming, and I'm attempting to play some 8bit wav files.
> However OSS is telling me that my sound card will not play 8bit , only 16bit.
> If I force it. The sound changes pitch, and is very fast. ( obviously ).
>
> Is t
http://plugin.org.uk/meterbridge/meterbridge-0.9.2.tar.gz
* Fixed bug in peak detection code
* Slight efficiency improvements
* Fixed crash bug when too many meters are requested
* Increased maximum number of meters
- Steve
On Sat, Jun 07, 2003 at 03:35:05 +0200, Torgeir Strand Henriksen wrote:
> lør, 07.06.2003 kl. 14.36 skrev Vincent Touquet:
> > What I do know about this, is that it is illegal from the VST SDK
> > license point of view to redistribute their headers with some GPL sources,
>
> Yes, we only intend t
On Wed, Jun 04, 2003 at 01:42:17PM +0200, Jay Vaughan wrote:
> >keep in mind yamaha's announcement that they would be using linux in
> >most of their keyboards starting within a year or so.
>
> I heard about this announcement as a rumoure but haven't seen
> anything 'official' on it. However if
On Tue, Jun 03, 2003 at 06:58:03 -0700, Fernando Pablo Lopez-Lezcano wrote:
> > > 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 i
On Tue, Jun 03, 2003 at 10:19:15 -0700, Fernando Pablo Lopez-Lezcano wrote:
> 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
On Tue, Jun 03, 2003 at 06:44:08PM +0300, Juhana Sadeharju wrote:
> MVC sure is a great thing, but I would like to see a concrete
> toolkit or a hint list which helps me in making perfect MVC
> code immediately. Is it even possible to write a MVC toolkit?
> What would be in such a toolkit?
GTK has
On Tue, Jun 03, 2003 at 10:50:26AM +0200, Vincent Touquet wrote:
> I must say I really like the jack api and ladspa.
> One thing that is unfortunate (others would call it
> a strength), is the lack of a unified set of widgets we
> could use to build plugin guis from (or any application
> for that
http://plugin.org.uk/releases/0.4.2/
Highly recomended upgrade for 0.4.x users.
Changes:
* Great new set of filter plugins from Alexander Ehlert
* Applied patch from Anand Kumria to make it build with gcc 3.3
* Rewrote the flanger modulation code - its not optimised, but should work
* Added supp
On Thu, May 29, 2003 at 04:28:07 -0700, Josh Green wrote:
> void rdtsc(unsigned int *lsi, unsigned int *msi)
> {
> __asm__ ("rdtsc" : "=a" (*lsi), "=d" (*msi));
> }
There is an ll version that writes directly to a 64bit int.
c.f. msr.h
- Steve
On Thu, May 29, 2003 at 04:23:48 -0600, jacob robbins wrote:
> I'm a little green at time measurement facilities available in linux,
>
> In my host, I would like to be able to measure how much time each
> individual LADPSA plugin takes. Assuming I do realtime work with the
> smallest buffer size
On Thu, May 29, 2003 at 06:20:34 -0400, Paul Davis wrote:
> what would be *really* bad is if they actually changed the code so
> that attempts to set SCHED_FIFO are not honored because they believe
> they are useless. i don't know which of these is true.
My main dev machien is RH9 and I haven't no
On Sun, Apr 06, 2003 at 01:10:17PM +0200, Ingo Oeser wrote:
> > Sure, it will only work on architectures where 32bit reads and writes are
> > atomic.
>
> That is not even true on all ix86 machines. At least I've seen
> special memory ordering barriers used in the kernel for newer
> ix86 machines
On Sat, Apr 05, 2003 at 10:44:01AM -0500, Dave Phillips wrote:
> Steve, what about time compression/expansion, the harmonics generator,
> and the all-important karaoke plugin ?
Hmm... I hadn't though about time compression etc. as its not allowed in
LADSPA.
I suggest that a system that categorise
On Sat, Apr 05, 2003 at 06:15:09 +0200, Ingo Oeser wrote:
> Now make that thread-safe and esp. thread-safe on an architecture
> with weak memory ordering and all the fun stuff.
Sure, it will only work on architectures where 32bit reads and writes are
atomic.
> If you have that all working and lo
Hi all,
After the LAD Conference and using apps which used the lrdf taxoomy
(putting plugins into categories) code it became obvious the the current
taxonomy wasn't really useful.
the current taxnomy looks like:
Utilities
Generators
Oscillators
Simulators
Reverbs
Time
Delays
Phas
There are many cases in audio software when you are only concerned with
reading single values at a time from the fifo and relative delays, then
its much simpler [from memory, syntax might be wrong]:
unsigned int size = some_power_of_two
unsigned int write_ptr = 0
float buff
On Fri, Apr 04, 2003 at 07:48:20 -0500, Paul Davis wrote:
> there is one aspect of the LFRB that bothers me. as has been explained
> many times, the monotonic motion of the read/write pointers is
> key. but when one the reader/writer moves the pointer to the end of
> the buffer and wraps it around,
http://www.fftw.org/
Just a headsup for all the people who link against it. Hopefully they've
normailised the build system now...
Looks pretty good, now includes SIMD optimisations.
- Steve
On Fri, Mar 21, 2003 at 08:36:57 +0100, [EMAIL PROTECTED] wrote:
> galan saves against the label.
> I wanted to change this to the UID after thinking the label was not
> unique. But if i get this right the label is unique. And then i will
> leave it like it is.
The label is not unique.
Making it
On Sat, Mar 22, 2003 at 08:30:22 +, Simon Jenkins wrote:
> Something has to make this ramp/curve(/whatever), because at its
> source (eg UI widget or incoming midi message) the toggling of a
> switch *is* an event. But the rise and fall characteristics should
> belong to the owner of the source
It appears to be some kind of latency optimisation for busses, but I can;t
really work out what it does. Theres a whitepaper about it here:
http://www.sis.com/hs_tech/
The claim is that it can reduce system latency by proritising certain
streams. I think. If you could express these priorities to t
On Thu, Mar 20, 2003 at 03:27:15PM +0900, Patrick Shirkey wrote:
> I found it hilarious that the writer found that Linux is not viable
> because none of the *big names* in audio software support it.
There does seem to be a belief that the brand actually imparts some
qualities to the bits and byte
On Wed, Mar 19, 2003 at 11:57:35 +0100, Dr. Matthias Nagorni wrote:
> On Wed, 19 Mar 2003, Steve Harris wrote:
>
> > etc.) and it doesn;t solve the immediate problem of UIs that cannot be
> > succesfully represented in XML, eg. (my favourite exmaple) a lowpass
> > fil
On Wed, Mar 19, 2003 at 10:33:40 +0100, Martin Voelkel wrote:
> Martin Voelkel writes:
> > i could not found any hint about the license of matt wright's library,
> > he always says "OpenSource", which is not necessarily "free". will
> > ask him about this.
>
> o.k. each file says:
>
> >>
> Permi
On Tue, Mar 18, 2003 at 01:19:37 -0800, Thomas Webb wrote:
> > You cant generate "normal" DSP code from C as it
> > tends to be fixedpoint,
> > and C doesn't support it.
> >
> > - Steve
>
> Yeah, fixed point DSPs are cheaper, no? I wasn't
> suggesting using a C compiler to generate assembler. I
>
On Wed, Mar 19, 2003 at 09:32:34 +0300, Roman Kaljakin wrote:
> > What I like about this solution is that it would not only allow to share
> > modules among the many softsynths, but it could also be used to solve the
> > GUI/Toolkit problem. Namely one could also express the GUI layout
> > informat
On Tue, Mar 18, 2003 at 04:53:42 -0500, Paul Davis wrote:
> >Hey, the broken-record technique works ;)
>
> it sure does. what would you like me to repeat next ?
>
> >> probably at least a half-dozen companies doing this today - should
> >> they all sit down and work out how to make their stuff in
On Tue, Mar 18, 2003 at 11:41:38 -0500, Ivica Bukvic wrote:
> As you can see OSC is very powerful and already present in a number of
> apps. While LADSPA protocol might be also very useful, it implies that
> the module or synth is presented in a LADSPA plugin form, while OSC can
> also manipulate s
On Tue, Mar 18, 2003 at 08:35:30 +0100, Lukas Degener wrote:
> >
> >
> >I'm new to LADSPA, but isn't that what LADSPA control
> >protocol does?
> >
> Dunno. have to do some reading. What is Open Sound Control?
Its a synthesis focused message passing protocol. Generally run over UDP.
Pretty popula
On Tue, Mar 18, 2003 at 10:25:47 -0800, Thomas Webb wrote:
> I'm new to LADSPA, but isn't that what LADSPA control
> protocol does? I think it would be better if there was
> something like that, but the plugin can work with or
> without the gui.
LCP is mostly hypothetical. There are some sample UI
On Tue, Mar 18, 2003 at 02:38:49 -0500, Paul Davis wrote:
> >problem of the hosts not completly implementing everything that is
> >supported by ladspa (until recently, i didn't know about this rdf
> >thingy, for instance.)
>
> that isn't actually part of LADSPA. its an example of the extreme eas
On Tue, Mar 18, 2003 at 10:27:42 -0800, Thomas Webb wrote:
> Here's an idea: find a way to conver these same XML
> files into dsp assembler. All the sudden, the same
> stuff you use to make a softsynth can be reused for a
> hardware synth!
You cant generate "normal" DSP code from C as it tends to
On Tue, Mar 18, 2003 at 01:31:28 +0100, Francois Dechelle wrote:
> On Tue, 2003-03-18 at 12:46, Steve Harris wrote:
>
> > Yes, but the ID number would be created from a hash of the unqiue
> > identifier (eg. a URI), so it would be consistant between sessions.
>
> W
On Tue, Mar 18, 2003 at 12:04:46 +0100, Francois Dechelle wrote:
> > A better solution would be to expand the ID space to 64bits, and reserve
> > the top bit's worth, which is plenty, but will break binary compatibility
> > of course.
>
> In any case, hosts that save the ID cannot restore the plug
[This is a conversation Francois and I have been having this morning.
There is a general problem with LADSPA wrapper plugins that create
plugins from other sources. Its not possible for them to pick unique IDs
as they dont know what has been assigned and what hasn't]
On Tue, Mar 18, 2003 at 10:
hangeLog:
2003-02-23 Steve Harris <[EMAIL PROTECTED]>
* Fixed memory leak in gate
* Fixed filter implementation in gate
* Fixed key defaults in gate
* Made passes=0 work in GSM
* Added bandlimiting filter to GSM (less cruchy sounds)
2003-02-24 Steve Harris <[EMAIL PROTECTED]>
On Thu, Mar 06, 2003 at 02:33:46PM -0500, rm wrote:
> On Thu, Mar 06, 2003 at 09:12:03PM +0200, Juhana Sadeharju wrote:
> > Hello. I need two functions:
> >
> > make_shm(int size, char *key)
> > -run by root
> > -creates a locked shared memory segment
> > -returns a key (preferably a string) wh
0.2.4 http://plugin.org.uk/lrdf/
liblrdf is a library for handling RDF files describing LADSPA plugins,
plus it can also do lightweight general RDF tasks.
Changes:
Added a pkgconfig file suppllied by Taybin
Fixed a buffer overrun triggered by rebuilding the caches
Fixed a bunch of memo
On Tue, Mar 04, 2003 at 09:56:36AM -0500, Paul Davis wrote:
> >On Mon, Mar 03, 2003 at 10:12:14 -0500, Paul Davis wrote:
> >> /* Hint LADSPA_HINT_OUTPUT_METER indicates that the value of output
> >>control port is likely to be most meaningful to the user if
> >>displayed as a meter. Can be
On Mon, Mar 03, 2003 at 09:36:09 -0500, Taybin wrote:
> Why have both? Couldn't the absence of one imply the presence of the
> other? And if there are both, it also implies that there are third and
> forth states of both and neither.
I think there is meter and/or text (ie. both if ou support bot
On Mon, Mar 03, 2003 at 11:44:12 -0500, Jesse Chappell wrote:
> Steve Harris wrote on Sat, 01-Mar-2003:
>
> > > There is no reason MOMENTARY needs to be restricted to TOGGLED
> > > controls. There just needs to be a hint to specify what the "inactive"
> &g
On Mon, Mar 03, 2003 at 02:26:44 +0100, [EMAIL PROTECTED] wrote:
> do i understand this correctly ?
> upon receipt of an event for a momentary CONTROL i set it to 1 for one
> process call ?
> and then back to 0...
Yes, thats correct.
If combined with the CONTROL hint it should be set for one samp
On Mon, Mar 03, 2003 at 10:12:14 -0500, Paul Davis wrote:
> /* Hint LADSPA_HINT_OUTPUT_METER indicates that the value of output
>control port is likely to be most meaningful to the user if
>displayed as a meter. Can be combined with LADSPA_HINT_LOGARITHMIC
>if the meter should use a lo
On Mon, Mar 03, 2003 at 05:22:06 +1100, Allan Klinbail wrote:
> The reason for using a sidechain (in the hardware world) as opposed to
> plugging everything inline.. is simplification of patching and
> minimising the number of cables being used.
>
> In software there would be no reason other t
On Fri, Feb 28, 2003 at 04:26:23 -0500, Jesse Chappell wrote:
> Mike Rawes wrote on Fri, 28-Feb-2003:
>
> > /* Hint MOMENTARY indicates that that a control should behave like a
> >momentary switch, such as a reset or sync control. LADSPA_HINT_MOMENTARY
> >may only be used in combination
On Fri, Feb 28, 2003 at 04:51:07 +0100, Fons Adriaensen wrote:
> The thread that calls the user's callback function is completely
> hidden, and so it can wait only for the trigger form jackd and nothing
> else. As a consequence you can't use it to communicate safely with your
> callback which would
On Fri, Feb 28, 2003 at 03:49:59 +0100, Fons Adriaensen wrote:
> Is this really new ? I was porting some C++ thread classes (originally
> developed for Solaris) to 2.4.19 this week. The ITC mechanism uses
> pthread_cond_timedwait(), which takes a struct timespec * referring to
> an absolute time, t
On Fri, Feb 28, 2003 at 10:07:18 +, Mike Rawes wrote:
> Think this needs to go to LAD too...
Er, yeah, I didn't realise it wasn't.
> > I think there was one more too, but I can't think what it was...
>
> I remember one about sidechains or something. I don't know what a sidechain is,
> thoug
On Thu, Feb 27, 2003 at 10:58:56 -0500, Ivica Bukvic wrote:
> Hi,
>
> Some of your ideas already reside in other projects, so perhaps consider
> contributing to them rather than starting yet another project. IMHO what
> we really need now in Linux community is a couple of really stable and
> versa
On Thu, Feb 27, 2003 at 07:03:07 -0500, Paul Davis wrote:
> you need to understand that this state of affairs is caused by
> misleading advertising and marketing. firewire cards cost $50 and can
Actually, in europe at least firewire cards are < $20. The abundance of DV
camcorders has pushed the pr
On Thu, Feb 27, 2003 at 07:47:22 +0100, [EMAIL PROTECTED] wrote:
> > If each plugin only ever worries about the current block for I/O, this
> > is not an issue, because plugins would never generate events that
> > they may need to take back later.
>
> hmmm... this would make the event delay more
On Wed, Feb 26, 2003 at 09:48:35 -0500, Dave Phillips wrote:
> Paul Davis wrote:
>
> > if anyone has a Hang drum available, i can tap out some pretty patterns :)
>
> I've been listening to some water drumming by African rainforest
> dwellers. All we need is a sufficiently large tub, enough liqui
On Wed, Feb 26, 2003 at 09:35:46 -0500, Paul Davis wrote:
> if anyone has a Hang drum available, i can tap out some pretty
> patterns :)
>
> oh wait, i'm the engineer, right?
I play a mean powerdrill ;) but have no useful musical skills, maybe I
should do the engineering.
- Steve
On Wed, Feb 26, 2003 at 01:51:41 +0100, Martijn Sipkema wrote:
> Well, I'll shut up about it. I still think it is a mistake. I haven't heard
> any
> convincing (to me) arguments why an application should not handle variable
> sized callbacks.
Because it makes certain types of processing viable, wh
On Wed, Feb 26, 2003 at 12:38:38 +0100, Martijn Sipkema wrote:
> Still there is no guarantee that 10 packets always have exactly the same
> number of samples. You say the mLAN spec says you need a buffer of
> around ~250us. Note that is doesn't say a buffer of a number of frames.
> The bottom line
On Wed, Feb 26, 2003 at 11:17:31 +0100, Martijn Sipkema wrote:
> > > I'm not sure, but it seems the audio transport over FireWire does not
> > > deliver a constant number of frames per packet. Does this mean that
> > > JACK cannot support FireWire audio without extra buffering?
> >
> > ISO packets
On Wed, Feb 26, 2003 at 01:01:45AM +0100, Martijn Sipkema wrote:
> > Some folks here might find this of interest. I do...
> >
> > http://www.cs.ru.ac.za/research/g99s2711/thesis/thesis-final.pdf
>
> I'm not sure, but it seems the audio transport over FireWire does not
> deliver a constant number
On Tue, Feb 25, 2003 at 04:07:33 +0100, Fons Adriaensen wrote:
> BTW, can JACK handle several HW interface using different blocksizes
> at a time (assuming sample frequencies are coherent) ?
Not directly, but I believe that ALSA can. To work it would require that
the cards were in sample sync (is
I hacked up a shell script [attached] to valgrind LADSPA .so files. It
will report leaks, bufferoverruns, reads from unitialised variables and
so on, but it doesn't totally exercise the plugin so it may miss some
things.
Obviously it helps if you rebuild with -g on and it works best with gcc3
(bet
On Mon, Feb 24, 2003 at 07:49:43 +0100, Martijn Sipkema wrote:
> > > [...]
> > > > > Perhaps you would reconsider having JACK use constant (frames)
> > > > > callbacks?
> > > >
> > > > I think a better solution might be to buffer up enough samples so that
> > > > jackd can provide a constant number
On Mon, Feb 24, 2003 at 06:03:58 +0100, Martijn Sipkema wrote:
> [...]
> > > Perhaps you would reconsider having JACK use constant (frames)
> > > callbacks?
> >
> > I think a better solution might be to buffer up enough samples so that
> > jackd can provide a constant number of frames.
>
> I don'
On Mon, Feb 24, 2003 at 04:54:56PM +0100, Martijn Sipkema wrote:
> [...]
> > many USB audio interfaces work in a fundamentally different way than
> > other audio interfaces. rather than sending an "interrupt" to the host
> > after processing 2^N frames, they send an interrupt every N
> > msecs.
>
On Thu, Feb 20, 2003 at 03:26:27 +, Bob Ham wrote:
> On Wed, 2003-02-19 at 16:33, Paul Davis wrote:
> > >* midi thread will now try and use SCHED_FIFO. If you run jackd with
> >
> > why?
>
> Without SCHED_FIFO, the midi thread takes a back seat in the
> processing. This means that control c
On Mon, Feb 17, 2003 at 11:52:56 +1100, Allan Klinbail wrote:
> Not being a coder so you can all shout me down in flames if you like if
> my response is misguided ..
>
> > Thanks, but I really wanted someting with dynamic timing. Does this queue
> > tie me to a particular BPM? All I wanted was to
On Fri, Feb 14, 2003 at 07:59:33 +0100, Takashi Iwai wrote:
> - allocate and set up the queue.
>
> snd_seq_t *seq;
> // allocation of seq handler
> ...
>
> // allocation of queue
> int queue = snd_seq_alloc_queue(seq);
>
> snd_seq_queue_tempo_t *tempo;
>
On Mon, Feb 17, 2003 at 08:34:10 +0100, Roger Larsson wrote:
> Testing that i have done suggest that you should ALWAYS define the
> architecture of your target. (I have not checked if the example does this
> but it is usually forgot...)
>
> -march=pentium3
> or if you need it to run on older comp
On Sun, Feb 16, 2003 at 12:28:57 +1100, Erik de Castro Lopo wrote:
> As a C fan I was rather curious about this. I didn't want people getting the
> wrong impression that C++ is automatically faster than C (it isn't) or that in
> the long term improvements in the C++ compiler will make it faster tha
801 - 900 of 1876 matches
Mail list logo
