Re: [linux-audio-dev] Disksampler, AES preprints + CMJ papers needed
On Thursday 07 August 2003 21:12, Juhana Sadeharju wrote: > for open source software developers. Anyone in Finland has CMJ > issues starting from the early issues? I could come and check them > through. HY:n musiikkitieteen kirjastoon (Vironkatu 1) tulee cmj. On tullut aika pitkään afaik. Jotain aes-juttuja tulee kai myös. Tkk:lle tulee varmaan aes-hässäkät ainakin. -- Jaakko Prättälä [EMAIL PROTECTED]
[linux-audio-dev] KIND ATTENTION
From: Mrs Magret Hatch PLEASE ENDEAVOUR TO USE IT FOR THE CHILDREN OF GOD. I am the above named person from Kuwait. I am married to Mr. Kazeem Hatch who worked with Kuwait embassy in Ivory Coast for nine years before he died in the year 2001. We were married for eleven years without a child. He died after a brief illness that lasted for only four days. Before his death we were both born again Christians.When my late husband was alive he deposited the sum of$10.5Million (ten Million fivehundred thousand U.S. Dollars) with one Pinnacle Finance/Security Company in Spain. Presently, this money is still with the Security Company. Recently, my Doctor told me that I would not last for the next three months due to cancer problem. Though what disturbs me most is my stroke. Having known my condition I decided to donate this fund to church or better still a christian individual that will utilize this money the way I am going to instruct here in. I want a church that will use this fund to fund churches, orphanages,Research centers and widows propagating the word of God and to ensure that the house of God is maintained. The Bible made us to understand that Blessed is the hand that giveth. I took this decision because I dont have any child that will inherit this money and my husband relatives are not Christians and I dont want my husbands hard earned money to be misused by unbelievers. I dont want a situation where this money will be used in an ungodly manner. Hence the reason for taking this bold decision. I am not afraid of death hence I know where I am going. I know that I am going to be in the bossom of the Lord. Exodus 14 VS 14 says that the lord will fight my case and I shall hold my peace. I dont need any telephone communication in this regard because of my health because of the presence of my husbands relatives around me always. I dont want them to know about this development. With God all things are possible. As soon as I receive your reply I shall give you the contact of the Pinnacle Finance/Security Company in spain . I will also issue you a letter of authority that will empower you as the new beneficiary of this fund. I want you and the church to always pray for me because the lord is my shephard. My happiness is that I lived a life of a worthy Christian. Whoever that wants to serve the Lord must serve him in spirit and truth. Please always be prayerful all through your life. Any delay in your reply will give me room in sourcing for a church or christian individual for this same purpose. Please assure me that you will act accordingly as I stated herein. Hoping to hear from you. Remain blessed in the name of the Lord. Yours in christ, Mrs Magreth Hatch.
[linux-audio-dev] Dont let your loans kill you! fjfdsioa,
Hi, Loans are a very quick way to get behind. We can help! We can consolidate your bills into just one low monthly payment. Start Fresh! - Save you a lot of money by eliminating late fees - Settle your accounts for a substantially reduced amount - Stop creditors calling you on the phone - Avoid bankruptcy ... and more! Why keep dealing with the stress, and headaches? Combine your debt into a low interest repayment and get on with your life today!! Come here and take a look at how we can help. http://btrack.iwon.com/r.pl?redir=http://[EMAIL PROTECTED]/index.php?N=g not interested? http://btrack.iwon.com/r.pl?redir=http://[EMAIL PROTECTED]/r.php
Re: [linux-audio-dev] gQ for Linux
Hi, Could it be more useful to have this ported to LADSPA? I am not familiar with the application nor the LADSPA API so please excuse me if this is a stupid idea. I sure would like a nice EQ plugin with a nice GUI. Regards On Wed, 2003-08-13 at 02:25, Erik de Castro Lopo wrote: > On Tue, 12 Aug 2003 18:18:13 -0700 (PDT) > kevin ernste <[EMAIL PROTECTED]> wrote: > > > And the source can be found here: > > > > http://music.princeton.edu/~dan/programs.html > > > > Note that Dan's open source lisencing terms can be found in the src > > tarball's README. > > Sorry Kevin, but I can't find anything in the tarball that looks anything > like a proper license. > > Erik -- antoine rivoire <[EMAIL PROTECTED]>
Re: [linux-audio-dev] sc synth definition file format?
Hallo, ist der plan immer noch aktuell Q mit SuperCollider zu verbinden? Bin zufällig beim Mail aufräumen auf diese etwas ältere Email gestossen. Oliver Albert Graef wrote: Hi, I'm currently embarking on a project to make an interface between Q, a functional programming language (http://www.musikwissenschaft.uni-mainz.de/~ag/q/), and SuperCollider. I think the OSC interface will be fairly straightforward to do, but I haven't been able to find any documentation (besides the sc sources, which I haven't grokked yet ;-) on the format of the synth definition file. Does anyone here know more about this? Many thanks in advance, Albert
Re: [linux-audio-dev] Should the list be members-only?
On Thursday 14 August 2003 17:12, Paul Winkler wrote: > Hi folks, your friendly temporary list-admin here. > (Joern's on vacation and I'm filling in.) > > We seem to be getting quite a lot of spam lately. > Currently the list is "open" - non-members can post. > > I'd like to take an informal poll: > > Should the LAD list remain totally open, or should non-member postings require moderator approval > > I should point out that the LAU list requires approval > for non-member postings, and it seems to be no problem > in my very-limited experience managing the lists: > I check the pending-approval queue at least once a day, find > nothing but spam, and throw it away. Approving a legit non-member > posting would be trivially easy.
[linux-audio-dev] why are you waiting
VIRUS ALERT - YOU MAY BE INFECTED WITHOUT EVEN KNOWING IT Most users dont realize they have a virus, and find out after its too late. Norton Antivirus is a complete package that offers you TOTAL protection! btw, you look great today. Total PC Protection RIGHT NOW. http://[EMAIL PROTECTED]/default.asp?id=3000 ps. dont want any more of this shit? http://[EMAIL PROTECTED]/remove/remove.html
Re: [linux-audio-dev] exploring LADSPA
On Thursday 14 August 2003 01:00 am, Brad Arant wrote: > LADSPA is interesting but > I do not see where it handles some of the issues of polyphonic voicing > and assignment control. I'm presently dealing with polyphony at the Python level (Python bindings for my LADSPA-like system). > Do not be discouraged by those that tell you that we already did it and > why don't you use that. They are missing the point, aren't they! 8^) I think so. I could buy all my carrots at the local supermarket, but then I wouldn't have the gratification of raising them myself. Also, there's always the possibility of digging up something new and interesting in even the most heavily trampled places. - Pete
Re: [linux-audio-dev] Should the list be members-only?
Paul Winkler wrote: I'd like to take an informal poll: Should the LAD list remain totally open, or should non-member postings require moderator approval? yes axel
Re: [linux-audio-dev] exploring LADSPA
On Wed, Aug 13, 2003 at 10:47:48 -0700, Tim Hockin wrote: > It's like designing a new windowing system. You MIGHT do better, but lots > of really smart people have done worse. I'd actively beg that anyone who > has a lot of thoughts on this PLEASE catch up on GMPI and join in the fray. > The XAP ideas have actually been pretty well received so far, and the LAD > community is doing a lot to stop the Mac and Windows people from screwing > this up yet again (Paul, Steve - my thanks!). 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. - Steve
[linux-audio-dev] Linux 2.6 not a latency panacea?
I am distressed. It was my understanding that the 2.5/2.6 kernel branch was undergoing significant scheduler and latency work, and that 2.6 would eliminate the kernel from the list of obstacles of low-latency on Linux. It will have the preemptable kernel patch, the new scheduler, and all of Ingo Molnar's low-latency work. Claims were being thrown around that 2.6 would be the lowest-latency operating system on the planet. So how is it that we're in the 2.6.0-test series and people are complaining about audio skipping in **XMMS**, which uses three second buffers by default?? If people are getting skips from high-latency playback, what hope is there for low-latency audio? A series of patches are coming from both Ingo and Con Kolivas attempting to address this, but the fact they are just now throwing around potential solutions erodes at my faith that they really understand the problem or how to solve it. Is 2.6.x going to be suitable for low-latency (or even reliable high-latency) audio? Or is it going to be more of the same: patching the kernel, tweaking parameters, reading magical incantations, and hoping for the best? Reassure me please! Josh
Re: [linux-audio-dev] Linux 2.6 not a latency panacea?
At Thu, 14 Aug 2003 02:48:40 +0200, Christian Henz wrote: > > On Wed, Aug 13, 2003 at 03:09:10PM -0700, Joshua Haberman wrote: > > I am distressed. It was my understanding that the 2.5/2.6 kernel branch > > was undergoing significant scheduler and latency work, and that 2.6 > > would eliminate the kernel from the list of obstacles of low-latency on > > Linux. It will have the preemptable kernel patch, the new scheduler, > > and all of Ingo Molnar's low-latency work. Claims were being thrown > > around that 2.6 would be the lowest-latency operating system on the planet. > > > > So how is it that we're in the 2.6.0-test series and people are > > complaining about audio skipping in **XMMS**, which uses three second > > buffers by default?? If people are getting skips from high-latency > > playback, what hope is there for low-latency audio? A series of patches > > are coming from both Ingo and Con Kolivas attempting to address this, > > but the fact they are just now throwing around potential solutions > > erodes at my faith that they really understand the problem or how to > > solve it. > > > > Is 2.6.x going to be suitable for low-latency (or even reliable > > high-latency) audio? Or is it going to be more of the same: patching > > the kernel, tweaking parameters, reading magical incantations, and > > hoping for the best? > > > > Reassure me please! > > > > Josh > > > > I also found 2.6.0-test[123] to be less responsive than 2.4.x-ll, or even stock > 2.4.x. I've also experienced XMMS dropouts under load (for example compiling Muse) > > Some behaviour I've noticed is that under heavy load the desktop/audio doesn't > freeze for a certain block of time, but rather in short (~2 seconds) intervalls... this should have been imporved significantly in -mm tree. even reducing the min/max timeslices would help a lot. the default values look too large for desktop users... Takashi
Re: [linux-audio-dev] Problems with sb-live wave-tables and midi
paul wisehart wrote: > I have this error that I don't know how to fix. > I was using Craig Stuart Sapp's Midiio library to control > the Emu10k1 wave-table synth. It *was* working until I reinstalled > my linux system. I have put evrything back the way it was, and > now I get these errors when I use the Midiio library: > > -- > > ALSA lib rawmidi_hw.c:227:(snd_rawmidi_hw_open) open /dev/snd/midiC0D3 failed: No > such device > ALSA lib rawmidi_hw.c:227:(snd_rawmidi_hw_open) open /dev/snd/midiC0D4 failed: No > such device > ALSA lib rawmidi_hw.c:227:(snd_rawmidi_hw_open) open /dev/snd/midiC0D5 failed: No > such device > ALSA lib rawmidi_hw.c:227:(snd_rawmidi_hw_open) open /dev/snd/midiC0D6 failed: No > such device > ALSA lib rawmidi_hw.c:227:(snd_rawmidi_hw_open) open /dev/snd/midiC0D7 failed: No > such device Hi Paul: A few questions first: Did you run './snddevices' after installing the driver ? It shouldn't be necessary anymore, but in case of problems run it anyway. What kind of code are you using with Craig's library ? An example would help me understand what you want to do. Do you have a MIDI patch bay such as kaconnect or the ALSA MIDI patch bay ? If so you can look at a graphic representation of your card's MIDI ports. > Whats the correlation between the /dev/snd/midi* devices and > the alsa/Emu10k1 wavetable ports? See below... > //--- > > <[EMAIL PROTECTED]/sound_prg/midio> aconnect -o > client 64: 'Rawmidi 0 - EMU10K1 MPU-401 (UART)' [type=kernel] > 0 'EMU10K1 MPU-401 (UART)' > client 65: 'Emu10k1 WaveTable' [type=kernel] > 0 'Emu10k1 Port 0 ' > 1 'Emu10k1 Port 1 ' > 2 'Emu10k1 Port 2 ' > 3 'Emu10k1 Port 3 ' > > //--- > > <[EMAIL PROTECTED]/sound_prg/midio> pmidi -l > Port Client name Port name > 64:0 Rawmidi 0 - EMU10K1 MPU-401 (UEMU10K1 MPU-401 (UART) > 65:0 Emu10k1 WaveTable Emu10k1 Port 0 > 65:1 Emu10k1 WaveTable Emu10k1 Port 1 > 65:2 Emu10k1 WaveTable Emu10k1 Port 2 > 65:3 Emu10k1 WaveTable Emu10k1 Port 3 This command will connect the input device at your hardware MIDI port to the EMU10k1 synth: aconnect 64:0 65:0 Try to see if it works on your system, then let me know. Your question is really better suited for the Linux audio users group, but feel free to email me directly. I also have the SBLive and can hopefully help you through the trouble. Best regards, == Dave Phillips The Book Of Linux Music & Sound at http://www.nostarch.com/lms.htm The Linux Soundapps Site at http://linux-sound.org
Re: [linux-audio-dev] exploring LADSPA
On Thu, Aug 14, 2003 at 03:00:51PM +0200, Ingo Oeser wrote: > On Thu, Aug 14, 2003 at 09:55:01AM +0100, Steve Harris wrote: > > You can do it efficiently in software if you downcompile the > > modules to a processing loop at runtime, c.f. the linuxsampler > > project. > > This should be the default, since compiling is fast and cheap > these days. Well, if youre working in a modular you might not want it recompiling after every connection. > There could be even a mix, where you compile relocatable blocks, > which can be chosen. I would envision sth. like the GCC uses for > the backend, but much simpler. And you could have the eqivalent of interpreting where the blocks are run like plugins, and only downcompiled when you tell it to (like in SyncModular). > > The is an area where we can really beet the closed source guys as we have > > no issues with giving away out DSP code. > > But a version for communicating with these commercial stuff > should be there. Right, but it wouldn't be able to downcompile commercial stuff, cos they wouldn't make the source available. > With a compiled version, we win at least in cache usage and > therefore should also win in performance ;-) Yes, its a significant win for blockless processing, less for for blocked, but I expect its still worthwhile. - Steve
RE: [linux-audio-dev] exploring LADSPA
>> Would like to respond to Pete Yadlowsky... >Thanks, Brad. >> |- I've done away with the distinction between control signals and audio >> |signals. >> Early on I adopted this approach but have changed my ways as I traveled down >> the >> path for a few reasons. Actually, I have made the distinction of a control >> signal >> versus an audio path for the sake of patching. A control signal in my system >> is >> primarily a single channel signal but has all the characteristics of a >> single >> audio channel. The audio channel is actually a stereo 2x channel. > I can see that if the system has a built-in stereophonic sense that you'd want > control and audio signals on separate "busses". However, in the system I've > been working on (I'm calling it XAK: extensible audio kit) there's no innate > support for any particular number of channels. I wanted the flexibility to do > stereo, quad, septaphonic, etc, so I deliberately omitted any assumed sense > of channel-ness. So, how to handle an arbitrary number of channels? There is > support in place such that XAK's plugins can be written to allow for blocks > of arbitrary numbers of input or output ports, designated during a > post-initialization configuration phase. To configure, say, an N-output > reverb unit: > self->outs = xak_output_bank (self, "out"); > Which produces a block of output ports named out1, out2, etc. (This brings me > to another salient feature: ports are identified by symbolic names, rather > than numbers, granted at init/configuration time.) By this feature, one can > patch together an N-channel audio buss of virtually any width. Sounds interesting. My system is similar but my audio paths are still stereophonic due to the large number of modules that rely on stereo pairs and you can always assign "control" channels to deal with an exception. I have a delay module that I have been working on that provides multile audio paths as you describe but the output is still in pairs. Ultimately I mix down to stereo anyway (I only have two ears). I know some audio systems support 6 channels for professional use but they are arrange in three stereo pairs. >> I would also like to say that I have looked at the Jack and LADSPA signal >> paths >> and I believe they are single precision floating point numbers. I personally >> have adopted the double precision format > As have I. >> and have done extensive benchmark tests and >> have found no degradation in performance > 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. No difference according to my benchmarks - 0 difference >> I would like to comment on this as well. The audio and signal path objects >> that >> I have described actually have the number of samples contained within a >> packet object and these are passed between the objects. > The packet idea is interesting. I'll consider it further. >> |- Every input port is a mixer/modulator. >> Internally though, I create a separate module that is >> "auto-patched" >> into the patch for two reasons; 1) I dont incur the overhead of a summation >> or modulation process if there aren't two signals to contend with > With XAK's "multi-jacked" input port, the signal sum/product is initialized > with the value of the first feeder signal. If there are additional signals to > deal with, only then is the necessary arithmetic performed. >> and 2) I do >> not burden the module code writer with the additional task of dealing with >> the process of summation or modulation of multiple inputs. > XAK handles this for the coder transparently by a certain function provided > with a set of core utilities: > sample = xak_readport (self->inport); > It seems that a LADSPA input port is basically a block of memory where > computed samples are written. The XAK input port, in contrast, is a structure > whose owning plugin queries it for a sample. In response, the port's feeders' > plugins' run() methods are invoked, who in turn query their input ports, and > so on up the chain. One complete chain reaction, driven by xak_readport() > above, constitutes a single sample run. > I have written Python bindings for XAK to facilitate test and experimentation, > and to simplify the construction of complex networks of plugins and lists of > events to drive them. > I get a sense from postings to this list that this group is primarily > interested in real-time synthesis. RT doesn't interest me so much at this > time, partly because I'm running on a clunky old 400MHz machine, and partly > because I'm more interested in the purity of the idea than I am in wringing > every last drop out of each machine cycle. The hardware will inevitably get > faster, but at least for now I'll be content to churn out gigabytes of sound > files. I am a real time musician and I like the real time performance myself.
Re: [linux-audio-dev] exploring LADSPA
On Thu, Aug 14, 2003 at 12:22:06PM +0100, Steve Harris wrote: > 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, sorry, I didn't mean to be so negative. I'd been > having a bad day. :) np. I actually think random ideas are wonderful - that is how you break out of ruts. -- Notice that as computers are becoming easier and easier to use, suddenly there's a big market for "Dummies" books. Cause and effect, or merely an ironic juxtaposition of unrelated facts?
Reason for current policy, was Re: [linux-audio-dev] Should the list be members-only?
One more bit of information... I'm not sure if everybody knows that there was a good reason the list policy was set to open. *please follow up to the other thread*, this is just an aside... >From http://www.linuxdj.com/audio/lad/subscribelad.php3: The list is open. You can post messages even if you are not subscribed. This is necessary to make cross-postings and participation from people on the ALSA and linux-kernel lists possible. It also means we have to live with the occasional spam. It can be helpful to subscribe and lurk for a while before you join the discussion to familiarize yourself with the the habits of the tribe :) So, changing policy would mean the list-admin volunteer(s) would get bombarded with approval requests every time there's a thread crossposted. This would also really slow down those discussions. Mailman does provide a tantalizing option: you can require the list address be in the explicit destinations (to or cc), which we already do; and then provide addresses which are considered equivalent to the list address as acceptable destinations. However, I assume this option does not override the non-member policy. It would be very odd if it did! But would be handy for our purposes - not much (if any) spam has both linux-audio-dev and linux-kernel or alsa-devel in the explicit recipients. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's SQUEEGIE GUY PSEUDO SOUP! (random hero from isometric.spaceninja.com)
Re: Reason for current policy, was Re: [linux-audio-dev] Should the list be members-only?
On Thu, Aug 14, 2003 at 04:55:41PM +0200, Frank Barknecht wrote: > Without saying my opinion (which is ambivalent, because I use > spamassassin and often don't see the spam coming through) I don't know why I didn't think of this before, but I'm going to look into getting SpamAssasin in the pipe *before * mailman, which can then require moderator approval for anything spammish. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's SPIFFY MIDGET! (random hero from isometric.spaceninja.com)
Re: [linux-audio-dev] softsynth SDK?
Hallo, nikodimka hat gesagt: // nikodimka wrote: > I have a couple of algorithms I would like to turn > into a softsynth. > I want the synth to be alsaseq->synth->jack . > And I want it to have a couple of GUI knobs. ... > I would really like to escape dealing with basic functionality > which has been implemented tens of times in the existing > softsynths, but want to concentrate on the algorithms themselves. Well, why not extend some of the existing softsynths? That's what I do: Because I'm too lazy to write gui code I write Pd externals. The GUI part can be quickly done inside Pd (and every other user could do their own). jMax or SSM also come to mind and of course it is also possible to directly write a LADSPA plugin and load that in one of those softsynths. ciao -- Frank Barknecht _ __footils.org__
Monitor - again Re: [linux-audio-dev] Linux 2.6 not a latency panacea?
On Thursday 14 August 2003 15.59, Takashi Iwai wrote: > At Thu, 14 Aug 2003 02:55:28 +0300 (EEST), > > Kai Vehmanen wrote: > > For example, one new approach to the problem SCHED_SOFTRR, see: > > http://www.xmailserver.org/linux-patches/softrr.html > > http://www.ussg.iu.edu/hypermail/linux/kernel/0307.1/1729.html > > > > It's unlikely to get something like this enabled by default in the > > vanilla kernel, but we might be able to get a kernel option (no > > patching!). But, but, as you can see from the discussion, they are > > talking about totally different things (how XMMS/realplayer performs)... > > > > ... basicly a way to get benefits of SCHED_FIFO but without need for root > > privileges. Now we just need to push these to the standard kernel > > somehow. > > i think the most benifit of soft-RR is that it doesn't bring your box > hanging up even if a RT-process gets into an infinite loop. this will > help to sort out the problem when a JACK system freezes with > SCHED_FIFO. (i.e. if it happens with soft-RR, it's a kernel/driver > bug :) My monitor can do this too. But you need to have that running. It degrades ALL SCHED_FIFO/RT processes to SCHED_OTHER on overuse - processes that do run as root could be protected. (FUTURE) > > running by the normal user is an additional gift, for my eyes. > such a feature can be implemented with a wrapper (library), too, > as jackstart does. You can request SCHED_FIFO/RT from my monitor. Current implementation is working but it can be improved! It uses static allocations intentionally. The problem is to get it accepted - should it be added to jack(d)? /RogerL -- Roger Larsson Skellefteå Sweden rt_monitor.zip Description: Zip archive
Re: [linux-audio-dev] gQ for Linux
Greetings: I've downloaded Dan's sources and am in the process of getting gQ to compile. I have the ViewKit stuff from ICS, and I also have OpenMotif on my system. I've edited the Makefile for a Linux machine but I'm currently stuck here: [EMAIL PROTECTED] gQ.src]$ make gcc -g -O2 -c MasterControls.C In file included from MasterControls.C:149: SoundIn.h:26: syntax error before `;' SoundIn.h:27: syntax error before `;' MasterControls.C: In method `MasterControls::MasterControls (const char *, _WidgetRec *)': MasterControls.C:250: name lookup of `i' changed for new ISO `for' scoping MasterControls.C:243: using obsolete binding at `i' MasterControls.C: In method `void MasterControls::play (_WidgetRec *, void *)': MasterControls.C:1106: warning: passing `double' for argument passing 1 of `sleep (unsigned int)' MasterControls.C:1106: warning: argument to `unsigned int' from `double' MasterControls.C:1119: cannot convert `void (*) ()' to `void (*) (int)' for argument `2' to `signal (int, void (*) (int))' MasterControls.C:1128: `PR_SADDR' undeclared (first use this function) MasterControls.C:1128: (Each undeclared identifier is reported only once for each function it appears in.) MasterControls.C:1128: `sproc' undeclared (first use this function) MasterControls.C: In method `void MasterControls::stopPlay (_WidgetRec *, void *)': MasterControls.C:1184: warning: passing `double' for argument passing 1 of `sleep (unsigned int)' MasterControls.C:1184: warning: argument to `unsigned int' from `double' MasterControls.C: In method `void MasterControls::OpenFile (const char *)': MasterControls.C:1593: name lookup of `i' changed for new ISO `for' scoping MasterControls.C:1586: using obsolete binding at `i' MasterControls.C: In method `void MasterControls::SaveFileAs (const char *)': MasterControls.C:1659: name lookup of `i' changed for new ISO `for' scoping MasterControls.C:1652: using obsolete binding at `i' MasterControls.C: In method `void MasterControls::SaveFile ()': MasterControls.C:1684: name lookup of `i' changed for new ISO `for' scoping MasterControls.C:1677: using obsolete binding at `i' MasterControls.C: In method `void MasterControls::OpenSoundfile (const char *)': MasterControls.C:1731: warning: assignment to `int' from `float' MasterControls.C:1731: warning: argument to `int' from `float' MasterControls.C: In method `void MasterControls::writeAIFF ()': MasterControls.C:1780: cannot convert `void (*) ()' to `void (*) (int)' for argument `2' to `signal (int, void (*) (int))' MasterControls.C:1799: warning: passing `double' for argument passing 1 of `sleep (unsigned int)' MasterControls.C:1799: warning: argument to `unsigned int' from `double' MasterControls.C: In method `void MasterControls::writeNEXT ()': MasterControls.C:1850: cannot convert `void (*) ()' to `void (*) (int)' for argument `2' to `signal (int, void (*) (int))' MasterControls.C:1868: warning: passing `double' for argument passing 1 of `sleep (unsigned int)' MasterControls.C:1868: warning: argument to `unsigned int' from `double' MasterControls.C: In function `void playsnd (void *)': MasterControls.C:1952: warning: initialization to `int' from `float' MasterControls.C:1952: warning: argument to `int' from `float' MasterControls.C:1953: warning: initialization to `int' from `float' MasterControls.C:1953: warning: argument to `int' from `float' MasterControls.C: In function `void playsndMono (void *)': MasterControls.C:2049: warning: initialization to `int' from `float' MasterControls.C:2049: warning: argument to `int' from `float' MasterControls.C:2050: warning: initialization to `int' from `float' MasterControls.C:2050: warning: argument to `int' from `float' MasterControls.C: In method `void MasterControls::DrawGrid ()': MasterControls.C:2350: name lookup of `i' changed for new ISO `for' scoping MasterControls.C:2349: using obsolete binding at `i' make: *** [MasterControls.o] Error 1 I'm stuck at the syntax error in SoundIn.h and at the PS_SADDR macro, and I'm open to advice and suggestions. If anyone would like to help out with the port please contact me off-list and we'll carry on from there. Best regards, == Dave Phillips The Book Of Linux Music & Sound at http://www.nostarch.com/lms.htm The Linux Soundapps Site at http://linux-sound.org
Re: [linux-audio-dev] Re: gQ for Linux
On Thu, 14 Aug 2003, Dave Phillips wrote:
> Martijn Sipkema wrote:
>
> > [...]
> > > What is 'ALport' and 'ALconfig', and where are they
> > > defined?
> >
> > Those are part of the SGI audio library and I woudn't expect them
> > to be available under Linux.
>
> Actually they are available for Linux. Richard Kent, author of the DAP
> soundfile editor, ported the SGI audio library quite some time ago. His
> work is called 'tichstuff' and is available here:
>
> ftp://mustec.bgsu.edu/pub/linux/tichstuff.tar.gz
>
Its better to use the standard libaudiofile (which ao. gnome uses), and
add the following definitions:
#ifdef GNOME_AUDIOFILE
/* Michael PruettAudiofilelib */
#define AFreadframes afReadFrames
#define AFwriteframes afWriteFrames
#define AFopenfile afOpenFile
#define AFgetchannels afGetChannels
#define AFgetrate afGetRate
#define AFgetcompression afGetCompression
#define AFgetfilefmt afGetFileFormat
#define AFgetsampfmt afGetSampleFormat
#define AFgetframecnt afGetFrameCount
#define AFclosefile afCloseFile
#define AFclosefile afCloseFile
#define AFseekframe afSeekFrame
#define AFclosefile afCloseFile
#define AFnewfilesetup afNewFileSetup
#define AFfreefilesetup afFreeFileSetup
#define AFinitchannels afInitChannels
#define AFinitrate afInitRate
#define AFinitcompression afInitCompression
#define AFinitfilefmt afInitFileFormat
#define AFinitsampfmt afInitSampleFormat
/* to satisfy the linker , compression not supported */
int afGetCompression (AFfilehandle fh, int track)
{
return AF_COMPRESSION_NONE;
}
void afInitCompression (AFfilesetup afs, int track, int compression)
{
}
#endif
Then you can read wav files etc. Not just aiff.
--
Re: [linux-audio-dev] Should the list be members-only?
At 05:12 PM 14/08/2003, Paul Winkler wrote: We seem to be getting quite a lot of spam lately. Currently the list is "open" - non-members can post. I'd like to take an informal poll: Should the LAD list remain totally open, or should non-member postings require moderator approval? I should point out that the LAU list requires approval for non-member postings, and it seems to be no problem in my very-limited experience managing the lists: I check the pending-approval queue at least once a day, find nothing but spam, and throw it away. Approving a legit non-member posting would be trivially easy. I think that this list should be for members only, and it is not that hard to join anyway. If they really want us to get the message, they would join. Regards Luke Luke Yelavich AudioSlack Founder and main package maintainer Audio software packaged for the Slackware Linux Distribution http://www.audioslack.com [EMAIL PROTECTED]
Re: [linux-audio-dev] Linux 2.6 not a latency panacea?
At Thu, 14 Aug 2003 02:55:28 +0300 (EEST), Kai Vehmanen wrote: > > For example, one new approach to the problem SCHED_SOFTRR, see: > http://www.xmailserver.org/linux-patches/softrr.html > http://www.ussg.iu.edu/hypermail/linux/kernel/0307.1/1729.html > > It's unlikely to get something like this enabled by default in the vanilla > kernel, but we might be able to get a kernel option (no patching!). But, > but, as you can see from the discussion, they are talking about totally > different things (how XMMS/realplayer performs)... > > ... basicly a way to get benefits of SCHED_FIFO but without need for root > privileges. Now we just need to push these to the standard kernel somehow. i think the most benifit of soft-RR is that it doesn't bring your box hanging up even if a RT-process gets into an infinite loop. this will help to sort out the problem when a JACK system freezes with SCHED_FIFO. (i.e. if it happens with soft-RR, it's a kernel/driver bug :) running by the normal user is an additional gift, for my eyes. such a feature can be implemented with a wrapper (library), too, as jackstart does. Takashi
Re: [linux-audio-dev] exploring LADSPA
On Thu, Aug 14, 2003 at 01:24:50AM -0400, Paul Davis wrote: > > >and other controllers using (yuck) MIDI for now. LADSPA is interesting but > >I do not see where it handles some of the issues of polyphonic voicing > >and assignment control. > > it doesn't. it was never meant to. attempts to create an API that did > do this led to discussions here (on LAD) about "XAP", but this has > just about all moved to the GMPI mailing list, where us LAD'ers get to > hang out and talk shop with the guys at Cakewalk, Adobe, FXpansion, > and several other companies who work on plugins and DAWs. devising > your own new API at this time is a bit like, err, err, i don't know > what its like but its like something. It's like designing a new windowing system. You MIGHT do better, but lots of really smart people have done worse. I'd actively beg that anyone who has a lot of thoughts on this PLEASE catch up on GMPI and join in the fray. The XAP ideas have actually been pretty well received so far, and the LAD community is doing a lot to stop the Mac and Windows people from screwing this up yet again (Paul, Steve - my thanks!). > not missing the point. i welcome any and all developers to LAD and to > LADSPA. but those who don't know and understand history are condemned > to repeat it, and the linux world is full of repeated false starts > while all the time promising projects cry out for more assistance to > flesh them out. I too started my own plugin API to replace LADSPA for multichannel IO and instruments etc. It's a BIG problem to do really right. I think XAp had some REALLY clever ideas come out of it. GMPI is sanctioned by the MMA - if ANYTHING has a chance at succeeding cross-platform, that is it. Yes, it is a SLOW process. Yes, you'll have to make concessions to Windows developers. But in the end, you might just have a real winner of an API. Tim
Re: [linux-audio-dev] exploring LADSPA
On Wednesday 13 August 2003 08:09 pm, Paul Davis wrote: > per-sample processing isn't a feasible option as a general API model > for, oh, i'd guess at least another 3-4 years. I'm in no particular hurry. Till then, I'll just chug along. I can't help but find the one-sample model compellingly attractive in its simplicity. I only have to wait for the hardware to catch up.
Re: [linux-audio-dev] Should the list be members-only?
Jack O'Quin wrote: > ... I would vote++ for the suggestion to moderate non-member postings. Agreed. Best regards, == Dave Phillips
[linux-audio-dev] exploring LADSPA
Hello,
I'm new to this mailing list, though not especially new to computer music. I
was heavily involved in it some years ago, mainly on the NeXT platform, then
fell away. Out of curiousity, I recently decided to look around and see what
was available today for Linux, audio-wise.
One of the items I found was LADSPA. "A standardized interface for audio
plugin units carried in shared libraries," thought I. "Interesting idea." I
took a closer look at LADSPA and, like any happy programmer, decided that
there are some things about it that I'd do differently. So, to flesh out and
test my ideas, and just for fun, I proceeded to build a LADSPA-inspired
plugin system of my own. I'm writing now to present these ideas in the event
that someone may find a few of them useful, and to perhaps contribute to
LADSPA's evolution:
- I've done away with the distinction between control signals and audio
signals. I understand the performance gains to be had by computing one class
of signals less often than another, but I feel this is a hold-over from days
when computers were much slower than they are now. In my ideal system,
signals are signals and any signal should be potentially applicable to any
purpose. I don't want to be bothered with control vs. audio, either
conceptually or in actual code.
- 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
conceptual simplification. I don't want the individual plugin to have to know
anything of process iteration; that job is for the containing infrastructure.
Also, some years ago I started working on some computer synthesis software
and found that when units ("plugins") computed samples in blocks (instead of
one at a time), there was a strange behavior when these units were patched
together in looped delay line configurations. As I recall, gaps would appear
in the audio output, and these gaps would grow in length as the loop
proceeded. I don't remember if I ever discovered the exact cause, but I think
it had something to do with the relationship between the length of a block of
samples and the length of the delay line. Maybe I was doing something wrong,
but going to a one-sample-per-run process made the problem go away. I wanted
the flexibility of being able to patch units together in any sort of
topology.
- Every input port is a mixer/modulator. Since the operations of mixing and
modulating (multiplying) signals together are so often needed, I decided to
build them into plugin input ports. A given input port can accept any number
of connections from "feeders" and either mixes or modulates their outputs
transparently, according to the port's configuration. I believe this
simplifies use of the system and eliminates the need for a special
runAdding() plugin method.
There's more, but this is getting rather long. I'll leave it here for now. If
you've gotten this far, thanks for your time.
--
Pete Yadlowsky
ITC Unix Systems Support
University of Virginia
Re: [linux-audio-dev] exploring LADSPA
>that someone may find a few of them useful, and to perhaps contribute to
>LADSPA's evolution:
LADSPA's evolution is most likely to take place within the context of
GMPI (Generalized Music Plugin Interface), a cross-industry attempt to
define a new platform and vendor independent audio/MIDI plugin API. it
will be slow, but there isn't a lot of point in doing much more than
tweaking LADSPA for now.
note that LADSPA was originally designed to be a "least common
denominator" among numerous fractured app-specific audio plugin
APIs. it has served this purpose extremely well, and i think most of
its contributors, users and developers would be inclined to leave it
that way :)
>- I've done away with the distinction between control signals and audio
>signals. I understand the performance gains to be had by computing one class
>of signals less often than another, but I feel this is a hold-over from days
>when computers were much slower than they are now. In my ideal system,
Sure, in your ideal system. In my ideal system, I'd love to be able to
do real-time physical modelling of a full string orchestra, and add in
real time convolution-based reverb to model the hall. But in any real
system, there are always limits, and even on the recent 2.4GHz dual
athlon system i tested recently, its completely *trivial* to overload
the CPU with audio synthesis and processing.
>- 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
everybody knows its incredibly inefficient. you have 100% of the
overhead of a chain of function calls for every sample. for anything
except trivial processing, its too expensive to be useful for a
general purpose API (for now).
>conceptual simplification. I don't want the individual plugin to have to know
>anything of process iteration; that job is for the containing infrastructure.
>Also, some years ago I started working on some computer synthesis software
>and found that when units ("plugins") computed samples in blocks (instead of
>one at a time), there was a strange behavior when these units were patched
>together in looped delay line configurations. As I recall, gaps would appear
if you read "the computer music tutorial" by curtis rhoads, you could
avoid discovering this, and instead read about what people have done
to tackle the problem since it was noted 25-30 years ago :)
per-sample processing isn't a feasible option as a general API model
for, oh, i'd guess at least another 3-4 years. and many operations
that want to work in the frequency domain require blocks anyway, and
so are not helped by this design.
>- Every input port is a mixer/modulator. Since the operations of mixing and
>modulating (multiplying) signals together are so often needed, I decided to
>build them into plugin input ports. A given input port can accept any number
>of connections from "feeders" and either mixes or modulates their outputs
>transparently, according to the port's configuration. I believe this
>simplifies use of the system and eliminates the need for a special
>runAdding() plugin method.
JACK (http://jackit.sf.net/) does this too. its a very nice design,
although it has its downsides.
--p
Re: [linux-audio-dev] gQ for Linux
If its paragraphic then the UI is an important part, so LADSPA wouldnt be appropraite. - Steve On Wed, Aug 13, 2003 at 12:29:51 +0100, antoine rivoire wrote: > Hi, > Could it be more useful to have this ported to LADSPA? I am not familiar > with the application nor the LADSPA API so please excuse me if this is a > stupid idea. > I sure would like a nice EQ plugin with a nice GUI. > Regards > > > > > On Wed, 2003-08-13 at 02:25, Erik de Castro Lopo wrote: > > On Tue, 12 Aug 2003 18:18:13 -0700 (PDT) > > kevin ernste <[EMAIL PROTECTED]> wrote: > > > > > And the source can be found here: > > > > > > http://music.princeton.edu/~dan/programs.html > > > > > > Note that Dan's open source lisencing terms can be found in the src > > > tarball's README. > > > > Sorry Kevin, but I can't find anything in the tarball that looks anything > > like a proper license. > > > > Erik > -- > antoine rivoire <[EMAIL PROTECTED]>
Re: [linux-audio-dev] Mx4
Hi ! When I moved Mx4 across the room to my motherkeyboard, I realized that I had forgotten to implement sustain-pedal ... It is in place and works now. Get it at the usual place: http://hem.passagen.se/ja_linux/ c[] // Jens M Andreasen
Re: [linux-audio-dev] exploring LADSPA
>>> and have done extensive benchmark tests and >>> have found no degradation in performance > >> 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. > >No difference according to my benchmarks - 0 difference most other testers measure 6-8% on intel h/w (slower for doubles). you have to be very careful that you are measuring two different situations. automatic compiler conversions can make what appears to be float math actually be double to start with. >> I get a sense from postings to this list that this group is primarily >> interested in real-time synthesis. RT doesn't interest me so much at this >> time, partly because I'm running on a clunky old 400MHz machine, and i routinely run RT synthesis code on my clunky old 450MHz machine :) >and other controllers using (yuck) MIDI for now. LADSPA is interesting but >I do not see where it handles some of the issues of polyphonic voicing >and assignment control. it doesn't. it was never meant to. attempts to create an API that did do this led to discussions here (on LAD) about "XAP", but this has just about all moved to the GMPI mailing list, where us LAD'ers get to hang out and talk shop with the guys at Cakewalk, Adobe, FXpansion, and several other companies who work on plugins and DAWs. devising your own new API at this time is a bit like, err, err, i don't know what its like but its like something. >Do not be discouraged by those that tell you that we already did it and >why don't you use that. They are missing the point, aren't they! 8^) not missing the point. i welcome any and all developers to LAD and to LADSPA. but those who don't know and understand history are condemned to repeat it, and the linux world is full of repeated false starts while all the time promising projects cry out for more assistance to flesh them out. --p "grumpy old man"
[linux-audio-dev] Should the list be members-only?
Hi folks, your friendly temporary list-admin here. (Joern's on vacation and I'm filling in.) We seem to be getting quite a lot of spam lately. Currently the list is "open" - non-members can post. I'd like to take an informal poll: Should the LAD list remain totally open, or should non-member postings require moderator approval? I should point out that the LAU list requires approval for non-member postings, and it seems to be no problem in my very-limited experience managing the lists: I check the pending-approval queue at least once a day, find nothing but spam, and throw it away. Approving a legit non-member posting would be trivially easy. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's GILDED THANATOS MYRKSKOG! (random hero from isometric.spaceninja.com)
Re: [linux-audio-dev] Should the list be members-only?
On Thu, Aug 14, 2003 at 03:12:55AM -0400, Paul Winkler wrote: > Should the LAD list remain totally open, or should > non-member postings require moderator approval? Given the amount of spam we're having the last days, I'd say the list should be moderated for non-members, and for new members until they've posted something on-topic. -- FA
Re: [linux-audio-dev] Re: gQ for Linux
"Kjetil S. Matheussen" wrote: > Its better to use the standard libaudiofile (which ao. gnome uses), and > add the following definitions: > [snip] Unfortunately libaudiofile doesn't address the particular problem, and Michael never ported libaudio. Kjetil, you have considerable experience porting SGI audio software to Linux: would you be interested in looking at Dan's code ? I'm sure you could see how to resolve the difficulty with SoundIn.h (it's written for SGI audio I/O). Best regards, == dp
[linux-audio-dev] gQ for Linux
Hello - I have recently persuaded Dan Trueman to release the source code for his amazing real-time paragraphic EQ app, "gQ" (originally for Irix, motif/viewkit) with the intention of finding developers interested in porting it to Linux, ideally as a JACK client. It was recently ported to Max (and now PD minus the graphics) as a part of the PeRColate externals (http://www.music.columbia.edu/PeRColate/), but both Dan and I feel a standalone Linux version would be very useful. Is anyone interested in helping tackle this one? I may do it myself if there are no takers, but it will take me _much_ longer than a 'real' coder ;> The orignal desription as well as a shot of gQ can be found here: http://www.music.princeton.edu/%7Edan/gQpage/gQ.html And the source can be found here: http://music.princeton.edu/~dan/programs.html Note that Dan's open source lisencing terms can be found in the src tarball's README. Kevin = "I should prefer this note not be read or, if skimmed, that it should be forgotten." - Mallarme __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: Reason for current policy, was Re: [linux-audio-dev] Should the list be members-only?
Hallo, Paul Winkler hat gesagt: // Paul Winkler wrote: > One more bit of information... I'm not sure if everybody knows that > there was a good reason the list policy was set to open. [...] Without saying my opinion (which is ambivalent, because I use spamassassin and often don't see the spam coming through) I'd like to make a point that a poll on this list will only get responses from members of the list. A non-regular poster will of course probably not speak up now to keep the list open. I am on a lot of mailing lists, I filter with procmal, scan with spamassassin and my email address is on so many webpages, I don't need to protect it anymore. But a casual poster might just look for an answer to a single question and might not want to follow all the discusscions on the list by subscription. That's a reason for keeping this list open. It may not be a strong one though, but might probably be stronger for LAU actually. Just my 2 cent thingie enlargement. ciao -- Frank Barknecht _ __footils.org__
Re: [linux-audio-dev] exploring LADSPA
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 > everybody knows its incredibly inefficient. you have 100% of the > overhead of a chain of function calls for every sample. for anything > except trivial processing, its too expensive to be useful for a > general purpose API (for now). So does sfront, SyncModular and and lots of hardware systems. You can do it efficiently in software if you downcompile the modules to a processing loop at runtime, c.f. the linuxsampler project. The is an area where we can really beet the closed source guys as we have no issues with giving away out DSP code. > per-sample processing isn't a feasible option as a general API model > for, oh, i'd guess at least another 3-4 years. and many operations > that want to work in the frequency domain require blocks anyway, and > so are not helped by this design. NB nor by the current design of blocked systems, the FFT, WSOLA, etc. requirements are a bit odd. > >transparently, according to the port's configuration. I believe this > >simplifies use of the system and eliminates the need for a special > >runAdding() plugin method. My suspicion is that runAdding et al is just unneccesary (c.f. cache effects), but I haven't benchmarked it. - Steve
Re: [OT] Re: [linux-audio-dev] Linux 2.6 not a latency panacea?
At Thu, 14 Aug 2003 16:27:37 +0200, Robert Jonsson wrote: > > Hi, > > > > I also found 2.6.0-test[123] to be less responsive than 2.4.x-ll, or even > > > stock 2.4.x. I've also experienced XMMS dropouts under load (for example > > > compiling Muse) > > > > > > Some behaviour I've noticed is that under heavy load the desktop/audio > > > doesn't freeze for a certain block of time, but rather in short (~2 > > > seconds) intervalls... > > > > this should have been imporved significantly in -mm tree. > > even reducing the min/max timeslices would help a lot. the default > > values look too large for desktop users... > > A fairly of topic question: Since 2.6 contains several schedulers; is this > selectable at runtime or is it a compiletime switch ? it's defined statically in kernel/sched.c: /* * These are the 'tuning knobs' of the scheduler: * * Minimum timeslice is 10 msecs, default timeslice is 100 msecs, * maximum timeslice is 200 msecs. Timeslices get refilled after * they expire. */ #define MIN_TIMESLICE ( 10 * HZ / 1000) #define MAX_TIMESLICE (200 * HZ / 1000) ... (remember that HZ=1000 in 2.6 for i386.) > Sounds shaky to select at runtime, but infinitely cool :) i guess it would be relatively easy to replace the above with variables controlled via sysctl. Takashi
Re: [linux-audio-dev] Should the list be members-only?
Robert Jonsson <[EMAIL PROTECTED]> writes: > There is some crossposting occuring that, atleast sometimes, is > worth while. If the list is closed this won't be possible if not all > senders are members of all the mailinglists, and that is hardly the > purpose. This actually works fairly well already (in reverse). I did reply-all to a message sent to both LAD and LAU (without realizing it) back when I was not subscribed to LAU. I got a sensible response saying that since I was not subscribed my message was awaiting moderator approval. The moderator approved my message after perhaps half a day. Once I realized what had happened, I subscribed to LAU as well. Problem solved. :-) So, I would vote++ for the suggestion to moderate non-member postings. -- Jack O'Quin Austin, Texas, USA
Re: [linux-audio-dev] exploring LADSPA
On Thu, Aug 14, 2003 at 09:55:01AM +0100, Steve Harris wrote: > You can do it efficiently in software if you downcompile the > modules to a processing loop at runtime, c.f. the linuxsampler > project. This should be the default, since compiling is fast and cheap these days. There could be even a mix, where you compile relocatable blocks, which can be chosen. I would envision sth. like the GCC uses for the backend, but much simpler. > The is an area where we can really beet the closed source guys as we have > no issues with giving away out DSP code. But a version for communicating with these commercial stuff should be there. With a compiled version, we win at least in cache usage and therefore should also win in performance ;-) Regards Ingo Oeser
[linux-audio-dev] Edirol PCR-30 working with ALSA.
Hello everyone! I just picked up one of the Edirol PCR-30 usb keybaords. Seems to work just fine with the snd-usb-audio drivers. I figured it should be added to the ALSA Soundcard Matrix. I'm sure the PCR-50 could be added as well. cheers! rob buse ___ Sent through e-mol. E-mail, Anywhere, Anytime. http://www.e-mol.com
[linux-audio-dev] Letter.
Dear Sir, Compliments, I implore you to take the time to go through my letter carefully as the decision you make will go off a long way to determine the future and continued existence of the entire members of my family and your own famiy. Having retired for two and a half year now. I have been bored, until my children introdued me to the use of internet teaching me how wild and how it has made the world a small place. However, i got fasinated and starting everyday and since i have a lot of time, that is alot of time to spent on the internet. I came across your contact. I am happy to say that as a former (retired) military service man and former defense minister in Nigeria i been blessed with a lot of influence and all the things money can buy. I've quite a lot of funds for any useful investment and having discussed with my daughter who handles my finance, i would be glad if you would consider useful whatever investment, either a shipping investment or others. I actually and eventually wish to build a strong and trustworthy relationship with you as my partner to secure and preserve whatever we might agree to do. Also i would not suggest for an investment in Africa regarding and considering some obvious security and logistic reasons. Once again, i am happy for been opportuned to contact you through this means of communication, also appreciate to meet you for this wonderful business investment opportunity that we are yet to negotiate as business partners and as my foriegn partner. I will be glad if this opportunity is quarrantee and consider my outmost partnership enquiry. Thanks. Yours Faithfully, Rtd. Gen.T.Y Danjuma. Private Tel:234-8034-033-173 Email:[EMAIL PROTECTED]
[linux-audio-dev] Cut your debt in half! READ THIS NOW fdsjio
Read this! Why buy your bank manager a new car? We blast your debt and give you a fresh start! - Save you a lot of money by eliminating late fees - Settle your accounts for a substantially reduced amount - Stop creditors calling you on the phone - Avoid bankruptcy ... and more! Why keep dealing with the stress, and headaches? Combine your debt into a low interest repayment and get on with your life today!! Come here and take a look at how we can help. http://btrack.iwon.com/r.pl?redir=http://[EMAIL PROTECTED]/index.php?N=g stop more of these http://btrack.iwon.com/r.pl?redir=http://[EMAIL PROTECTED]/r.php
Re: [linux-audio-dev] Linux 2.6 not a latency panacea?
On Wed, Aug 13, 2003 at 03:09:10PM -0700, Joshua Haberman wrote: > I am distressed. It was my understanding that the 2.5/2.6 kernel branch > was undergoing significant scheduler and latency work, and that 2.6 > would eliminate the kernel from the list of obstacles of low-latency on > Linux. It will have the preemptable kernel patch, the new scheduler, > and all of Ingo Molnar's low-latency work. Claims were being thrown > around that 2.6 would be the lowest-latency operating system on the planet. > > So how is it that we're in the 2.6.0-test series and people are > complaining about audio skipping in **XMMS**, which uses three second > buffers by default?? If people are getting skips from high-latency > playback, what hope is there for low-latency audio? A series of patches > are coming from both Ingo and Con Kolivas attempting to address this, > but the fact they are just now throwing around potential solutions > erodes at my faith that they really understand the problem or how to > solve it. > > Is 2.6.x going to be suitable for low-latency (or even reliable > high-latency) audio? Or is it going to be more of the same: patching > the kernel, tweaking parameters, reading magical incantations, and > hoping for the best? > > Reassure me please! > > Josh > I also found 2.6.0-test[123] to be less responsive than 2.4.x-ll, or even stock 2.4.x. I've also experienced XMMS dropouts under load (for example compiling Muse) Some behaviour I've noticed is that under heavy load the desktop/audio doesn't freeze for a certain block of time, but rather in short (~2 seconds) intervalls... cheers, Christian Henz
Re: [linux-audio-dev] gQ for Linux
Hallo, Steve Harris hat gesagt: // Steve Harris wrote: > If its paragraphic then the UI is an important part, so LADSPA wouldnt be > appropraite. I think it best would be a Jack app (next to freqtweak) ciao -- Frank Barknecht _ __footils.org__
Re: [linux-audio-dev] Denormal numbers
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 gcc's sse2 code generation unfortunatly. I dont know when, or if they have been fixed. - Steve
[linux-audio-dev] A job posting someone here has to be qualified for
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Folks, I wish I was qualified for this one. I'm not quite so I thought I'd pass it on to those who might be. Bearcat M. Sandor Linux Codec Software Engineer COMPANY: Top Notch Audio SKILLS REQUIRED: Software Developer Linux Codecs Application Embedded LOCATION: Any in US, AK RATE: Open AREA: 000 LENGTH: Contract Immediate TERM: CON_IND CON_HIRE_IND CON_CORP CON_HIRE_CORP SUMMARY: Linux Developer - Codecs I have an immediate start for contractor to work with our team. Telecommute to start. Initial contractor relationship with very possible contract to hire. Tasks: Test, Rework and Optimize Codecs. Troubleshoot Linu http://seeker.dice.com/seeker.epl?rel_code=35&op=5&type=14&dockey=xml/2/7/[EMAIL PROTECTED]&source=2 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/MpHvya+RPo9ly58RAmlrAKCrvAYrEcLIndHEUIa9YE24Yr8hmQCdE2dr zaeJcG/0Nb/EbAIcM/r3aAM= =olSH -END PGP SIGNATURE-
[linux-audio-dev] Problems with sb-live wave-tables and midi
Hi, I have this error that I don't know how to fix. I was using Craig Stuart Sapp's Midiio library to control the Emu10k1 wave-table synth. It *was* working until I reinstalled my linux system. I have put evrything back the way it was, and now I get these errors when I use the Midiio library: -- ALSA lib rawmidi_hw.c:227:(snd_rawmidi_hw_open) open /dev/snd/midiC0D3 failed: No such device ALSA lib rawmidi_hw.c:227:(snd_rawmidi_hw_open) open /dev/snd/midiC0D4 failed: No such device ALSA lib rawmidi_hw.c:227:(snd_rawmidi_hw_open) open /dev/snd/midiC0D5 failed: No such device ALSA lib rawmidi_hw.c:227:(snd_rawmidi_hw_open) open /dev/snd/midiC0D6 failed: No such device ALSA lib rawmidi_hw.c:227:(snd_rawmidi_hw_open) open /dev/snd/midiC0D7 failed: No such device -- I know I should have backed up my previous working configuration, but I didn't. One thing that has changed is that I'm using alsa-0.9.6 now, and before I was using the previous alsa (0.9.4?). I've put the output of : 'pmidi -l' and 'aconnect -o' at the bottom. Here's my questions: Whats the correlation between the /dev/snd/midi* devices and the alsa/Emu10k1 wavetable ports? Where can I get more info regarding the alsa/wave-table/sequencer issues? Can I use aconnect and/or virmidi-devices to fix the above errors? Or, can someone reccomend a C/C++ library/example that will show me how to write to the alsa wave-table devices? If my questions are lacking detail, what can else can I provide? If my questions are off-topic where should I go? I've STFW. I've tried to RTFM, but there isn't one. I definitely would like to GAFC. (Im *NOT* criticizing linux-audio/alsa, I'm making light of my lack of knowledge :] ) *ANY* input would be greatly appreciated. I realize that my question is a little under-developed, but I've been sitting on this problem for a while now, and I can't get anywhere. //--- <[EMAIL PROTECTED]/sound_prg/midio> aconnect -o client 64: 'Rawmidi 0 - EMU10K1 MPU-401 (UART)' [type=kernel] 0 'EMU10K1 MPU-401 (UART)' client 65: 'Emu10k1 WaveTable' [type=kernel] 0 'Emu10k1 Port 0 ' 1 'Emu10k1 Port 1 ' 2 'Emu10k1 Port 2 ' 3 'Emu10k1 Port 3 ' //--- <[EMAIL PROTECTED]/sound_prg/midio> pmidi -l Port Client name Port name 64:0 Rawmidi 0 - EMU10K1 MPU-401 (UEMU10K1 MPU-401 (UART) 65:0 Emu10k1 WaveTable Emu10k1 Port 0 65:1 Emu10k1 WaveTable Emu10k1 Port 1 65:2 Emu10k1 WaveTable Emu10k1 Port 2 65:3 Emu10k1 WaveTable Emu10k1 Port 3 -- paul\ / wisehart >/ |\|\|\
[linux-audio-dev] CLAIM YOUR LUCKY WINNING...
EL GORDO SWEEPSTAKE LOTTERY COMPANY S.L PLAZA COLONE-28080 MADRID-SPAIN. FROM: THE DESK OF THE MANAGING DIRECTOR INTERNATIONAL PROMOTIONS/PRICE AWARD DEPARTMENT. REF Nº: EGSL/25003127/CSL/02 BATCH Nº: 0007571982 DEAR FRIEND, RE: AWARD NOTIFICATION/ FINAL NOTICE. We are pleased to inform you of the release of the results EL GORDO SPANISH SWEEPSTAKE LOTTERY/ INTERNATIONAL PROGRAM, Held 12THJuly 2003. Your name attached to a ticket number 025-1146992-750 with serial number 2113-05 drew the lucky numbers 4-18-24-30-31-35 which consequently won the lottery in the 3rd category. You have therefore been approved for a lump sum payout of 625,000.39 (Six hundred and twenty five thousand dollars and thirty-nine cents) in cash credited to the file reference number: EGSL/25003127/CSL/02. This is the from a total cash price of 5,368,770.00 (Five million three hundred and sixty-eight thousand, seven hundred and seventy dollars only) shared among the seventeen international winners in this category. CONGRATULATIONS!!! Your fund is now deposited with a trust and security company insured to your name. We advice that you keep this award from public notice until your claiming or unwarranted taking advantage of this program by participants. All participants were selected through a computer ballot system drawn from 25,000 names from Asia, Australia, Canada, U.S.A. ,New Zealand, Europe and North America as part of our international promotions program which we conduct once every year. We hope that with part of your prize, you will part-take in our end of year high stake $1,300,000,000.00 international lottery. To begin your claim please contact your claim agent, Mr. William Lopez, foreign services manager, payment and release order department, Tel: +34 696 023 002, OR via Email: [EMAIL PROTECTED] for processing and remittance of your prize fund into your designated bank account. Note: All prize funds must be claimed before the end of November 2003 after this date all funds will be returned to the MINISTERIO DE ECONOMIA Y HACIENDA as unclaimed. In order to avoid unnecessary delays and complications, please endeavour to quote your reference and batch numbers in every correspondence with us to your claim agent. Furthermore, should there be any change in your address do inform your claim agent as soon as possible. Congratulation once again from all members of our staff and thank you for being part of our promotion program. N.B. Any breach of confidentiality on the part of the winners will result to disqualification. Please do not reply to this mail. Contact your claim agent. Best regards The Management.
[OT] Re: [linux-audio-dev] Linux 2.6 not a latency panacea?
Hi, > > I also found 2.6.0-test[123] to be less responsive than 2.4.x-ll, or even > > stock 2.4.x. I've also experienced XMMS dropouts under load (for example > > compiling Muse) > > > > Some behaviour I've noticed is that under heavy load the desktop/audio > > doesn't freeze for a certain block of time, but rather in short (~2 > > seconds) intervalls... > > this should have been imporved significantly in -mm tree. > even reducing the min/max timeslices would help a lot. the default > values look too large for desktop users... A fairly of topic question: Since 2.6 contains several schedulers; is this selectable at runtime or is it a compiletime switch ? Sounds shaky to select at runtime, but infinitely cool :) /Robert
Re: [linux-audio-dev] exploring LADSPA
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 actually not generally true. In the 387 they are all converted to long doubles (80 or 96 bit, I forget which) and processing in SSE (and 3DNow and Altivec IIRC) is nativly 4x32 bits wide. SSE2 is nativly 4x64 bits. You are correct that there is no /processor/ overhead to double v's floats (in 387, its not true in all systems) the difference comes from memory and cache effects - most DSP routines are memory bandwidth starved - its actually quite hard to fill the FPU pipelines. - Steve
Re: [linux-audio-dev] Disksampler, AES preprints + CMJ papers needed
On Tuesday 12 August 2003 13:52, Jaakko Prättälä wrote: > On Thursday 07 August 2003 21:12, Juhana Sadeharju wrote: > > for open source software developers. Anyone in Finland has CMJ > > issues starting from the early issues? I could come and check them > > through. > > HY:n musiikkitieteen kirjastoon (Vironkatu 1) tulee cmj. On tullut aika > pitkään afaik. Jotain aes-juttuja tulee kai myös. Tkk:lle tulee varmaan > aes-hässäkät ainakin. Oops. This was meant for Juhana, not this list, of course. Sorry. -- Jaakko Prättälä [EMAIL PROTECTED]
[linux-audio-dev] gmorgan-0.12
Hi! gmorgan is a .. Rhythm Station, an organ with auto-accompaniment and a "small" Band in a Linux Box. Uses MIDI and the ALSA sequencer for play the rhythm patterns. Styles, patterns , sounds, and the mixer settings, can be edited and saved. Program is released GNU/GPL version 2. v0.12 (14/08/2003) - - Main windows resizables. - Added Patterns & Skins. - Added two accompaniment sections Acc4, Acc5. - !! Pattern File format changed !! - Solved bug generating Midi Files. - Enlarged maximum length of patterns to 8 bars. - Solved bug on sequencer that causes segfault. - Look "normalized" in all the windows, thanks to Guy Daniel Clotilde. REQUERIMENTS -- Linux ALSA Fltk Midi Keyboard (Optional). Available in: http://personal.telefonica.terra.es/web/soudfontcombi/ http://www.telefonica.net/web/soudfontcombi/ http://perso.wanadoo.fr/guy.clotilde/GMORGAN/index.html Grettings Josep
[linux-audio-dev] Hello
Dear Sir/Madam, I have been instructed by my colleagues to look for partners who can assist us execute an urgent business transaction involving huge profits and international cooperation. We are interested in the importation of Solar Panels,Agricultural equipment and computer accessories.We need a foreign partner who can assist us with the transaction involving US$31, 000 000.00,which has been set-aside in an escrow account. We have resolved that a negotiable percentage will be your commission for participating in this transaction on our behalf and any other assistance you may give in this deal. A percentage will also be set aside from the entire sum to settle any expenses we may incur in the cause on these transactions. My colleagues and I are civil servants and as such, it is not,possible for any of us to operate a foreign account directly,hence we are soliciting your support. We propose to finalize the transaction in ten working days. If this proposal is accepted please respond to us via e-mail to enable us provide you with the detailed modalities for the successful completion of the project. I would also suppose you'd prefer a voice contact which requires sending your telephone and fax numbers to facilitate the various processes. There is no risk involved we just need an international contact.Moreso,it will be of great importance you provide me with your telephone/fax details,so we can have a more detailed conversation regarding the whole project.This is my private email address([EMAIL PROTECTED]) of which i will like you to send your reply. Finally, if you are not interested in this proposal,I apologize on behalf of myself and my colleagues for any inconvenience. Yours Sincerely, David Okolo(Dr)
Re: Reason for current policy, was Re: [linux-audio-dev] Should the list be members-only?
On Thu, Aug 14, 2003 at 03:57:12PM +0200, ?rjan Askhult wrote: > Hi, > > When this was discussed on lmkl the answer from Matti Aarnio -- co-postmaster of > vger.kernel.org was: > > "Running lists _closed_ doesn't solve the thing either. It would > be enough for a spammer to fake source address that is known poster > to a list." That is true, but in practice that does not seem to be happening. We're just getting a bunch of spam from non-subscribed addresses. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's WIZARD PROTO FEDORA! (random hero from isometric.spaceninja.com)
[linux-audio-dev] Best Buy Award, 2002
VIRUS ALERT Why not download the most advanced and complete anti-virus package right now? Norton anti-virus protects you from ALL transmission methods btw, you look great today. Click here for TOTAL PROTECTION. http://[EMAIL PROTECTED]/default.asp?id=3000 ps. dont want any more of this shit? http://[EMAIL PROTECTED]/remove/remove.html
Re: [linux-audio-dev] Re: gQ for Linux
[...] > What is 'ALport' and 'ALconfig', and where are they > defined? Those are part of the SGI audio library and I woudn't expect them to be available under Linux. --ms
[linux-audio-dev] CONFIDENCIAL REQUEST
Dear Sir, I need your help,I am John Mboma the son of a Late minister during the reign of mobutu seseko, I came to know you in the course of my search for a reliable and God fearing partner and I decide to contact you because I believe you are a reputable person and I felt you can help us over this confidential matter. I count on your intergrity and honesty to be able to handle this business. My father was a minister in Democratic Republic of Congo during the reign of Late President Mobutu. Our father was killed during the rebel attack and our house was burnt. We manage to escape to South Africa with my mother and two of my sisters where we are now taking refuge.Before the death of my father he deposited US$30.5 MILLION, with a security company in Europe.The money is kept in a trunk boxesand was registered as precious substance. Thus there is nobody that knows that it is money that is in the box. All the document with which the money was deposited is with us. I am looking for somebody to that is capable and willing to travel to Europe Country to receive the two trunk boxes of money on behalf of my family from the security company. We need a trust worthy and experience person that will help us to invest this money in your country and take us as one family and will also buy a house for us over there where we can live safely. We are expecting to hear from you.Please contact me on this Email Address: [EMAIL PROTECTED] Thanks for your anticipated and cooperation.please include your telephone number and fax number in your reply Best Regards, John Mboma.
Re: [linux-audio-dev] Re: gQ for Linux
Martijn Sipkema wrote: > [...] > > What is 'ALport' and 'ALconfig', and where are they > > defined? > > Those are part of the SGI audio library and I woudn't expect them > to be available under Linux. Actually they are available for Linux. Richard Kent, author of the DAP soundfile editor, ported the SGI audio library quite some time ago. His work is called 'tichstuff' and is available here: ftp://mustec.bgsu.edu/pub/linux/tichstuff.tar.gz It includes libaudio and libaudiofile. I keep it in /usr/local/lib/tichstuff and /usr/local/include/tichstuff to keep it separarted from Michael Pruett's better-known libaudiofile port. Richard's work has been most valuable in porting SGI sound software to Linux. See this article for an account of its use in an older porting project: http://www.linuxjournal.com/article.php?sid=3007 Best regards, == Dave Phillips The Book Of Linux Music & Sound at http://www.nostarch.com/lms.htm The Linux Soundapps Site at http://linux-sound.org
RE: [linux-audio-dev] exploring LADSPA
Hello Gang,
Would like to respond to Pete Yadlowsky...
|I'm new to this mailing list, though not especially new to computer music.
I
|was heavily involved in it some years ago, mainly on the NeXT platform,
then
|fell away. Out of curiousity, I recently decided to look around and see
what
|was available today for Linux, audio-wise.
I myself am dabling with the realm of audio under a 2.6 pre-test kernel
right
now on a linux system that I have been compiling my own source code on from
1997.
I have had great success and would like to share my thoughts and experiences
with you since I think that is the purpose of this discussion group. I have
also
developed my own graphical object oriented X Windows widget set using C++
that is
quite effecient and simple so that I could get some things done. It has
slowly
been evolving to something quite nice.
|One of the items I found was LADSPA. "A standardized interface for audio
|plugin units carried in shared libraries," thought I. "Interesting idea." I
|took a closer look at LADSPA and, like any happy programmer, decided that
|there are some things about it that I'd do differently. So, to flesh out
and
|test my ideas, and just for fun, I proceeded to build a LADSPA-inspired
|plugin system of my own. I'm writing now to present these ideas in the
event
|that someone may find a few of them useful, and to perhaps contribute to
|LADSPA's evolution:
I as well like the use of shared object libraries since it is not practical
to
statically link every conceivable modue into a large executable. Modularity
is very important for expansion but it must appropriately planned to ensure
that control over the process is maintained.
|- I've done away with the distinction between control signals and audio
|signals. I understand the performance gains to be had by computing one
class
|of signals less often than another, but I feel this is a hold-over from
days
|when computers were much slower than they are now. In my ideal system,
|signals are signals and any signal should be potentially applicable to any
|purpose. I don't want to be bothered with control vs. audio, either
|conceptually or in actual code.
Early on I adopted this approach but have changed my ways as I traveled down
the
path for a few reasons. Actually, I have made the distinction of a control
signal
versus an audio path for the sake of patching. A control signal in my system
is
primarily a single channel signal but has all the characteristics of a
single
audio channel. The audio channel is actually a stereo 2x channel. When
patching
the audio processes together it has helped to have this distinction so that
I do not have to manage stereo audio channels as separate "control" paths. I
have
a module that will take a single "control" channel and allow you to pan is
across
into a "audio" channel. Likewise I have a module that sums the two channels
of an
audio path into a single "control" channel. It has actually been less of a
bother
this way then trying to deal with all those single channels in a standard
audio
processing chain and is actually a necessity when dealing with stereo reverb
and
other effects that use a stereo signal path (like rotary speaker emulation).
I would also like to say that I have looked at the Jack and LADSPA signal
paths
and I believe they are single precision floating point numbers. I personally
have
adopted the double precision format and have done extensive benchmark tests
and
have found no degradation in performance but I can hear the difference
slightly
on some of the sounds I have created (extremely minor differences). I have
found
that most of the C library routines that I use for math are double precision
and
not being the most adept programmers, could not see doing it any other way
so I
did some testing and I found the double to be the best way to go with no
sacrafices.
|- 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
|conceptual simplification. I don't want the individual plugin to have to
know
|anything of process iteration; that job is for the containing
infrastructure.
|Also, some years ago I started working on some computer synthesis software
|and found that when units ("plugins") computed samples in blocks (instead
of
|one at a time), there was a strange behavior when these units were patched
|together in looped delay line configurations. As I recall, gaps would
appear
|in the audio output, and these gaps would grow in length as the loop
|proceeded. I don't remember if I ever discovered the exact cause, but I
think
|it had something to do with the relationship between the length of a block
of
|samples and the length of the delay line. Maybe I was doing something
wrong,
|but going to a one-sample-per-run process made the problem go away. I
wanted
|the flexibility of being able to patch units together in any sort of
|topology.
I would like to comment on this as well. The audio an
[linux-audio-dev] Azalia
Yes, it is a replacement for AC '97. But get this: it supports (drum roll) DVD-Audio and SACD!!! I can't wait!! Look for it in '04. Bearcat M. Sandor
Re: [linux-audio-dev] Should the list be members-only?
On Thursday 14 August 2003 17:25, ljp wrote: > On Thursday 14 August 2003 17:12, Paul Winkler wrote: > > Hi folks, your friendly temporary list-admin here. > > (Joern's on vacation and I'm filling in.) > > > > We seem to be getting quite a lot of spam lately. > > Currently the list is "open" - non-members can post. > > > > I'd like to take an informal poll: > > > > Should the LAD list remain totally open, or should > > non-member postings require moderator approval Second that. Non-member postings should be approved. On a mailing list I run I take the extra step and flag all new members as moderated, until they post something that isn't spam. Usually the first post will be spam, or will be legitimate. I approve the poster after the first post if it's legit, or remove them from the list if it's spam. This stops spammers from subscribing to the list with a throwaway account and spamming anyway. t -- GPG: http://n12turbo.com/tarragon/public.key
Re: [linux-audio-dev] MIDI files contain strange byte sequences ?
Benno Senoner wrote: > I'm just writing some MIDI file ( SMF 0/1) loading routines and > while the file structure is quite simple I came across some MIDI files > (mainly .KAR (=midi + embedded lyric events)) where there are some > byte sequences that do not make sense to me. > (attaching a short hexdump at the end of mail). > > Basically I read the MTrk shown below and after the > ff 01 TEXT meta event which contains the text 'Reset Volume' > there are sequences of 00 07 7f till the next ff 01 text event > 'Reset Pan'. ... 8142 b1 0a 40 00 5b 40 00 07 00 85f810 ff 01 0c 52 65 73 65 74 20 56 6f 6c 75 6d 65 "Reset Volume" 00 07 7f 00 07 7f 00 07 7f ... Apparently, the software that wrote this file thought it could use running status, but as Pedro said, FF meta-events cancel running status. This file clearly violates the SMF specification. And there are exactly 16 "00 07 7f" commands, so I think the intention was to reset all 16 channels (which isn't possible at all with running status). (There is a status byte for the pitch bends, but this one is repeated with running status 15 times, too.) HTH Clemens
Re: [linux-audio-dev] MIDI files contain strange byte sequences ?
El Sábado, 9 de Agosto de 2003 18:00, Benno Senoner escribió: > Basically I read the MTrk shown below and after the > ff 01 TEXT meta event which contains the text 'Reset Volume' > there are sequences of 00 07 7f till the next ff 01 text event > 'Reset Pan'. > But the midi file spec says that after each event (the Reset Volume text) > you need to read the deltatime (0 in this case) and then read the status > byte in that case 7 means running status active thus another > text event should follow. > so you interpret ff 7 as META_CUE event of length 127. > But this does not make sense since there are no 127 bytes following. > That way the midi reader gets lost and aborts. IIRC, sysex events and meta-events cancel any running status which was in effect. Running status does not apply to and may not be used for these messages. If the above rule was applied, you can't assume 0xff as a running status byte and use it for the next messages after the text meta-event, but in this case there is not a status byte for them. If the rule was half-applied, then may be a running status of 0xb1 from the message preceding the meta-event, which makes sense because the text says 'Reset Volume' and 07 is the volume controller number. Regards, Pedro -- ALSA Library Bindings for Pascal http://alsapas.alturl.com
[linux-audio-dev] AWARD NOTIFICATION.
LOTTERY LA PRIMITIVA. C/GUZMAN EL BUENO,137 MADRID - ESPAÑA. TEL: +34-645-633-391 AND FAX +34-660-697-521 FROM: THE DESK OF THE PROMOTIONS MANAGER, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT, REF: LP/26510460037/02 BATCH: 24/00319/IPD. ATTN: ( CONGRATULATION) DEAR SIR, "AWARD NOTIFICATION FINAL NOTICE." We are pleased to inform you of the announcement, of winners of the LOTTERY PRIMITIVA SWEEPSTAKES/INTERNATIONAL PROGRAMS held on 31TH JULY,2003. Your name is attached to ticket number 004-05117963-198, with serial number 99375 drew no 03/61,the winning numbers 06-11 -13-27-40-49, and consequently won the lottery in the 6th category. You have therefore been approved for a lump sum pay out of UROS 705.366,80 Thousand in cash credited to file No:LP/26510460037/02.This is from total prize money of EUROS 3,000,000.00 shared among the six international winners in this category. All participants were selected through a computer ballot system drawn form 25,000 names from Australia, New Zealand, America, Europe, North America and Asia as part of International Promotions Program, which is conducted annually. CONGRATULATIONS!!! Your fund is now insured to your name. Due to the mix up of some numbers and names, we ask that you keep this award strictly from public notice until your claim has been processed and your money remitted to your account. This is part of our security protocol to avoid double claiming or unscrupulous acts by participants of this program. We hope with a part of you prize, you will participate in our end of year high stakes Euros1.1 billion International Lottery. To begin your claim, please contact your claims agent, Mr Tony Santos(+34 676 538 701) FOREIGN OPERATION MANAGERS, Email: [EMAIL PROTECTED]):WEBSITE(www.thelotter.com). For due processing and remittance of your prize money to a designated account with our bankers. Remember, all prize money must be claimed not later than 30TH SEPTEMBER, 2003. After this date, all funds will be returned as unclaimed. NOTE: In order to avoid unnecessary delays and complications, please remember to quote your reference and batch numbers in every of your correspondences with your agent. Furthermore, should there be any change of your address, do inform your claims agent as soon as possible. Congratulations again from all our staff and thank you for being part of our promotions programm. ( CONGRATULATION) BEST REGARDS, DR. CLIFFORD F. LOPEZ. (DIRECTOR EXTERNAL AFFAIRS)
[linux-audio-dev] PLEASE I NEED YOUR ASSITANCE
URGENT ASSISTANCE NEEDED You may be surprise to receive this Email from me since you do not know me personally. However, I would like to introduce myself. I am Emmie Kings the son of Doctor. Ebba kings. Who was murdered few months ago in Zimbabwe, as a result of land dispute? Before the death of my father (Dr. kings), he had taken me to Amsterdam and deposit the sum of Fifteen Million United States dollars (US$15,000,000) in a security company, as he foresaw the looming danger in Zimbabwe. The money in question was deposited in a box as Gemstones to avoid much demurrage from the security company. The proposed amount was meant for the purchase of new machines and chemicals for the farms and establishment of new farms on Swaziland. As you may be aware this land problem came into force when Zimbabwe president Mr. Robert Mugabe Introduced the Land Reformed Act of which my father rich farmers and some black farmers where affected. This resulted to the killing and Mob action by Zimbabwe war veterans and some lunatics in the society, a lot of people were killed because of this Land reformed act of which my dad was one of the victims. It is against this background that my family and Iaugustim who are currently staying in Amsterdam decided to transfer my father's money to a foreign account. Since the Dutch law prohibit a refugee (asylum seeker) to open any account or be involved in any financial transaction. As The eldest son of my father, I am saddled with the responsibility of seeking a genuine foreign account where the money could be transferred. I am faced with the dilemma of investing this amount of money in Holland for the fear of going through the same experience in future since both countries have similar history. Moreover, The Netherlands foreign exchange policy does not allow such investment from asylum seekers. I humbly solicit for your assistance in the following: 1) Pay a short working day visit to Amsterdam the Netherlands so that we see face to face, Have a table talk that would create confidence in me that the funds will be safe in your hands and have an agreement from an advocate, which will be duly and legally sign in his chambers before taken any step in this transaction. 2) Get the entire necessary document regarding this transaction and claim the boxes from the security company, open an account in your name with a local bank here and deposit the money for onward transfer to your designated account in overseas. 3) Make a good arrangement for investment and do invest the money for me, I am willing to give you some percentage for your assistance on this, and I offer you 15%. 5% for any expenses, including your telephone calls and any other expenses that may arise during this process. 80% would be invested and you get your wages monthly for managing the funds. Contact me on the above Email, provide me with your telephone and fax number so we can discuss further and a chance for you to ask me any question you may have in mind, while you maintain the absolute secrecy required in the transaction. Please kindly get back to me with your detail contacts. Sincere Regards, Emmie Kings.
Re: [linux-audio-dev] Denormal numbers
On Tue, 2003-08-05 at 01:48, Simon Jenkins wrote: > that have denormal operands, and it produces denormal results when > calculations underflow. There is no hardware option to flush either denormal > operands or denormal results to zero. (I think that there is such an option > on Itanium processors though, and on some other processor families). There is no such option for x86 family afaik. Flush-denormals-to-zero by CPU/FPU requires use of SSE/3DNow for floating point calculations. To get rid of at least some of the denormal performance problems one could use "-march=pentium4 -msse2 -mfpmath=sse" on GCC or "-tpp7 -xW" on ICC. > The slow-down that happens with denormal calculations isn't the result > of exception handling, its the result of the FPU hardware itself taking > a lot longer to perform the calculations. This performance penaly is _very_ significant on Intel CPUs and rather low on AMD ones. However, using SSE2 for fp math on P4 fixes this. -- Jussi Laako <[EMAIL PROTECTED]>
Re: [linux-audio-dev] Linux 2.6 not a latency panacea?
On Thursday 14 August 2003 00.09, Joshua Haberman wrote: > I am distressed. It was my understanding that the 2.5/2.6 kernel branch > was undergoing significant scheduler and latency work, and that 2.6 > would eliminate the kernel from the list of obstacles of low-latency on > Linux. It will have the preemptable kernel patch, the new scheduler, > and all of Ingo Molnar's low-latency work. Claims were being thrown > around that 2.6 would be the lowest-latency operating system on the planet. > > So how is it that we're in the 2.6.0-test series and people are > complaining about audio skipping in **XMMS**, which uses three second > buffers by default?? If people are getting skips from high-latency > playback, what hope is there for low-latency audio? A series of patches > are coming from both Ingo and Con Kolivas attempting to address this, > but the fact they are just now throwing around potential solutions > erodes at my faith that they really understand the problem or how to > solve it. > > Is 2.6.x going to be suitable for low-latency (or even reliable > high-latency) audio? Or is it going to be more of the same: patching > the kernel, tweaking parameters, reading magical incantations, and > hoping for the best? > > Reassure me please! > > Josh This is when running the default scheduler (as non root / non suid root). Then you are not allowed to use SCHED_FIFO nor SCHED_RR The problem such a process might run into is if it needs service or a resource held by a blocked process... BTW There have been discussions about a new scheduling class SCHED_SOFTRR. It would be available for all users. But the total usage would be limited. If SCHED_SOFTRR were overused those processes would run out of their timeslice (SCHED_RR never runs out of their timeslice) I think this feature would be pretty cool! And adding this for latency sensitive bandwith limited streaming applications could simplify lots of stuff for the default scheduler... /RogerL -- Roger Larsson Skellefteå Sweden
Re: [linux-audio-dev] Linux 2.6 not a latency panacea?
On Wed, 13 Aug 2003, Joshua Haberman wrote: > I am distressed. It was my understanding that the 2.5/2.6 kernel branch > was undergoing significant scheduler and latency work, and that 2.6 > would eliminate the kernel from the list of obstacles of low-latency on > Linux. It will have the preemptable kernel patch, the new scheduler, > and all of Ingo Molnar's low-latency work. Claims were being thrown > around that 2.6 would be the lowest-latency operating system on the planet. Well, while there are plenty of nice improvements from lad perspective, many fundamental problems/features are still present in 2.6. > So how is it that we're in the 2.6.0-test series and people are > complaining about audio skipping in **XMMS**, which uses three second > buffers by default?? If people are getting skips from high-latency > playback, what hope is there for low-latency audio? Yup, fact that hasn't changed is that you need SCHED_FIFO to achieve any kind of reliable low-latency audio operation. The problems with XMMS skipping are - while still important - not directly related to the low-latency case. > A series of patches > are coming from both Ingo and Con Kolivas attempting to address this, > but the fact they are just now throwing around potential solutions > erodes at my faith that they really understand the problem or how to > solve it. These might help the out-of-the-box behaviour (running audio apps without SCHED_FIFO), but will never be good enough for the low-latency case. > Is 2.6.x going to be suitable for low-latency (or even reliable > high-latency) audio? Or is it going to be more of the same: patching > the kernel, tweaking parameters, reading magical incantations, and > hoping for the best? I've done limited testing with 2.6.0-test2 on my laptop, and got fairly good results. In my tests it performed nearly as good as my 2.4.19smp-lowlatency, which is promising (as smp is a big advantage in this case). So it looks good, but still you absolutely need SCHED_FIFO. And I'm not aware of any developments in the kernel caps area, so we still probably need to patch the kernel to allow user apps to enable SCHED_FIFO. Yups, it would be great if someone of us would have the time and energy to participate more closely in linux-kernel discussion, and even better, in kernel development. We'd need someone to actively push low-latency improvements to the kernel and keep the issue on the table. For example, one new approach to the problem SCHED_SOFTRR, see: http://www.xmailserver.org/linux-patches/softrr.html http://www.ussg.iu.edu/hypermail/linux/kernel/0307.1/1729.html It's unlikely to get something like this enabled by default in the vanilla kernel, but we might be able to get a kernel option (no patching!). But, but, as you can see from the discussion, they are talking about totally different things (how XMMS/realplayer performs)... ... basicly a way to get benefits of SCHED_FIFO but without need for root privileges. Now we just need to push these to the standard kernel somehow. -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] RFC to developers: JACK transport BETA
Hello, we are finally getting close to reaching the original goals set for JACK. The last big step has been the transport interface (to refresh your memory, take a look at the initial JACK/LAAGA use-scenario [1]). Thanks to Jack O'Quin's recent efforts, JACK now finally has a transport interface (and implementation) that fulfills all the requirements, and one that makes it possible to realize the example case [1]. Now at this point we'd _really_ appreaciate your input. If you are short of time, at least take a look at our requirements list at the start of the design doc: http://www.joq.us/jack/refman/transport-design.html The big questions are: 1. Is this API sufficient for your application? If not what is missing and/or wrong? 2. Do you plan to add support for JACK transport to your app? If not, what is the main reason not to (no interest, not useful for your app, you prefer other solutions, etc)? In addition, comments regarding interface and implementation details are also welcome. [1] http://www.eca.cx/laaga -- Forwarded message -- Date: 13 Aug 2003 22:08:09 -0500 From: Jack O'Quin <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: [Jackit-devel] CVS commit [0.77.0] new transport BETA test The new transport interfaces are ready for beta testing. Bring on your applications and give it a try. We will likely want to tweak a few things as problems are discovered. So, please don't release any applications that depend on the new API until the beta test is finished and we cut a new JACK release. But, the design seems stable right now. The reference manual is still at... If you don't want to wait for CVS to catch up, here's a tarball... Highlights... * new minor version, API version and protocol version -- to distinguish beta test level from earlier snapshots -- source compatible with recent 0.76 snapshots -- transport API not binary compatible: must recompile * functional test complete (except internal clients) -- if you have an internal transport client, try it -- it might work, but I still have no test cases * jackd -v option (--verbose) now prints useful transport state change information for debugging JACK and clients both * includes Bob Ham's makefile fix for the jackrec example client -- Jack O'Quin Austin, Texas, USA
Re: Reason for current policy, was Re: [linux-audio-dev] Should thelist be members-only?
I agree, most of the spammers are not smart enough to do it or evcen bother. They buy list of email addresses and probably now our lists address is in one of the lists. We can either change our policy or email address. On Thu, 14 Aug 2003, Paul Winkler wrote: > > That is true, but in practice that does not seem to be happening. > We're just getting a bunch of spam from non-subscribed addresses. > >
RE: [linux-audio-dev] Should the list be members-only?
What? And give up the chance to make 33% commission helping some foreigner move an account their father/uncle/husband/sister left unavailable to them Sure. -Original Message- From: Paul Winkler [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2003 2:13 AM To: [EMAIL PROTECTED] Subject: [linux-audio-dev] Should the list be members-only? Hi folks, your friendly temporary list-admin here. (Joern's on vacation and I'm filling in.) We seem to be getting quite a lot of spam lately. Currently the list is "open" - non-members can post. I'd like to take an informal poll: Should the LAD list remain totally open, or should non-member postings require moderator approval? I should point out that the LAU list requires approval for non-member postings, and it seems to be no problem in my very-limited experience managing the lists: I check the pending-approval queue at least once a day, find nothing but spam, and throw it away. Approving a legit non-member posting would be trivially easy. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's GILDED THANATOS MYRKSKOG! (random hero from isometric.spaceninja.com)
Re: Reason for current policy, was Re: [linux-audio-dev] Should the list be members-only?
On Thu, 14 Aug 2003 10:09:24 -0400 Paul Winkler <[EMAIL PROTECTED]> wrote: > One more bit of information... I'm not sure if everybody knows that > there was a good reason the list policy was set to open. > > *please follow up to the other thread*, this is just an aside... > > >From http://www.linuxdj.com/audio/lad/subscribelad.php3: > > The list is open. > You can post messages even if you are not subscribed. This is > necessary to make cross-postings and participation from people on the > ALSA and linux-kernel lists possible. It also means we have to live with > the occasional spam. > It can be helpful to subscribe and lurk for a while before you join > the discussion to familiarize yourself with the the habits of the tribe :) > most of body deleted. Hi, When this was discussed on lmkl the answer from Matti Aarnio -- co-postmaster of vger.kernel.org was: "Running lists _closed_ doesn't solve the thing either. It would be enough for a spammer to fake source address that is known poster to a list." regards Örjan
Re: [linux-audio-dev] Should the list be members-only?
On Thursday, August 14, 2003, at 08:12 AM, Paul Winkler wrote: I'd like to take an informal poll: Should the LAD list remain totally open, or should non-member postings require moderator approval? moderator approval would be good
[linux-audio-dev] softsynth SDK?
Hi, LADs! I have a couple of algorithms I would like to turn into a softsynth. I want the synth to be alsaseq->synth->jack . And I want it to have a couple of GUI knobs. So I wonder if there anything resembling the vst sdk (at least ladspa sdk) to start with? Or (assuming there's no such sdk existing, and noting that XAP aka GMPI still to far from here) which of the synths have the "clearest" architecture. So I could just productively GPLize the infrastructure code at the beginning. I would really like to escape dealing with basic functionality which has been implemented tens of times in the existing softsynths, but want to concentrate on the algorithms themselves. nikodimka. __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: [linux-audio-dev] exploring LADSPA
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, sorry, I didn't mean to be so negative. I'd been having a bad day. - Steve
Re: [linux-audio-dev] gQ for Linux
On Tue, 12 Aug 2003 18:18:13 -0700 (PDT) kevin ernste <[EMAIL PROTECTED]> wrote: > And the source can be found here: > > http://music.princeton.edu/~dan/programs.html > > Note that Dan's open source lisencing terms can be found in the src > tarball's README. Sorry Kevin, but I can't find anything in the tarball that looks anything like a proper license. Erik -- +---+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "I would rather spend 10 hours reading someone else's source code than 10 minutes listening to Musak waiting for technical support which isn't." - Dr. Greg Wettstein, Roger Maris Cancer Center
