Re: [LAD] hard realtime performance synth
Which is interesting. I did not notice on my ASUS laptop any significant difference between rt-kernel and a normal one. It was there - a bit less dropouts, but the change was not significant, meaning that my non RT kernel mode works almost as good. On Wed, Jan 27, 2010 at 9:47 AM, David Olofson wrote: > On Tuesday 26 January 2010, at 21.15.43, David McClanahan > wrote: > [...] > > 3. I'm a little worried about what some are calling realtime systems. The > > realtime system that is part of Ubuntu Studio and others may be more > > preemptible than the normal kernel(as in kernel calls themselves can be > > preempted), but that's not a hard realtime system. A hard realtime > > system(simplistic I know) might entail a task whose sole job is to pump > out > > a sinusoidal sound sample to the D-to-A on the sound card. A hard > realtime > > scheduler would run that task at 44Khz no matter what. This would entail > > developing code that when the machine instructions were analyzed, would > run > > in the time constraints(aka the 44Khz). RTLinux appears to be suitable > and > > RTAI might be. Perhaps others. > > The relevant definition of "hard realtime system" here is "a system that > always responds in bounded time." That bounded time may be one microsecond > or > one hour, but as long as the system can meet it's deadline every time, it's > a > hard realtime system. The definition doesn't really imply any specific time > frames. > > Now, in real life, the "every time" part will never be quite accurate. > After > all, you may see some "once in a billion" combination of hardware events > that > delays your IRQ a few microseconds too many, or your lose power, or the > hardware breaks down, or a software bug strikes... There are countless > things > that can go wrong in any non-trivial system. > > Of course, there's a big difference between a DAW that drops out a few > times a > day, and one that runs rock solid for weeks - but a truly glitch-free > system > would probably be ridiculously expensive, if it's even possible to build. > Triple redundancy hardware, code verified by NASA, various other things > I've > never even thought of; that sort of stuff... > > As to the 44 kHz "cycle rate" on the software level, although possible, is > big > waste of CPU power on any general purpose CPU, as the IRQ and context > switching overhead will be quite substantial. Further, even the (normally > irrelevant) worst case scheduling jitter starts making a significant impact > on > the maximum safe "DSP" CPU load. (Double the cycle rate, and the constant > jitter makes twice the impact.) > > Therefore, most low latency audio applications (whether on PCs/workstations > or > dedicated hardware) process a bunch of samples at a time, usually somewhere > around one millisecond's worth of audio. This allows you to use nearly all > available CPU power for actual DSP work, and you don't even need to use an > "extreme" RTOS like RTAI/LXRT or RT-Linux to make it "reasonably reliable". > > With a properly configured "lowlatency" Linux system on decent hardware (as > in, no BIOS super-NMIs blocking IRQs and stuf; raw performance is less of > an > issue), you can probably have a few days without a glitch, with a latency > of a > few milliseconds. > > I haven't kept up with the latest developments, but I remember > stress-testing > the first generation lowlatency kernels by Ingo Molnar, at 3 ms latency > with > 80% "DSP" CPU load. Hours of X11 stress, disk I/O stress, CPU stress and > combined stress, without a single drop-out. This was back in the Pentium II > days, and IIRC, the fastest CPU I tested on was a 333 MHz Celeron. Not > saying > this will work with any lowlatency kernel on any hardware, but it's > definitely > possible without a "real" RT kernel. > > > -- > //David Olofson - Developer, Artist, Open Source Advocate > > .--- Games, examples, libraries, scripting, sound, music, graphics ---. > | http://olofson.net http://kobodeluxe.com http://audiality.org | > | http://eel.olofson.net http://zeespace.net http://reologica.se | > '-' > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev > ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] hard realtime performance synth
On Tuesday 26 January 2010, at 21.15.43, David McClanahan wrote: [...] > 3. I'm a little worried about what some are calling realtime systems. The > realtime system that is part of Ubuntu Studio and others may be more > preemptible than the normal kernel(as in kernel calls themselves can be > preempted), but that's not a hard realtime system. A hard realtime > system(simplistic I know) might entail a task whose sole job is to pump out > a sinusoidal sound sample to the D-to-A on the sound card. A hard realtime > scheduler would run that task at 44Khz no matter what. This would entail > developing code that when the machine instructions were analyzed, would run > in the time constraints(aka the 44Khz). RTLinux appears to be suitable and > RTAI might be. Perhaps others. The relevant definition of "hard realtime system" here is "a system that always responds in bounded time." That bounded time may be one microsecond or one hour, but as long as the system can meet it's deadline every time, it's a hard realtime system. The definition doesn't really imply any specific time frames. Now, in real life, the "every time" part will never be quite accurate. After all, you may see some "once in a billion" combination of hardware events that delays your IRQ a few microseconds too many, or your lose power, or the hardware breaks down, or a software bug strikes... There are countless things that can go wrong in any non-trivial system. Of course, there's a big difference between a DAW that drops out a few times a day, and one that runs rock solid for weeks - but a truly glitch-free system would probably be ridiculously expensive, if it's even possible to build. Triple redundancy hardware, code verified by NASA, various other things I've never even thought of; that sort of stuff... As to the 44 kHz "cycle rate" on the software level, although possible, is big waste of CPU power on any general purpose CPU, as the IRQ and context switching overhead will be quite substantial. Further, even the (normally irrelevant) worst case scheduling jitter starts making a significant impact on the maximum safe "DSP" CPU load. (Double the cycle rate, and the constant jitter makes twice the impact.) Therefore, most low latency audio applications (whether on PCs/workstations or dedicated hardware) process a bunch of samples at a time, usually somewhere around one millisecond's worth of audio. This allows you to use nearly all available CPU power for actual DSP work, and you don't even need to use an "extreme" RTOS like RTAI/LXRT or RT-Linux to make it "reasonably reliable". With a properly configured "lowlatency" Linux system on decent hardware (as in, no BIOS super-NMIs blocking IRQs and stuf; raw performance is less of an issue), you can probably have a few days without a glitch, with a latency of a few milliseconds. I haven't kept up with the latest developments, but I remember stress-testing the first generation lowlatency kernels by Ingo Molnar, at 3 ms latency with 80% "DSP" CPU load. Hours of X11 stress, disk I/O stress, CPU stress and combined stress, without a single drop-out. This was back in the Pentium II days, and IIRC, the fastest CPU I tested on was a 333 MHz Celeron. Not saying this will work with any lowlatency kernel on any hardware, but it's definitely possible without a "real" RT kernel. -- //David Olofson - Developer, Artist, Open Source Advocate .--- Games, examples, libraries, scripting, sound, music, graphics ---. | http://olofson.net http://kobodeluxe.com http://audiality.org | | http://eel.olofson.net http://zeespace.net http://reologica.se | '-' ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] hard realtime performance synth
Hey! Bristol synths are very good, but I have problems with them. They do run on my system, but I am not able to use most of them reliably, since if you play fast or play a long succession of notes, the synth simply uses up too many resources and eventually gets kicked out of jack. So my dream to use all those synths in a real-time performance are still only dreams. I have been in close contact with the developer and as far as I understood he does not have such an issue on his machine. He will soon release a new version and we'll see how it goes, but at the moment Bristol synths seem to be using too much resources to be used for live performance and my machine is nowhere near being old, with a DUO P8600 CPU and 4Gb of RAM it should fly. Louigi Verona. On Wed, Jan 27, 2010 at 4:15 AM, David McClanahan < david.mcclana...@gmail.com> wrote: > Hi, > > Thanks for the response. Some thoughts > > > 1. Bristol synth was one the first synths I tried. I had installed > Ubuntu(Karma I think. BTW: Ubuntu is based off Debian and that packaging > system didn't seem to save me from breaking things) and then used various > "apt" commands suggested on the Ubuntu Studio site to install sections I > wanted(including the "realtime" kernel). When I ran Bristol(or ZynAddSub for > that matter) it would lockup and not even display the keyboard interface. I > eventually discovered that networking(the loop device interface) was not > hooked in. I got a little further in that graphic interface came up and I > got a plink or 2 before lockup. I'll take a look at the suggestions given > however. > > 2. As for some of other suggestions, I don't care what interface(X11,curses > etc) is available on the sound host(the dell in this case). As long as I > could control it and get some usable status output that'd be ok. (I'll check > into linux sampler). I could see it functioning perfectly well via some > midi/serial connection which I think ALSA has. > > 3. I'm a little worried about what some are calling realtime systems. The > realtime system that is part of Ubuntu Studio and others may be more > preemptible than the normal kernel(as in kernel calls themselves can be > preempted), but that's not a hard realtime system. A hard realtime > system(simplistic I know) might entail a task whose sole job is to pump out > a sinusoidal sound sample to the D-to-A on the sound card. A hard realtime > scheduler would run that task at 44Khz no matter what. This would entail > developing code that when the machine instructions were analyzed, would run > in the time constraints(aka the 44Khz). RTLinux appears to be suitable and > RTAI might be. Perhaps others. > > The way things are now even with the "realtime kernel" on U. Studio. , > xruns can occur because there's no hard limit on accessing resources-only > priorities. This may work fine on newer/faster machines but not on the older > ones. Some may say, "Go buy a faster machine". My answer is that won't > necessarily solve the problem which is a proliferation of "systems" on top > of systems without any assurance they'll all work together on time. I could > go buy a new systems but I have the feeling I'd be still "tuning" to get > things running. Roland, Korg, Yamaha put out turnkey products on what I > suspect is simpler hardware and my question is there any reason why similar > turnkey systems could not be developed on a Linux system(even on an older > machine). There may be some reason. I just don't think I've heard it yet. > > david > > > David > > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev > > ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] MusE 1.0.1
On January 26, 2010 08:33:48 am Robert Jonsson wrote: > Hi Alex, > > 2010/1/26 alex stone : > > Robert, as a note of interest here, is there a reason why Muse only > > has 32 midi ports available? Is it possible to increase this at user > > level? (I have 65 and counting) > > 65! Thats, thats... alot :) > > Actually the default was recently upped from 16 to 32, thinking that > we should cover most uses, apparently we were wrong :-) > It's a define so it is possible to change but a recompile is needed, > though I recall there were some issues last time... > I have forwarded to the devel list if Tim wants to chime in. This might be a problem. It's not just the define that sets the number of ports. The ports are used in certain places via an unsigned 32-bit int. Each bit corresponds to one port (used, not used etc.) So we were lucky to be able to increase from 16 to 32, but beyond that I will have to look at redesigning parts of the ports system. Maybe not as tough as it sounds, but not as easy as changing a define... I will have a look. Tim. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] hard realtime performance synth
Excerpts from fons's message of Tue Jan 26 21:47:31 +0100 2010: > On Tue, Jan 26, 2010 at 03:15:43PM -0500, David McClanahan wrote: > > > 3. I'm a little worried about what some are calling realtime systems. The > > realtime system that is part of Ubuntu Studio and others may be more > > preemptible than the normal kernel(as in kernel calls themselves can be > > preempted), but that's not a hard realtime system. A hard realtime > > system(simplistic I know) might entail a task whose sole job is to pump out > > a sinusoidal sound sample to the D-to-A on the sound card. A hard realtime > > scheduler would run that task at 44Khz no matter what. This would entail > > developing code that when the machine instructions were analyzed, would run > > in the time constraints(aka the 44Khz). RTLinux appears to be suitable and > > RTAI might be. Perhaps others. > > That's not how Linux audio works. Processing is done in > blocks of typically between 64 and 1024 samples. > > > The way things are now even with the "realtime kernel" on U. Studio. , xruns > > can occur because there's no hard limit on accessing resources-only > > priorities. This may work fine on newer/faster machines but not on the older > > ones. Some may say, "Go buy a faster machine". My answer is that won't > > necessarily solve the problem which is a proliferation of "systems" on top > > of systems without any assurance they'll all work together on time. > > With current kernels you don't even need any RT patches > to get good performance, unless you need very low latency > (i.e. very small block sizes). I've been working most of > the day on a 64-channel system with several quite complex > apps, and I haven't seen a single xrun. Standard unpatched > 2.6.32 kernel. > If you get xruns on a correectly set-up system (and that > requires very little these days) it's probably because > the apps you use have not been written in the way required > to perform well in a realtime context. Unfortunately there > are many like that. > > Ciao, > > -- > FA > > O tu, che porte, correndo si ? > E guerra e morte ! Well, I use the same distro and kernel and easily get xruns. It all depends on a couple of factors, among them hardware, software and settings. One reason why such hardware is not feasible for hard realtime is SMI. Currently there's nothing you can do about those other than hoping that they don't happen and that they don't block for too long. Well you can go up with your latency settings which will make it less likely that SMIs cause xruns. There are some slides from the last Linux Plumbers conference that explain what it basically is and talk about a possible future solution: linuxplumbersconf.org/2009/slides/Keith-Mannthey-SMI-plumers-2009.pdf Other typical laptop hardware also is one reason for xruns, mainly wireless, bluetooth or network in general, various acpi thingies, etc.. These fall in the settings category I guess, and I'm no expert on those (yet) since I'm pretty new to laptops. It certainly is possible to use laptops as reliable synths, Ken Restivo uses a netbook as synth for live performances for example, but I think SMIs alone will prevent hard realtime capabilities on any standard hardware. Regards, Philipp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] hard realtime performance synth
On Tue, Jan 26, 2010 at 3:15 PM, David McClanahan wrote: > in the time constraints(aka the 44Khz). RTLinux appears to be suitable and > RTAI might be. Perhaps others. Just a note, I know there will be lots of different answers to your post, but in the midst of all that could we have a small side discussion on precisely this topic? I have been using Xenomai recently for non-audio related research, and found it not too hard to use. (Other than the fact that I had to patch and compile the kernel myself.) However, this was with some custom PCI hardware for which I had driver source code which I translated to the RTDM model myself. (Which was quite easy actually. RTDM is not a bad driver model at all-- in some ways more consistent than the Linux driver model.) Does anyone have experience porting audio drivers to RTDM? Or... is it possible to use ALSA in conjunction with Xenomai somehow? I'm particularly interested for small embedded systems, but the old Dell laptop in question is also I think a valid scenario. thanks, Steve ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] hard realtime performance synth
On Tue, Jan 26, 2010 at 03:15:43PM -0500, David McClanahan wrote: > 3. I'm a little worried about what some are calling realtime systems. The > realtime system that is part of Ubuntu Studio and others may be more > preemptible than the normal kernel(as in kernel calls themselves can be > preempted), but that's not a hard realtime system. A hard realtime > system(simplistic I know) might entail a task whose sole job is to pump out > a sinusoidal sound sample to the D-to-A on the sound card. A hard realtime > scheduler would run that task at 44Khz no matter what. This would entail > developing code that when the machine instructions were analyzed, would run > in the time constraints(aka the 44Khz). RTLinux appears to be suitable and > RTAI might be. Perhaps others. That's not how Linux audio works. Processing is done in blocks of typically between 64 and 1024 samples. > The way things are now even with the "realtime kernel" on U. Studio. , xruns > can occur because there's no hard limit on accessing resources-only > priorities. This may work fine on newer/faster machines but not on the older > ones. Some may say, "Go buy a faster machine". My answer is that won't > necessarily solve the problem which is a proliferation of "systems" on top > of systems without any assurance they'll all work together on time. With current kernels you don't even need any RT patches to get good performance, unless you need very low latency (i.e. very small block sizes). I've been working most of the day on a 64-channel system with several quite complex apps, and I haven't seen a single xrun. Standard unpatched 2.6.32 kernel. If you get xruns on a correectly set-up system (and that requires very little these days) it's probably because the apps you use have not been written in the way required to perform well in a realtime context. Unfortunately there are many like that. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte ! ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] hard realtime performance synth
On Tue, Jan 26, 2010 at 2:15 PM, David McClanahan wrote: > things running. Roland, Korg, Yamaha put out turnkey products on what I > suspect is simpler hardware and my question is there any reason why similar > turnkey systems could not be developed on a Linux system(even on an older > machine). There may be some reason. I just don't think I've heard it yet. this isn't meant to be a snarky response, but I think the answer to your question as to why such a system hasn't been developed yet is money. -- Josh Lawrence http://www.hardbop200.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] hard realtime performance synth
Hi, Thanks for the response. Some thoughts 1. Bristol synth was one the first synths I tried. I had installed Ubuntu(Karma I think. BTW: Ubuntu is based off Debian and that packaging system didn't seem to save me from breaking things) and then used various "apt" commands suggested on the Ubuntu Studio site to install sections I wanted(including the "realtime" kernel). When I ran Bristol(or ZynAddSub for that matter) it would lockup and not even display the keyboard interface. I eventually discovered that networking(the loop device interface) was not hooked in. I got a little further in that graphic interface came up and I got a plink or 2 before lockup. I'll take a look at the suggestions given however. 2. As for some of other suggestions, I don't care what interface(X11,curses etc) is available on the sound host(the dell in this case). As long as I could control it and get some usable status output that'd be ok. (I'll check into linux sampler). I could see it functioning perfectly well via some midi/serial connection which I think ALSA has. 3. I'm a little worried about what some are calling realtime systems. The realtime system that is part of Ubuntu Studio and others may be more preemptible than the normal kernel(as in kernel calls themselves can be preempted), but that's not a hard realtime system. A hard realtime system(simplistic I know) might entail a task whose sole job is to pump out a sinusoidal sound sample to the D-to-A on the sound card. A hard realtime scheduler would run that task at 44Khz no matter what. This would entail developing code that when the machine instructions were analyzed, would run in the time constraints(aka the 44Khz). RTLinux appears to be suitable and RTAI might be. Perhaps others. The way things are now even with the "realtime kernel" on U. Studio. , xruns can occur because there's no hard limit on accessing resources-only priorities. This may work fine on newer/faster machines but not on the older ones. Some may say, "Go buy a faster machine". My answer is that won't necessarily solve the problem which is a proliferation of "systems" on top of systems without any assurance they'll all work together on time. I could go buy a new systems but I have the feeling I'd be still "tuning" to get things running. Roland, Korg, Yamaha put out turnkey products on what I suspect is simpler hardware and my question is there any reason why similar turnkey systems could not be developed on a Linux system(even on an older machine). There may be some reason. I just don't think I've heard it yet. david David ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Beta testers required for jretune - Update
Hi Fons, söndag januari 24 2010 22.02.37 skrev Jostein Chr. Andersen: > söndag januari 24 2010 18.48.14 skrev f...@kokkinizita.net: > > On Sun, Jan 24, 2010 at 05:49:52PM +0100, Jostein Chr. Andersen wrote: > > > First, a problem: my voice sounds like it is sent thru a chorus-like > > > processor when I listen. I routed my voice thru another jack connected > > > app just to check that I had done everything right, no chorus or > > > artifacts on that one. > > > > Could it be you're listening to a mix of the original > > and the processed version ? That would surely produce > > a chorus effect. > > Yes, it sounds definitive as a perfect dry/wet mix from the clean sound and > jretune's processed sound. Update: I tried the same on a recorded file and it works as it should - and it sounds really good and in fact very natural, the "gliding time" between notes seems to be perfect for me. I'm really impressed! Please, send more sources to if you want more testing. :-) I can't understand why I have problems when running jretune in realtime and have to investigate it. Please, pardon me for bugging you before I have done in depth testing of it, that will not be before the weekend. If I find out more of this, I will send you information off list. Thanks, Jostein ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] tschack ... early version of smp enabled jack1
On Mon, Jan 25, 2010 at 11:01:53PM +0100, hollunder wrote: > Excerpts from torbenh's message of Sun Jan 24 22:05:49 +0100 2010: > > > > hi... > > > > since i dont want to let jack1 codebase die in a feature freeze, > > i added some features. > > > > - smp aware > > - clickless connections > > > > these changes are too radical to be included in mainline jack1. > > so it gets a new name. > > its approaching beta status now. dunno... maybe someone is motivated to > > test it. > > > > http://hochstrom.endofinternet.org/trac/tschack/wiki > > Thanks Torben, clickless connections sound interesting, smp is pointless > on my current system. Nevertheless I'll package it for the Arch Linux > User Repository, as mentioned on IRC today. I won't have a lot of time > to test it in the near future, but it should make it a little bit easier > for others. > > I have a few questions tough: > 1) Is it a full replacement for jack1? I assume it is, but you never yup. its basically jack1 with a pretty big patch. > know.. > 2) Is there a chance that it will be merged back to jack1 someday? no chance at all. jack1 is in almost feature frozen. the only update it will see is the new latency API this is also such a big change, that most experience with the old codebase is not valid for this one. jack1 is supposed to be rock-solid, based on several years of experience with this mechanism. ripping the guts out, and turning it upside down, and afterwards "selling" it to users as the "rock solid jack1" isnt fair. this is a new implementation, and it needs to gain trust by itself. that said, it survives bad treatment by the oom guys without xruns. i basically consider it more robust than jack1, but since we only have 2-3 days experience with it, we cant be sure that its bug-free. > > Thanks, > Best regards, > Philipp > > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev -- torben Hohn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] MusE 1.0.1
On Tuesday 26 January 2010 14:51:35 alex stone wrote: > Robert, if you're considering upping this again, a colleague of mine > uses 126 ports, so something like 256 might be more suitable, and > cover just about everyone i should think. (we do orchestral music..) Is anyone else reminded of "640K ought to be enough for everybody" ? Why is there a limit beside the architectures int-size? Arnold signature.asc Description: This is a digitally signed message part. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] tschack ... early version of smp enabled jack1
--- On Tue, 1/26/10, Chris Cannam wrote: > From: Chris Cannam > Subject: Re: [LAD] tschack ... early version of smp enabled jack1 > To: "torbenh" > Cc: linux-audio-dev@lists.linuxaudio.org > Date: Tuesday, January 26, 2010, 7:38 AM > On Sun, Jan 24, 2010 at 9:05 PM, > torbenh > wrote: > > since i dont want to let jack1 codebase die in a > feature freeze, > > i added some features. > > > > - smp aware > > - clickless connections > > Is there any reason why a user would prefer this over > jack2? > and would I assume correctly that one of the reasons to not let the jack1 codebase "die" (or freeze) is that it is written in C as opposed to jack2 ? J. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] tschack ... early version of smp enabled jack1
i'll test this. working just fine as a drop-in replacement for stock jack1, i'll report back if i run across any issues. thanks :) -w On Sun, Jan 24, 2010 at 3:05 PM, torbenh wrote: > > hi... > > since i dont want to let jack1 codebase die in a feature freeze, > i added some features. > > - smp aware > - clickless connections > > these changes are too radical to be included in mainline jack1. > so it gets a new name. > its approaching beta status now. dunno... maybe someone is motivated to > test it. > > http://hochstrom.endofinternet.org/trac/tschack/wiki > > > > -- > torben Hohn > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev > ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] MusE 1.0.1
On Tue, Jan 26, 2010 at 1:33 PM, Robert Jonsson wrote: > Hi Alex, > > 2010/1/26 alex stone : >> Robert, as a note of interest here, is there a reason why Muse only >> has 32 midi ports available? Is it possible to increase this at user >> level? (I have 65 and counting) > > 65! Thats, thats... alot :) > > Actually the default was recently upped from 16 to 32, thinking that > we should cover most uses, apparently we were wrong :-) > It's a define so it is possible to change but a recompile is needed, > though I recall there were some issues last time... > I have forwarded to the devel list if Tim wants to chime in. > > /Robert > >> >> Alex. >> >> -- >> www.openoctave.org >> >> midi-subscr...@openoctave.org >> development-subscr...@openoctave.org >> > Robert, if you're considering upping this again, a colleague of mine uses 126 ports, so something like 256 might be more suitable, and cover just about everyone i should think. (we do orchestral music..) -- www.openoctave.org midi-subscr...@openoctave.org development-subscr...@openoctave.org ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] MusE 1.0.1
Hi Alex, 2010/1/26 alex stone : > Robert, as a note of interest here, is there a reason why Muse only > has 32 midi ports available? Is it possible to increase this at user > level? (I have 65 and counting) 65! Thats, thats... alot :) Actually the default was recently upped from 16 to 32, thinking that we should cover most uses, apparently we were wrong :-) It's a define so it is possible to change but a recompile is needed, though I recall there were some issues last time... I have forwarded to the devel list if Tim wants to chime in. /Robert > > Alex. > > -- > www.openoctave.org > > midi-subscr...@openoctave.org > development-subscr...@openoctave.org > ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] random curiosity
On Tue, 2010-01-26 at 14:23 +0100, Arnold Krille wrote: > I don't know but this sounds a bit stupid to me. You want the random numbers > to have differences. ... > And you can't really use scientific random number generators because you want > to be fast and have realtime with the synth ... I am surprised that nobody so far has suggested using the key and velocity as a "salt" to differentiate a single stream of randomness? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] random curiosity
Hi, On Tuesday 26 January 2010 13:33:52 Gabriel M. Beddingfield wrote: > On Tue, 26 Jan 2010, Arnold Krille wrote: > > I don't (yet) get the reason for doing this. If the global seed is > > initiated with time() it is the same as if each notes seed is initiated > > with time(), the > > *Is* each note being seeded with time()?? > > I got the impression that the seeds were being saved and > repeated. The reason why /that/ might make sense is if the > PRNG is being used for some kind of modulation effect -- and > then all the notes would have an identical "sound." I don't know but this sounds a bit stupid to me. You want the random numbers to have differences. Playing the same note again on a real piano or violin still produces different sounds each time. So I would expect a synth using random numbers for variety to behave the same and not give me exactly the same each time I hit that note. But regardless at how the seeds are initialized, when you use a special seed for each note, you are very much effected by correlation of the random numbers. When using the same seed for all notes, the access to the seed gets randomized as soon as you hit two notes together. Which reduces the effect of bad random numbers. And you can't really use scientific random number generators because you want to be fast and have realtime with the synth, so you are bound to have some strange effects from the random numbers. Arnold signature.asc Description: This is a digitally signed message part. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] MusE 1.0.1
Robert, as a note of interest here, is there a reason why Muse only has 32 midi ports available? Is it possible to increase this at user level? (I have 65 and counting) Alex. -- www.openoctave.org midi-subscr...@openoctave.org development-subscr...@openoctave.org ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] random curiosity
On Tuesday 26 January 2010 03:08:14 Arnold Krille wrote: > On Tuesday 26 January 2010 01:57:05 drew Roberts wrote: > > On Monday 25 January 2010 17:59:36 Gabriel M. Beddingfield wrote: > > > he return is > > > guaranteed be the most random number you could > > > imagine. > > > > I think you can get this by a simple call to rnd.i() > > > > Now, if you want to make your randomness complex rather than imaginary... > > I tell you guys, 21 is only half the answer... Wait! What was the question again? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] tschack ... early version of smp enabled jack1
On Sun, Jan 24, 2010 at 9:05 PM, torbenh wrote: > since i dont want to let jack1 codebase die in a feature freeze, > i added some features. > > - smp aware > - clickless connections Is there any reason why a user would prefer this over jack2? Chris ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] jack_capture V0.9.40
On Tue, Jan 26, 2010 at 1:19 PM, Kjetil S. Matheussen wrote: > > (I don't agree about the linux-audio-* mailing list > announcement policy, so from now on, program announcements > will only be posted to linux-audio-annou...@lists.linuxaudio.org !) > > > > Download from > = > http://archive.notam02.no/arkiv/src/?C=M;O=D > > > > jack_capture > > jack_capture is a program for recording soundfiles with jack. > > The default operation of the program is executed by writing "jack_capture" > in the terminal without any extra command line options: > > $ jack_capture > > ...which will record what you hear in your loudspeakers > into a stereo wav file. > > > > Most important new features since 0.9.36 > > * Direct support for mp3 using liblame. > * Console cleanup. Terminal should not be messy > when quitting jack_capture. > * Better buffering schemes. > * Less used memory. > > > > Features > > * Autogenerated filenames are unique and humanly readable. > > * The 4GB size barrier for wav files is handled by continuing > writing to new files when reaching 4GB. > > * Supports all soundfile formats supported by sndfile. > (wav, aiff, ogg, flac, wavex, au, etc.) (option: -f ) > > * Supports mp3 by using liblame. (option: -mp3) > > * Option for writing raw 16 bit data to stdout. (option: -ws) > > * Built-in console meter, plus option for automatically starting > and stopping the Meterbridge jack meter program. Port > connections to Meterbridge are done automatically, and > on the fly, by jack_capture. > > * jack_capture can connect to any input or output jack port. > > When "connecting" to a jack input port (i.e. a writable > port), jack_capture constantly monitors which jack ports > which are connected to the input port, and make sure > jack_capture is always connected to the same ports. > > In other words, jack_capture will reconnect its ports > automatically during recording to match the connections > of the ports. This is for instance convenient when > recording the playback ports since jack_capture can be > started first, and then other programs can start and > stop at any moment while all sound still should be recorded. > > * No limit on the number of jack ports jack_capture can connect to. > (I.e. the --port argument can be specified more than once, plus > that it accepts wildcard arguments. For instance, > > jack_capture --port "*" > > will connect to all current jack ports, both input and output > ports, except jack_capture's own ports.) > > * Buffers are automatically increased during runtime to prevent > underruns and to avoid wasting memory by preallocating too much. > (handled by using lockless atomic fifo/lifo queues to store > temporary sound data instead of ringbuffers) > > * The disk thread is automatically reniced to a higher priority when > using more than half of the buffer. > > * Significantly better recording performance than Ardour. > (probably because jack_capture writes all channels into > only one file and that it is not creating peak files). > (tested on athlonXP) > > * No problem writing at least 256 channels of 32 bit wav at once to a > local hard drive. (tested on icore7) > > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev > Kjetil, Installed and works on Gentoo 64bit. Recording works fine for a good standard. Tested recording WAV, Flac, and Ogg. Gui displayed correctly in fluxbox. Thank you. Alex. -- www.openoctave.org midi-subscr...@openoctave.org development-subscr...@openoctave.org ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] random curiosity
On Tue, 26 Jan 2010, Arnold Krille wrote: > I don't (yet) get the reason for doing this. If the global seed is initiated > with time() it is the same as if each notes seed is initiated with time(), the *Is* each note being seeded with time()?? I got the impression that the seeds were being saved and repeated. The reason why /that/ might make sense is if the PRNG is being used for some kind of modulation effect -- and then all the notes would have an identical "sound." -gabriel ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] jack_capture V0.9.40
Hi Kjetil Thanks for the new release, jack_capture-0.9.40 build and run/work well here on my debian/sid system. The $(DESTDIR) variable in the makefile makes it easy to build the deb packet. :-) regards hermann Am Dienstag, den 26.01.2010, 11:19 +0100 schrieb Kjetil S. Matheussen: > (I don't agree about the linux-audio-* mailing list > announcement policy, so from now on, program announcements > will only be posted to linux-audio-annou...@lists.linuxaudio.org !) > > > > Download from > = > http://archive.notam02.no/arkiv/src/?C=M;O=D > > > > jack_capture > > jack_capture is a program for recording soundfiles with jack. > > The default operation of the program is executed by writing "jack_capture" > in the terminal without any extra command line options: > > $ jack_capture > > ...which will record what you hear in your loudspeakers > into a stereo wav file. > > > > Most important new features since 0.9.36 > > * Direct support for mp3 using liblame. > * Console cleanup. Terminal should not be messy >when quitting jack_capture. > * Better buffering schemes. > * Less used memory. > > > > Features > > * Autogenerated filenames are unique and humanly readable. > > * The 4GB size barrier for wav files is handled by continuing >writing to new files when reaching 4GB. > > * Supports all soundfile formats supported by sndfile. >(wav, aiff, ogg, flac, wavex, au, etc.) (option: -f ) > > * Supports mp3 by using liblame.(option: -mp3) > > * Option for writing raw 16 bit data to stdout. (option: -ws) > > * Built-in console meter, plus option for automatically starting >and stopping the Meterbridge jack meter program. Port >connections to Meterbridge are done automatically, and >on the fly, by jack_capture. > > * jack_capture can connect to any input or output jack port. > >When "connecting" to a jack input port (i.e. a writable >port), jack_capture constantly monitors which jack ports >which are connected to the input port, and make sure >jack_capture is always connected to the same ports. > >In other words, jack_capture will reconnect its ports >automatically during recording to match the connections >of the ports. This is for instance convenient when >recording the playback ports since jack_capture can be >started first, and then other programs can start and >stop at any moment while all sound still should be recorded. > > * No limit on the number of jack ports jack_capture can connect to. >(I.e. the --port argument can be specified more than once, plus >that it accepts wildcard arguments. For instance, > > jack_capture --port "*" > >will connect to all current jack ports, both input and output >ports, except jack_capture's own ports.) > > * Buffers are automatically increased during runtime to prevent >underruns and to avoid wasting memory by preallocating too much. >(handled by using lockless atomic fifo/lifo queues to store >temporary sound data instead of ringbuffers) > > * The disk thread is automatically reniced to a higher priority when >using more than half of the buffer. > > * Significantly better recording performance than Ardour. >(probably because jack_capture writes all channels into >only one file and that it is not creating peak files). >(tested on athlonXP) > > * No problem writing at least 256 channels of 32 bit wav at once to a >local hard drive. (tested on icore7) > > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] [ANN] jack_capture V0.9.40
(I don't agree about the linux-audio-* mailing list announcement policy, so from now on, program announcements will only be posted to linux-audio-annou...@lists.linuxaudio.org !) Download from = http://archive.notam02.no/arkiv/src/?C=M;O=D jack_capture jack_capture is a program for recording soundfiles with jack. The default operation of the program is executed by writing "jack_capture" in the terminal without any extra command line options: $ jack_capture ...which will record what you hear in your loudspeakers into a stereo wav file. Most important new features since 0.9.36 * Direct support for mp3 using liblame. * Console cleanup. Terminal should not be messy when quitting jack_capture. * Better buffering schemes. * Less used memory. Features * Autogenerated filenames are unique and humanly readable. * The 4GB size barrier for wav files is handled by continuing writing to new files when reaching 4GB. * Supports all soundfile formats supported by sndfile. (wav, aiff, ogg, flac, wavex, au, etc.) (option: -f ) * Supports mp3 by using liblame.(option: -mp3) * Option for writing raw 16 bit data to stdout. (option: -ws) * Built-in console meter, plus option for automatically starting and stopping the Meterbridge jack meter program. Port connections to Meterbridge are done automatically, and on the fly, by jack_capture. * jack_capture can connect to any input or output jack port. When "connecting" to a jack input port (i.e. a writable port), jack_capture constantly monitors which jack ports which are connected to the input port, and make sure jack_capture is always connected to the same ports. In other words, jack_capture will reconnect its ports automatically during recording to match the connections of the ports. This is for instance convenient when recording the playback ports since jack_capture can be started first, and then other programs can start and stop at any moment while all sound still should be recorded. * No limit on the number of jack ports jack_capture can connect to. (I.e. the --port argument can be specified more than once, plus that it accepts wildcard arguments. For instance, jack_capture --port "*" will connect to all current jack ports, both input and output ports, except jack_capture's own ports.) * Buffers are automatically increased during runtime to prevent underruns and to avoid wasting memory by preallocating too much. (handled by using lockless atomic fifo/lifo queues to store temporary sound data instead of ringbuffers) * The disk thread is automatically reniced to a higher priority when using more than half of the buffer. * Significantly better recording performance than Ardour. (probably because jack_capture writes all channels into only one file and that it is not creating peak files). (tested on athlonXP) * No problem writing at least 256 channels of 32 bit wav at once to a local hard drive. (tested on icore7) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] random curiosity
Arnold Krille wrote: > [ ... ] > I don't (yet) get the reason for doing this. If the global seed is initiated > with time() it is the same as if each notes seed is initiated with time(), > the > numbers are still random beginning from that seed. The only problems I can > see > is when the random numbers are correlated resulting with per-note correlation > of for example always the a of the adsr being to short. A problem that is > easily solved when multiple notes get their numbers from the same seed > effectively randomizing the access to that seed and thus overcoming the > correlation... I can't come up with any better response than ... sounds feasible. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] random curiosity
On Tuesday 26 January 2010 00:01:50 Gabriel M. Beddingfield wrote: > On Tue, 26 Jan 2010, cal wrote: > >> That is to say, if you need a reproduceable string of "random" numbers > >> on each thread (e.g. for unit testing), then random_r() is your man. > >> Otherwise, it sounds like more trouble than it's worth. > > > > As I understand it, zyn wants a reproducible sequence for mainstream, > > plus a reproducible per note sequence seeded according to the current > > point in the mainstream sequence. Interrupting and resuming the > > mainstream sequence was the issue I was looking to simplify. If you step > > over srandom_r(), it's really not any great trouble. > > Kind of like where the random number generator is part of > the envelope, huh? That makes sense... in which case > random_r() would be a good use for that. I don't (yet) get the reason for doing this. If the global seed is initiated with time() it is the same as if each notes seed is initiated with time(), the numbers are still random beginning from that seed. The only problems I can see is when the random numbers are correlated resulting with per-note correlation of for example always the a of the adsr being to short. A problem that is easily solved when multiple notes get their numbers from the same seed effectively randomizing the access to that seed and thus overcoming the correlation... Arnold signature.asc Description: This is a digitally signed message part. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] random curiosity
On Tuesday 26 January 2010 01:57:05 drew Roberts wrote: > On Monday 25 January 2010 17:59:36 Gabriel M. Beddingfield wrote: > > he return is > > guaranteed be the most random number you could > > imagine. > > I think you can get this by a simple call to rnd.i() > > Now, if you want to make your randomness complex rather than imaginary... I tell you guys, 21 is only half the answer... signature.asc Description: This is a digitally signed message part. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
