Re: [linux-audio-dev] OSS will be back

2006-11-03 Thread Simon Jenkins
On Fri, 2006-11-03 at 08:53 +0100, Fons Adriaensen wrote: [...] I'd say that the essential feature of JACK is not that it is a callback based system, but that it presents and expects audio data in fixed size blocks and enforces the rule that all clients must have processed a block before the

Re: [linux-audio-dev] OSS will be back

2006-11-03 Thread Simon Jenkins
On Fri, 2006-11-03 at 17:50 +0100, Stéphane Letz wrote: Le 3 nov. 06 à 17:39, Simon Jenkins a écrit : On Fri, 2006-11-03 at 08:53 +0100, Fons Adriaensen wrote: [...] I'd say that the essential feature of JACK is not that it is a callback based system, but that it presents and expects

Re: [linux-audio-dev] linear resampling is crap ? (was: fast linear resampling on ARM - suggestions?)

2006-04-01 Thread Simon Jenkins
if there might be a better way to gain or lose the occasional sample. erm... Anyone? Simon Jenkins Bristol, UK

Re: [linux-audio-dev] Fixed vs. floating point

2005-10-14 Thread Simon Jenkins
On Fri, 2005-10-14 at 21:00 +0200, [EMAIL PROTECTED] wrote: [...]If numbers from binary 0.1 to 1.0 are represented using 24 bits (sign bit + mantissa, I think the implicit 1 does not count) You could represent numbers to 1 bit of precision using a zero bit mantissa (ie exponent only) format.

Re: [linux-audio-dev] libcui - design-question

