On 4/2/2010, "Emanuel Rumpf" <xbran(a)web.de> wrote: Run this script as your user (ie not as root) http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl

On Thu, 2010-02-04 at 20:30 +0100, Emanuel Rumpf wrote: Yes. I've been working for a while in a piece for real-time synthesis / sample playback and a piano controller (and pedals, etc, etc). I normally play with my laptop, a dual core lenovo t61 running the latest rt patched kernel and: linuxsampler at 96 voices max (4 different piano samples), two instances of the supercollider synthesis engine doing synthesis and spatialization, a program in supercollider controlling the whole thing (including the GUI feedback screen for the performer), jconvolver for convolution reverb and ambdec for ambisonics decoding. All with a PCMCIA RME card and a Multiface running at 128x2 48KHz. It can glitch but if it does it is because it has actually run out of cpu (and I have had a couple of instances in rehearsal where I'm playing textures so thick that the supercollider scheduling queue has filled up with not so good results, argh :-) All in all quite reliable (I played an earlier version of the piece in last year's LAC). -- Fernando

On Thu, Feb 4, 2010 at 2:46 PM, James Warden <warjamy(a)yahoo.com> wrote: I second the PianoTeq app recommendation... it sounds great and I have no problems with latency or xruns. I have almost the exact same sound setup and use it as a Jack client. It's not free, but worth the price. And doesn't need 30GB of disk space either. -- Brett ------------------------------------------------------------ "In the rhythm of music a secret is hidden; If I were to divulge it, it would overturn the world." -- Jelaleddin Rumi

On Thu, Feb 4, 2010 at 3:28 PM, Adrian Knoth <adi(a)drcomp.erfurt.thur.de> wrote: given that pianoteq is using physical modelling, its hard to see how their technology could be applied to hard synths, pads or atmo-fx.

On Thu, Feb 4, 2010 at 4:12 PM, Adrian Knoth <adi(a)drcomp.erfurt.thur.de> wrote: well, if you were willing to purchase gigasampler sample libraries, and spend a little time making sure your system configuration was all correct, i have little doubt that you could get LinuxSampler to do what you want. its notably lighter-weight for a sample-playback engine than most others that handle GS formats. however, given that gigasampler has died as a library format, and given that sound as if you don't believe your system configuration could possibly have any issues, i'm not sure that this solution will work for you. yep, precisely.

2010/2/4 Jens M Andreasen <jens.andreasen(a)comhem.se>se>: How to ? Where is the switch that would tell ladspa/dssi to use the GPU for processing ? That sounds marvelously. I found this information for DSP Accelerators http://www.thomann.de/gb/onlineexpert_127.html as well as this interresting device: http://www.uaudio.com/products/uad/uad2sl/index.html (I assume that it's not supported on linux) Those just work with special code-adjusted plugins. Does the VST API support them or even use them if present ? Do the RMI devices have plugin-accelerating DSPs ? Would it be worth to design an open-hardware DSP-add-on with an open API ? Since GPUs are very common already and have the fast PCIe connection using them may be more appropriate, I think. Running the rt-check script, indeed, I found some issues. Fixed them. Now, the only remaining warning is: Checking for Generic PCI bus-master DMA support... not found. ** Kernel without Generic PCI bus-master DMA support I retested with an undemanding 130 MB piano gig-file. Results: - Linuxsampler runs stable at 8ms. Great. - I'm able to play fast Sequences with PianoTecTrial at 16ms. I'm not allowed to use sustain or play quick chord progressions. They produce xruns and hard noise then. - yoshimi 054-pre4 behaves comparable to PianoTec at 16ms, but slightly worse. It produces occasional xruns even without chord-progressions. Likely conclusion: My system is not fast enough for this kind of processing, or somehow has a bad hareware-design. I will buy a new machine next year with 8 processors hopefully... Until then, the GPU seems the only miracle that could possibly help me out. Would it ? Thank you, replyers, for your replys and suggestions. -- E.R.

Emanuel! No DMA? That does seem bad! Direct Memory Access is VERY helpful and has been there for years - not to say decades. It's also supported by the Linux kernel since version 2.0.X something. If not enabled this can take up considereable amount of CPU time. So no wonder. Your system MUST be capabel of playing a nice piano (2-3GB) with LinuxSample with lower latencies. But how about your soundcard? Is it good, do you know, what they say about its own hardware latency? Always remember it's possible to play realtime on a 700mHz CPU, if you shut down the graphic. polyphony and sustain. Probably a few drop-outs there. But 700mHz are far from your new dual core! Kindest regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

On Sat, 2010-02-06 at 23:07 +0100, Emanuel Rumpf wrote: That article is so out of date, I dont know how to even begin to explain? Really, you might as well be talking about how M56k code does wonders on a NeXT cube. Do yourself a favour and ignore it. /jma

On Sat, 2010-02-06 at 21:36 +0100, Emanuel Rumpf wrote: I can only say what I have done and _very_ _carefully_ point out that I know _absolutely_ _nothing_ about RT-performance on any other system _whatsoever_! The box is a T3-P5945GC: http://www.asus.com/product.aspx?P_ID=BpN0BixlVJlpqtpu .. with an Intel 945GC chipset, AD1988b HDA audio and an E1200 (1.2 GHz "Conroe" style dual core Celeron.) The GPU is a pretty quiet, slightly overclocked Nvidia GT220 with DDR3 from Gigabyte. http://www.tomshardware.com/reviews/geforce-gt-220,2445.html (And apparently the GT240 model with GDDR5 is a lemon. Avoid!) Kernel is the 2.6.31.6-rt19, configured as per the Mandriva repositories (optimized for Core2 as the only change) That "switch" ideally would be somewhere here on LAD. The problem being mostly stirring up enough momentum to get something going. There might be this fear of jumping into the unknown? but hey look, here is one more programmer who has also had it with SSE and is not planning on upgrading to a 4 way $2K server any time soon: A realtime Mandelbrot zoomer in SSE assembly and CUDA http://users.softlab.ntua.gr/~ttsiod/mandelSSE.html In which one of those two codepaths would you like to spend your spare time? Which one looks the most civilized? Just wondering ... Reasonable expectations for RT performance is 1/3 of what Nvidia says is peak performance. So, 60 - 75 GFlops in the case at hand. Which translates to $1 per GFlop (including a healthy chunk of fast memory.) Hard to beat! The 0.3 msec turnaround time depends on that you are working from the console rather than the X-server. This might have been different if I had had dedicated cards, one for audio and one for video, but - unfortunately - I have only one PCIe slot, so there is nothing really that I can know or tell about that ... Working from within Gnome on a single card; 3 × 1.3 (+1.3) msec works and double that to become indestructibly rock-solid. [OK... That might be enough CUDA advocacy for tonight? :-D] /jma

2010/2/8 Joshua Boyd <jdboyd(a)jdboyd.net>et>: Actually OpenCL seems to already be supported, (in new hardware only ?), by the large graphic players: http://www.nvidia.com/object/cuda_opencl.html (there's a lot of docu here too !) http://developer.amd.com/gpu/atistreamsdk/pages/default.aspx http://www.khronos.org/opencl/ There's also the "CT Technology" from Intel (aquired from RapidMind), which is claimed to be easier to code and less hardware-dependant than OpenCL. http://software.intel.com/en-us/data-parallel/ http://software.intel.com/sites/products/collateral/hpc/ct/ct_newsletter110… A link to a short Intro. The code looks acceptable at a first glance: http://ati.amd.com/technology/streamcomputing/intro_opencl.html I still somehow wonder, how cheap low MHz Chips can outperform my GHz PC system. The answer seems to be parallelism of computations, which the GPUs (or DSPs) support better than CPUs. This also means, that faster CPUs won't necessarily bring the effect we are waiting for. (To play many software effects/instruments in an acceptable time.) Anyway. If the PCs can't do it, someone has to create a new system, or extend the PC anyway to make it capable. -- E.R.

2010/2/8 Paul Davis <paul(a)linuxaudiosystems.com>om>: Accepted. When running any 32 polyphonic hw synth, it is able to do those 32 voices anytime. When running out of the voices, something will happen (e.g. voice killing/stealing). But it won't start any noise. Something to concider Would a check for guaranteed voices be possible for a soft-synth ? That would require an extensive deterministic behavior, I think. Instead of noise generation, maybe some sort of interpolation/silence for sample values could be used, when running out of processing power. Kind regards - - E.R.

On Mon, Feb 08, 2010 at 10:01:03PM +0100, Emanuel Rumpf wrote: I am aware of Nvidia and ATI binary drivers supporting OpenCL. What I do not see is an ability to run this using the Nouvou, the RadeonHD xorg driver, the intel xorg driver, or as SSE optimized software only. If OpenCL DSP code would run on my desktop using CPUs only, faster than a reasonable C implementation using primitives would run, then I'd suggest it is ready for people to start using without holding out for open source driver support. I don't think that we are close enough to say that we will be there in 6-12 months yet though. If I am mistaken about the state of the Khronos reference implementation or the clang implementation, I'd love to see a demo prove me wrong. I am passingly aware of them, but as long as there is not an open language specification, and an open implementation, I don't think they are a real answer either. Just because I don't like it as well does not mean I won't accept it as a valid choice. However, the examples there still look a lot more complicated that the cuda examples. The page you posts included a fairly minimal OpenCL example that is close to 40 lines long without showing the actual source code for the actual OpenCL function to execute on the card. _global__ void inc_gpu(int *a, int N) { int idx = blockIdx.x * blockDim.x + threadIdx.x; if (idx < N) a[idx] = a[idx] + 1; } } int main() { float *a; dim3 dimBlock (blocksize); dim3 dimGrid( ceil( N / (float)blocksize) ); cudaMalloc((void **) &a, N); cudaMemcpy(a, someLocalSource, N*sizeof(float), cudaMemcpyHostToDevice); inc_gpu<<<dimGrid, dimBlock>>>(a, N); cudaFree(a); } The __global__ says that it will be called from the host but run on the device. Calling the function uses a modified call syntax to setup the arrangement of hardware resources that will be used by the call, but the number of units to use, and the block size to carve the data by. dim3 is a cuda defined datatype. Still, if OpenCL shows up in Mesa, and can at a minimum run on the CPU faster than a basic C implementation, then I would certainly choose it over Cuda for open-ness. Well, I bet a lot of software isn't wringing as much performance for your PC as it could. When it comes to music though, exactly what low mhz chips are beating a 2ghz Core 2 Duo or equivelent AMD? Also, how does the cost of said low mhz device compare to the Core 2 Duo? However, even in PCs, the trend is more cores, and either programmers need to get better, or else we need better tools. Now, I certainly plan to become a better programmer, but I still want better tools, and I think it is unfair to expect everyone to get better.

On Sat, Feb 06, 2010 at 09:36:20PM +0100, Emanuel Rumpf wrote: Glad you found it useful This checks for the 'CONFIG_BLK_DEV_IDEDMA_PCI' option, which seems to have been dropped somewhere between 2.6.29 and 2.6.31. I guess it was renamed or made non-optional, or something like that. I'll just remove this test from the script. Regards, Arnout