2005-09-23 Thread Simon Jenkins
On Fri, 2005-09-23 at 13:04 +0200, Tim Goetze wrote: [Kjetil Svalastog Matheussen] breathe deeply. think of snakes. say python. Are you serious? Do you know python? I hope not... I don`t want to start a flame-war over programming languages, but I know both scheme and python very well,

Re: [linux-audio-dev] Re: libcui - design-question

2005-09-20 Thread Simon Jenkins
From: Arnold Krille [EMAIL PROTECTED] On 9/20/05, Aaron [EMAIL PROTECTED] wrote: please save me from another lisp/scheme scriptable application /me too The scripting should be in a language easy enough for a non programer to use. Is xsl a possibility or is there a scripting language

Re: [linux-audio-dev] TAP EQ problems

2005-08-04 Thread Simon Jenkins
.html ~ Simon Jenkins

Re: [linux-audio-dev] FM, Phase Modulation and The Wiki

2005-06-29 Thread Simon Jenkins
On Wed, 2005-06-29 at 00:47 +0200, Jens M Andreasen wrote: On Tue, 2005-06-28 at 21:13 +0100, Simon Jenkins wrote: It seems the difference is that PD works on individual cycles of the modulated waveform. The wiki author guesses that there may be an extra synching oscillator but in fact

Re: [linux-audio-dev] FM, Phase Modulation and The Wiki

2005-06-28 Thread Simon Jenkins
On Tue, 2005-06-28 at 15:18 +0200, Jens M Andreasen wrote: On Tue, 2005-06-28 at 14:14 +0200, Jens M Andreasen wrote: I am currently looking [in wikipedia] at the Casio section near the end (regarding phase distortion.) Wasn't this technique developed way back in the 60's by french

Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many

2005-06-08 Thread Simon Jenkins
On Tue, 2005-06-07 at 19:34 -0500, Jan Depner wrote: On Tue, 2005-06-07 at 19:20, Dave Robillard wrote: Premature optimization is the root of all evil. Using C arrays and strings for no reason when a much more robust higher level type would suffice is /just as stupid/ as always using slow

Fw: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many

2005-06-08 Thread Simon Jenkins
As far as data volumes go, for your 5 million integers, you're off by about 5 orders of magnitude ;-) So, now that 5ms just became 500 seconds. Yes, my users do notice and appreciate that time savings ;-) Jan Sooo. if you stored this stuff on punched paper tape it would be long enough to

Re: [linux-audio-dev] LADSPA Issues

2005-05-20 Thread Simon Jenkins
into a single tree of all the locally known IDs. -- Simon Jenkins

Re: [linux-audio-dev] Re: Nord Modular instrument converter

2005-04-30 Thread Simon Jenkins
On Fri, 2005-04-29 at 16:30 +0300, Juhana Sadeharju wrote: From: Simon Jenkins [EMAIL PROTECTED] 2. Is C++ OK? (You'd end up with a Patch class that could be over-ridden to dump itself in whatever format was required). C++ is ok, and would make sense because the nmedit code is C

Re: [linux-audio-dev] Re: Nord Modular instrument converter

2005-04-29 Thread Simon Jenkins
snip Tasks we have: (1) To write the NM file parser which only maps the patch data to a C data structures. E.g., module[4].name module[4].col module[4].row module[4].p[2] module[4].im[1] module[4].ih[1] module[4].ic[1] That could be simpler than expected. NMEdit already

Re: Behringer [was Re: [linux-audio-user] Re: [linux-audio-dev] RME is no more]

2004-11-28 Thread Simon Jenkins
Marek Peteraj wrote: Oh BTW, just in case :) http://www.petitiononline.com/atipet/petition.html Free as in Nelson Mandela :) ~ Simon

Re: [linux-audio-dev] Open firewire audio interface: A back-of-an-envelope prototype plan

2004-11-28 Thread Simon Jenkins
Marcus Andersson wrote: Hi, what you need to figure out is how hardware can be developed by people living in different countries, the same way email/sourceforge/CVS pretty much solved the distribution problem for software. Here is just a couple of ideas. All interested developers buy a

Re: [linux-audio-dev] Re: [linux-audio-user] RME is no more

2004-11-27 Thread Simon Jenkins
Lee Revell wrote: On Thu, 2004-11-25 at 02:14 +0100, Marek Peteraj wrote: The official statement is that there will be no support for ALSA (Linux) FireWire drivers from RME. In other words there will be no such drivers, as it is impossible to write them without tons of hardware and software

Re: [linux-audio-dev] Open firewire audio interface: A back-of-an-envelope prototype plan

2004-11-26 Thread Simon Jenkins
Bob Knight wrote: I want an open ethernet audio device. I do not want or need to deal with pci, firewire, usb. Fair enough, and an interesting project, though personally I'm more interested in doing a firewire device. Use one of many controllers out there with a good embedded linux port and build

[linux-audio-dev] Open firewire audio interface: A back-of-an-envelope prototype plan

2004-11-25 Thread Simon Jenkins
Hi all: I've been thinking some more about a prototyping/development board (not a production board) for a free open multi-channel firewire audio interface. The objective would be to keep initial development time and costs down even at the expense of pushing component costs slightly up. Here are my

Re: [linux-audio-dev] Re: [Alsa-devel] Firewire Audio Card Support

2004-11-19 Thread Simon Jenkins
quality, number and types of inputs, packaging and price etc. Simon Jenkins

Re: [linux-audio-dev] Re: [Alsa-devel] Firewire Audio Card Support

2004-11-19 Thread Simon Jenkins
software projects. It's a different thing is someone is willing to sponsor such a project. Another option would be to find someone who'd pay us *not* to do it :) Simon Jenkins

Re: [linux-audio-dev] Re: [Alsa-devel] Firewire Audio Card Support

2004-11-19 Thread Simon Jenkins
Jussi Laako wrote: On Fri, 2004-11-19 at 21:03 +, Simon Jenkins wrote: Pessimistic. I had to specify a single 6-layer board, 5 days delivery and 100 component placements before I got an online quote approaching 500Euro. And the price drops *fast* when you want a few more boards, a bit

Re: [linux-audio-user] Re: [linux-audio-dev] Re: [Alsa-devel] Firewire Audio Card Support

2004-11-19 Thread Simon Jenkins
much do you need to make on each unit to be worthwhile? There's no law against providing windows mac drivers for it too. Simon Jenkins

Re: [linux-audio-dev] Re: [Alsa-devel] Firewire Audio Card Support

2004-11-19 Thread Simon Jenkins
Lee Revell wrote: On Sat, 2004-11-20 at 00:19 +, Simon Jenkins wrote: You were talking about a slightly more difficult and expensive thing than I was. I was thinking about: 1. A DSP implementation, not FPGA 2. A firewire interface, not PCI 3. Creating a reference implementation

Re: [linux-audio-dev] futex vs lock-free

2004-09-04 Thread Simon Jenkins
Orlarey LAD post you mentioned, and also to much information. One of the implementations - lock-free-lib - is reported to be GPL'd and to cover Alpha, Mips, ia64, x86, PPC and Sparc. Simon Jenkins (Bristol, UK)

Re: [linux-audio-dev] futex vs lock-free

2004-08-28 Thread Simon Jenkins
Simon Jenkins wrote: During collisions there is a busy retry loop, but 1) everything else trying to access the protected structure during the collision is also in a busy retry loop and 2) any of them can succeed, at any time, by making it once through the loop without something else hitting

Re: [linux-audio-dev] futex vs lock-free

2004-08-26 Thread Simon Jenkins
with standard m(/f)utexes, and are intended for real-time use. Simon Jenkins (Bristol, UK)

Re: [linux-audio-dev] futex vs lock-free

2004-08-26 Thread Simon Jenkins
you certainly /want/ to run) then only a continual barage of *new* collisions can starve you of access to the structure. Simon Jenkins (Bristol, UK)

Re: [linux-audio-dev] Re: [off-list] Read this after your first cup of coffee

2004-08-24 Thread Simon Jenkins
be achieved, anyway) to keep track of where (/when) they all are. The GUI provides this convenience... IF you can use it. But if you can't? The capabilities are still there! You just need to find a different way of getting at them. (OK, that's a big just). Simon Jenkins (Bristol, UK) ... Boggs believes

Re: [linux-audio-dev] sonar tracking question

2004-07-17 Thread Simon Jenkins
window to detect the location of finger taps on the surface of the window. Some of it might be relevant. Also... hmmm. Could also be relevant to a cheap DIY drum pad. Simon Jenkins (Bristol, UK)

Re: [linux-audio-dev] swh plugins and fixing undenormalize

2004-06-27 Thread Simon Jenkins
Tim Goetze wrote: [Tim Blechmann] On Fri, 25 Jun 2004 17:38:24 -0500 Jan Depner [EMAIL PROTECTED] wrote: On Fri, 2004-06-25 at 13:49, Tim Blechmann wrote: I have a denormal fix without a branch but you probably don't want to see it ;-) It's pretty simple, just OR the bits of the

Re: [linux-audio-dev] swh plugins and fixing undenormalize

2004-06-27 Thread Simon Jenkins
Tim Goetze wrote: [Simon Jenkins] Tim Goetze wrote: 8-bit exponent and no assumption about its value made, 8 binary 'shift', 7 'or' and 1 'and' statement if i'm not badly mistaken. and if i'm not, a branch will probably hurt less. Three shifts, three copys, three 'or's

Re: [linux-audio-dev] swh plugins and fixing undenormalize

2004-06-24 Thread Simon Jenkins
blunt because it damages the precision of extremely low but not yet denormal numbers: Anything of magnitude 2 ** -103 loses one bit of precision for each binary order of magnitude it is below that number. (This means that denormal numbers lose /all/ of their precision and become zero). Simon Jenkins

Re: [linux-audio-dev] swh plugins and fixing undenormalize

2004-06-24 Thread Simon Jenkins
is because casting macro arguments to volatile wasn't having the desired effect on the optimiser, whereas this does. Simon Jenkins (Bristol, UK)

Re: [linux-audio-dev] [OT] Linux, audio and the breach of GPL

2004-04-11 Thread Simon Jenkins
_some_ means not _any_: could you specify those entitled and those not? What, *again*? OK then. If you distribute an executeable and provide a written offer of source (section 3b) then your distributees may pass along the written offer to third parties (section 3c). Simon Jenkins

Re: [linux-audio-dev] [OT] Linux, audio and the breach of GPL

2004-04-10 Thread Simon Jenkins
code, valid for three years. (If you also make the source available by FTP then maybe nobody will ever order a physical copy). But also (important): 3. A copy of the GPL licence itself must accompany the executeable! Simon Jenkins

Re: [linux-audio-dev] [OT] Linux, audio and the breach of GPL

2004-04-10 Thread Simon Jenkins
versions even EXIST. But if (and only if) you distribute an executeable, then you are obligated to make source available to those who you distribute it to, and to third parties as described above. Simon Jenkins

Re: [linux-audio-dev] [OT] Linux, audio and the breach of GPL

2004-04-10 Thread Simon Jenkins
target processor (a courtroom)? /That's/ what you'd need a lawyer to tell you. Simon Jenkins

Re: [linux-audio-dev] [OT] Linux, audio and the breach of GPL

2004-04-10 Thread Simon Jenkins
Marek Peteraj wrote: On Sat, 2004-04-10 at 19:42, Simon Jenkins wrote: [EMAIL PROTECTED] wrote: IANAL, but I'm 99% sure that when you give someone a GPLd executable, you're only obligated to provide that one person with the sources, not the general public (read: everyone on earth

Re: [linux-audio-dev] [OT] Linux, audio and the breach of GPL

2004-04-10 Thread Simon Jenkins
Marek Peteraj wrote: On Sat, 2004-04-10 at 21:01, Simon Jenkins wrote: Marek Peteraj wrote: On Sat, 2004-04-10 at 19:42, Simon Jenkins wrote: [EMAIL PROTECTED] wrote: IANAL, but I'm 99% sure that when you give someone a GPLd executable, you're only obligated to provide that one person

Re: [linux-audio-dev] [OT] Linux, audio and the breach of GPL

2004-04-09 Thread Simon Jenkins
Jan Depner wrote: I agree completely. The relevant quote from the GPL FAQ is this: You're supposed to provide the source code by mail-order on a physical medium, if someone orders it. You are welcome to offer people a way to copy the corresponding source code by FTP, in addition to the

Re: [linux-audio-dev] [i686] xmm regs + gcc inline assembly

2004-02-13 Thread Simon Jenkins
Tim Goetze wrote: Simon Jenkins wrote: I can definitely get asm (movaps %%xmm1 %0 : =m (t[0])); to exhibit the optimisation problem (the one I couldn't get your original line to show) and then fix it again by removing the [0]. [snip] ok, here is a distilled test of how i allocate and use

Re: [linux-audio-dev] [i686] xmm regs + gcc inline assembly

2004-02-13 Thread Simon Jenkins
Simon Jenkins wrote: [...] printf (z is %.2f\n, z ); } /* end */ [...] No I didn't. Something's eaten a couple of linefeeds here. (other than that it still looks ok). ~S

Re: [linux-audio-dev] [i686] xmm regs + gcc inline assembly

2004-02-12 Thread Simon Jenkins
the compiler that the entire array t is in memory to which the instruction writes. This *ought* to discourage the optimiser from doing anything too drastic. (Maybe/AFAIK/IANAL/etc). Simon Jenkins (Bristol, UK)

Re: [linux-audio-dev] [i686] xmm regs + gcc inline assembly

2004-02-12 Thread Simon Jenkins
Tim Goetze wrote: Simon Jenkins wrote: for a simplified example, i'm using float t[4]; ... asm (movaps %%xmm1, %0 : : m (t[0])); to move 4 packed floats from xmm1 into 't'. I couldn't get this to fail in practice - though I didn't try all that hard - unless t isn't on a 16 byte boundary

[linux-audio-dev] branch-free denormal killer

2004-02-01 Thread Simon Jenkins
leaves anything higher than 9.8607615E-32 (ie 2 ** -103) completely unchanged. Numbers below this value lose one bit of precision for each binary order of magnitude they are below it. This has the effect that denormal numbers lose *all* their precision, ie they become zero. Simon Jenkins (Bristol, UK)

Re: [linux-audio-dev] Project: modular synth editor

2004-01-20 Thread Simon Jenkins
Steve Harris wrote: On Tue, Jan 20, 2004 at 01:55:54 +, Simon Jenkins wrote: This will 'work', AFAICS, but with one cycle delay. One or two cycles, depending on whether the client containing A and B guesses correctly that A comes before B in the overall graph. (It doesn't know

Re: [linux-audio-dev] Project: modular synth editor

2004-01-19 Thread Simon Jenkins
+---+ Oh dear... C needs to be called between A and B, but even if JACK and the two clients know that A-C-B is the correct order (which none of them do) it can't be achieved because A and B must be processed in a single callback. Simon Jenkins (Bristol, UK)

Re: [linux-audio-dev] Project: modular synth editor

2004-01-19 Thread Simon Jenkins
Whoops: Those ascii diagrams again: +---+ | +---+ | JACK -|- A -|---+ | | | +--|- B -|-- JACK +---+ +---+ | | +---|- C -|--+ | | | | | +---+ | |

Re: [linux-audio-dev] Project: modular synth editor

2004-01-19 Thread Simon Jenkins
Fons Adriaensen wrote: On Mon, Jan 19, 2004 at 08:56:52PM +, Simon Jenkins wrote: Worse: JACK - A - JACK - C - JACK - B - JACK Where C is in a separate client. Now... +---+ | | +---|- C

Re: [linux-audio-dev] Project: modular synth editor

2004-01-19 Thread Simon Jenkins
a good idea :) Even making the front half and back half of the mixer into separate clients can be defeated by a sufficiently pathological user. (Eg by chaining all the input sections together in the wrong order). Simon Jenkins (Bristol, UK)

Re: [linux-audio-dev] Denormal numbers

2003-08-04 Thread Simon Jenkins
*/ /*..*/ /* flush results to zero or - depending what the math was - take some other appropriate action */ /*..*/ } Simon Jenkins (Bristol, UK)

Re: [linux-audio-dev] Denormal numbers

2003-08-03 Thread Simon Jenkins
Simon Jenkins wrote: [...]If it still doesn't work after they are applied then you could try -ffloat-store. The compiler manual says that programs which rely on the exact storage format of IEEE floats should use this option, but I am unable to break the macro in a way that this fixes

Re: [linux-audio-dev] Denormal numbers

2003-08-03 Thread Simon Jenkins
Steve Harris wrote: 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. Its only an extra branch on the MULs where you actually use

Re: [linux-audio-dev] Denormal numbers

2003-08-02 Thread Simon Jenkins
Steve Harris wrote: 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

Re: [linux-audio-dev] Denormal numbers

2003-08-01 Thread Simon Jenkins
place. 6. Performance I'd classify this as quite fast but not very fast. This is in some ways a good thing: Its probably cheap enough to be carefully deployed in exactly the places where its needed, but not so cheap that it can be sprinkled around all over the place where it isn't. Simon Jenkins

Re: [linux-audio-dev] Denormal numbers

2003-08-01 Thread Simon Jenkins
Simon Jenkins wrote: If you're doing this sort of thing you need to fix it with a couple more brackets... #define FLUSH_TO_ZERO(fv) *(unsigned int*)(fv))0x7f80)==0)?0.0f:(fv)) ...and then, as far as I can see, the macro always does exactly what it is supposed to do. Whoops... I spoke

Re: [linux-audio-dev] XAP again - channels, etc.

2003-03-21 Thread Simon Jenkins
events, OTOH, has an event switch input. ~ Finally, define some default conversion plugins which can cast between various events and signals, allowing most things to be connected to most others. Simon Jenkins (Bristol, UK)

Re: [linux-audio-dev] Modular synths of the world, unite and takeover :-)

2003-03-18 Thread Simon Jenkins
for a dsp, modular synth developers would want to make different decisions from each other regarding some of the above points. Simon Jenkins (Bristol, UK)

Re: [linux-audio-dev] XAP spec - early scribbles

2003-03-06 Thread Simon Jenkins
[EMAIL PROTECTED] wrote: On Mon, Mar 03, 2003 at 08:36:04PM +, Simon Jenkins wrote: I'm trying to think about the most general model, at least at this stage. It might become unmanageably complex and need to be stripped back. OTOH its possible that a whole lot of complexity could suddenly

Re: [linux-audio-dev] XAP spec - early scribbles

2003-03-06 Thread Simon Jenkins
() manages to avoid recursion by using an intermediate list. Note: I've tried to give this a half decent test, and it does seem to work every time, but your original code has executed successfully about a zillion times more than this code has... Simon Jenkins (Bristol, UK)

Re: [linux-audio-dev] XAP spec - early scribbles

2003-03-03 Thread Simon Jenkins
[EMAIL PROTECTED] wrote: On Sun, Mar 02, 2003 at 09:06:02PM +, Simon Jenkins wrote: [EMAIL PROTECTED] wrote: ok ... now to the API... Here's my thinking so far, modulo some of your comments (I'll need to think a bit more about some other of your comments, eg what you need

Re: [linux-audio-dev] XAP spec - early scribbles

2003-03-02 Thread Simon Jenkins
. (Problem with this is that the implementation needs inheritance which would have to be hand rolled in C, were it to be exposed to the application.) == Copyright (c) Simon Jenkins 2003 licence

Re: [linux-audio-dev] XAP spec - early scribbles

2003-03-02 Thread Simon Jenkins
Dave Griffiths wrote: On Sat, 01 Mar 2003 03:03:37 + Simon Jenkins [EMAIL PROTECTED] wrote: I just took a look at the SSM GraphSort code (from 0.2.1rc2). Its a neat encapsulation but the sort algorithm seems to mess up on an important case: Nicely spotted, I hadn't noticed that one

Re: [linux-audio-dev] XAP spec - early scribbles

2003-03-01 Thread Simon Jenkins
David Olofson wrote: On Saturday 01 March 2003 04.03, Simon Jenkins wrote: [...all good points...] That's easily solved... but here's a problem that's not: A general solution to the graph sorting problem would have to know about the I/O dependencies *inside* the nodes. This isn't usually

Re: [linux-audio-dev] XAP spec - early scribbles

2003-03-01 Thread Simon Jenkins
[EMAIL PROTECTED] wrote: On Sat, Mar 01, 2003 at 03:03:37AM +, Simon Jenkins wrote: A general solution to the graph sorting problem would have to know about the I/O dependencies *inside* the nodes. This isn't usually a problem on the scale where a node represents, for example, a simple

Re: [linux-audio-dev] XAP spec - early scribbles

2003-03-01 Thread Simon Jenkins
but which amble doesn't, making sure it actually is correct, and releasing it as an LGPL library. Simon Jenkins (Bristol, UK)

Re: [linux-audio-dev] XAP spec - early scribbles

2003-03-01 Thread Simon Jenkins
probably wouldn't bother to sort the graph: it could rapidly calculate the execution order at runtime, executing each node as its data became available. OTOH I agree that there's an inconsistency at the implementation level, if thats what you're concerned about. Simon Jenkins (Bristol, UK)

Re: [linux-audio-dev] XAP spec - early scribbles

2003-03-01 Thread Simon Jenkins
David Olofson wrote: On Saturday 01 March 2003 17.12, Simon Jenkins wrote: [...] then these components must be built of other components... i dont see a reason why one wants a big complex component if it could be built from smaller components... (other than performace) Absolutely

Re: [linux-audio-dev] XAP spec - early scribbles

2003-03-01 Thread Simon Jenkins
to use STL on the inside, its just exposing it on the outside that I'm worried about). Simon Jenkins (Bristol, UK)

Re: [linux-audio-dev] XAP spec - early scribbles

2003-02-28 Thread Simon Jenkins
reasonable graphs: Different parts of their internals need to be executed at different times! Simon Jenkins (Bristol, UK)

[linux-audio-dev] amble (was: blockless processing)

2003-02-22 Thread Simon Jenkins
like this sort of thing: http://www.sbibble.pwp.blueyonder.co.uk/amble/amble-0.1.1.tar.gz Some (not all) of the demos require libsndfile and its headers. Simon Jenkins (Bristol, UK)

Re: [linux-audio-dev] can somebody tell me how to create a .wav filefrom the sound buffer or gsm?

2003-02-20 Thread Simon Jenkins
leo zhu wrote: I have already got the sound data from sound card into the buffer, and I've also finished it to encode the data to gsm and send to another server. Right now I need to store the sound data to some .wav file in the server. How can I do it, ether from memory buffer or gsm? Are there

Re: denormal floats (was Re: [linux-audio-dev] XAP spec - early scribbles)

2003-02-06 Thread Simon Jenkins
. (IMHO:) Denormals need to be detected and killed in the feedback paths that generate them. These paths are inside the plugins, not between them, so its something the plugin author has got to get right, not something the API/host can effectively deal with. Simon Jenkins (Bristol, UK)

Re: denormal floats (was Re: [linux-audio-dev] XAP spec - early scribbles)

2003-02-06 Thread Simon Jenkins
zapper. Simon Jenkins (Bristol UK)

Re: [linux-audio-dev] Blockless processing

2002-12-16 Thread Simon Jenkins
*hehe* I offer to shut up and code unless somebody pokes me with a sharp stick or something and the next thing that happens is: On Sun, Dec 15, 2002 at 07:47:07PM +, Simon Jenkins wrote: It sounds like you'd be better off working form the Sfront SAOL code. Well, I'm working from

Re: [linux-audio-dev] Blockless processing

2002-12-15 Thread Simon Jenkins
, but still a lot less than useable release code. I'll post it up somewhere when its done. Meanwhile I'd better shut up about the whole thing (unless somebody pokes me with a sharp stick or something). Simon Jenkins (Bristol, UK)

Re: [linux-audio-dev] Blockless processing

2002-12-15 Thread Simon Jenkins
Steve Harris wrote: On Sun, Dec 15, 2002 at 05:43:01PM +, Simon Jenkins wrote: Steve Harris wrote: Damn... dont encourage me. I'm gonna end up implemnting this thing for real if I'm not careful and I allready have a dozen other things that are more important. I'm currently

Re: [linux-audio-dev] Blockless processing

2002-12-13 Thread Simon Jenkins
on how the *entire* graph to be processed fitted into the *actual* available cache. Simon Jenkins (Bristol, UK)

Re: [linux-audio-dev] Blockless processing

2002-12-12 Thread Simon Jenkins
the existing modules reset themselves and everything starts again with the new module, suggesting that the existing modules have all lost their contexts. This is *really* annoying if you're trying to develop a patch or sequence that evolves very slowly. Simon Jenkins (Bristol, UK)

Re: [linux-audio-dev] Plugin APIs (again)

2002-12-10 Thread Simon Jenkins
processing they can have it. + plugins can be compiled for and run on a dedicated DSP board given an appropriate compiler. + plugins are unavoidably open source. Simon Jenkins (Bristol, UK)

Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] helpfor a levelmeter]

2002-11-12 Thread Simon Jenkins
Len Moskowitz wrote: Simon Jenkins [EMAIL PROTECTED] wrote: But where would they have been now if they had taken the fully open route? Somewhere better? Somewhere worse? Where could a hypothetical competitor who started now, from scratch, with a fully open model get to? Would they catch up

Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] helpfor a levelmeter]

2002-11-10 Thread Simon Jenkins
, with a fully open model get to? Would they catch up and overtake? Would they fail to catch up? Would they win or lose against chameleon in its own niche? Or would they carve out a new niche, next-door to the chameleon but not quite competing with it? I don't know the answers to these questions. Simon

Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] helpfor a levelmeter]

2002-11-09 Thread Simon Jenkins
Steve Harris wrote: On Sat, Nov 09, 2002 at 07:15:02AM +, Simon Jenkins wrote: Audio-related examples might include things like: Making a multi effects rack unit with pro-audio i/o, a heap of DSP power, front panel display and controls, and filling it with the pick of the available open

Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] helpfor a levelmeter]

2002-11-09 Thread Simon Jenkins
hardware. Simon Jenkins (Bristol, UK)

Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] helpfor a levelmeter]

2002-11-08 Thread Simon Jenkins
should be able to make a lot of money selling a box like that. Simon Jenkins (Bristol, UK)