On Tuesday 27 January 2009, James Stone wrote: [...] Depends on what you want to do... As long as the latency is *constant* (as in, no granularity for MIDI events), a few ms more or less is no big deal. Use headphones instead of near field monitors, and you cut some 3 ms right there...! If you're trying to route the monitor sound for a vocalist through the computer, latency might be more critical. It feels pretty weird if the monitor sound is significantly delayed, but I'm not sure exactly how much one can tolerate. //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --'

On tir, 2009-01-27 at 14:46 +0100, Raffaele Morelli wrote: I'll bet you cant even sense latency round 5,3ms when you play or sing along ...... /Sv-e

On tir, 2009-01-27 at 15:03 +0100, Cassiel wrote: Being supercilious dosn't document any facts ! What I read here is that 5.3ms is useless, then most computerbased setups will fail your demands then. /Sv-e

On tir, 2009-01-27 at 15:49 +0100, Cassiel wrote: You don't have to, I own a RME Multiface wich I can squize down to 0.67 ms working in 96000Hz /Sv-e

On tir, 2009-01-27 at 16:16 +0100, Jörn Nettingsmeier wrote: Your right, sorry. /Sv-e

interesting -- i also work with a Multiface, and find that Jack will not start at anything less than 64 frames/period and 2 frames/buffer, which is 1.33ms latency at 96kHz. i didn't think 32 frames/period was possible with that hardware -- what's your jack command-line? thanks... cheers! -- .pltk.

ah. thanks for clarifying. that works here, too -- but i'm not sure why i'd want to! ;-) cheers! -- .pltk.

Svend-Erik Kjær Madsen wrote: to put things in perspective: the speed of sound in air is around 340m/s. that means that in one millisecond, the sound travels about 34 cm. anything under a few ms total systems latency will not be noticeable in a normal listening environment, because you don't stick your head into the speakers. a drummer hitting a crash cymbal will have 3ms latency before the sound reaches his/her ears. a normal, 2m wide stereo triangle will introduce at least 6 ms latency. most jazz players i know are perfectly comfortable playing live on stage while being a few meters apart (true, bass and drums prefer to sit next to each other, but that will still mean 6-12 ms one-way latency).

Lee Revell wrote: true. recombining signals is a totally different beast, and *waay* more sensitive. iirc, the delay should be kept well below 3ms to avoid severe comb filtering (and any amount of delay will do weird things to your top octave and phase response...)...

On Tue, Jan 27, 2009 at 06:16:33PM +0100, Peder Hedlund wrote: My requirements are very specific: I play live with other musicians, via MIDI, and it's funk music, and I play bass through my Linux laptop. Therefore, I have to be locked in with the drummers. When I hit the 1, it has to be right on top of the kick drum. I also use a lot of softsynths, and I'm playing live, so Xruns are unacceptable. Consistently LOW latency with no Xruns and CPU-intensive softsynths are very important to me. That said, my current setup is a 2.33Ghz Core 2 Duo with a RT kernel and JACK set to -r 44100 -P 128 -n 3, using a USB soundcard and USB MIDI keyboard. I haven't calculated out what latency that is in milliseconds, but whatever it is, so far it works fine for me. It feels like I'm playing an actual instrument, not a sluggish computer. -ken

On Fri, 30 Jan 2009 03:05:11 +0100 torbenh(a)gmx.de wrote: depends, depends.. load? applications? If you see xruns might also depend on your jack line as there seems to be a bug that causes some xruns not to appear when -t is omitted. ... Best, Philipp

On Tue, 27 Jan 2009 14:29:40 +0000 James Stone <jamesmstone(a)gmail.com> wrote: I do very little microphone recording, but when I do, I send a feed direct to the headphone amplifer, as well as to the soundcard. To make the actual recording I use timemachine which, via jack, is the only thing connected to the soundcard inputs. The outputs from the soundcard also go to the headphone amp, so I record while playing back all the synth stuff (and any previous recordings). Finally I use audacity to line up the vocal with everything else. In actual fact latency is set to 5.8mS on my machine but I doubt I'd notice anything if it was higher. -- Will J Godfrey http://www.musically.me.uk

On Wed, 28 Jan 2009 20:11:36 +0100 Atte André Jensen <atte.jensen(a)gmail.com> wrote: Well, I've had a look at ardour and it goes right over my head (at around 40,000 feet). I really don't have the time and patience to start all over again. I think a great deal of one's ENJOYMENT in one's productivity comes from familiarity, and I've only incrementally added to my working style since my first MIDI setup in 1991. I think, so far I've made a grand total of four vocal recordings, and the method I used is relatively fast. Especially so when you consider I have literally taken years to develop some tunes. Also, for instrumental work I usually record in one straight hit, controlling everything from Rosegarden. The tune 'Lair Of The Dragon King' which I put up on here some time ago uses this method and Rosegarden is in charge of all of the following in one session. ZynAddSubFX Qsynth Hydrodgen jamin (two instances) External MIDI Sound Canvas Yamaha SY35 All connections eventually going to timemachine -- Will J Godfrey http://www.musically.me.uk

On Tue, 2009-01-27 at 14:06 +0100, Peder Hedlund wrote: It depends on your usage (this question seems to come up every couple of months lately). The current kernels are much better in low latency applications than three years ago. They are usable if you don't require "low" latencies (64 or 128 x 2). What you get also strongly depends on the hardware mix you have. If you want to use 64 or 128 frame periods (or less) you probably will need at rt patched kernel in most cases. Then again if an occasional xrun is not a problem then you would be fine with the stock kernel. While going down to, say, 1 or 2 mSecs of latency might be thought of as unnecessarily low, if your system can work at those levels then you are going to be more likely to never get an xrun when running at 5 mSecs latency. And if you are performing in a concert situation you _don't_ want an xrun, not even one. Linux, even rt patched, does not have a hard realtime scheduler with deadline guarantees, etc. -- Fernando

On Fri, 2009-01-30 at 03:23 +0100, torbenh(a)gmx.de wrote: Hmmm, I'm not sure, the load on pci itself by a soundcard should be nothing really hard. What would the internal card use? Would not that be pci or pci express anyway? Well, that's very good news then! I think the last time I tried to use a non-preempt was 2.6.27.x (maybe, I would have to double check). Playing 24 channels in ardour would result in xruns, not very often but they would happen, this is with 128x2 on an RME hdsp card runing on a quad core intel system. I should try again with the latest available. -- Fernando

Hiho, On Thursday 29 January 2009 18:41:48 Fernando Lopez-Lezcano wrote: I have been getting some xruns with my setup. Using jack with these settings: /usr/bin/jackd -R -p128 -t200 -dalsa -dhw:0 -r44100 -p1024 -n3 Using the internal soundcard (intel HDA). Basically running SuperCollider to play a stereo soundfile (the main track for the dance piece), and do some beattrack and pitchtrack analysis on that. The rest was mostly creating control signals (but on scsynth) for a light installation, which was controlled from the serial port. The other big loads were: * scgraph (about 15% CPU), for visualisation of what was happening (or should happen) with the light installation. * capturing video at 640x480 from a Canopus connected through firewire, using the vloopback module and dv4l, and feeding it into motiontrackosc, which was then communicating with SC, through OSC. This whole chain was quite CPU intensive. * SwingOSC for some SuperCollider GUIs. realtime priorities were handled through limits.conf, and I am running on the Debian kernel 2.6.26-1-amd64 on a Intel Core2 Duo, T7500 2.20 GHz. (It's a Lenovo Thinkpad T61). The previous Debian kernel 2.6.24, did give me better results with JACK, but had problem with the serial chip driver (the FTDI), at certain baudrates. So yes, the few xruns were problematic, since my soundtrack was the only sound that was going on, and I would really like to know how I could make this whole setup a bit more robust. The video capturing and the visualisation are certainly less time critical, as I am only deriving control data from it, and/or using it to monitor. It is not projected out again. sincerely, Marije PS, I may put some video material of this thing online a bit later.

On Tuesday 10 March 2009 09:06:16 Cassiel wrote: Generic, Debian stock. I didn't have time yet to try out and patch and build a kernel myself. (It's been a while since I did that). sincerely, Marije

Hi again, debian stock kernels are not rt. In order to work with lower latencies and boost audio performance you need to patch the generic kernel. A fix for midi should be in this rt patch http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.26.8-rt16.bz2(… I am not sure) and higher. Otherwise you can download the patch here http://offog.org/stuff/rt-200901/tasklets-fix-tasklet_hi_action.patch Actually I am on 2.6.29-rt-vanilla, debian way compiled, on testing/squeeze but I did it on lenny a couple of days after it was released. When compiling from vanilla sources you must prevent compiler warnings to stop building by checking "Kernel hacking" -> "Continue building despite compiler warnings" and then go with make-kpkg as usual on debian. regards r 2009/3/10 alex stone <compose59(a)gmail.com>

On Tuesday 10 March 2009 15:45:44 Cassiel wrote: Where did you get "Debian Way" sources for 2.6.29? The last kernel I made for rt patches that was workable was 2.6.23 which I got prepatched from musix. Kernels I built for 2.6.25 and 2.6.26 had problems with IDE DMA and were too dangerous to use (this was for a via chipset MB). I am running an unpatched (none available) 2.6.28 without problems but have done no audio on it. Things play OK.

I downloaded vanilla sources from kernel.org and "compiled" using the debian way. r 2009/3/10 David Baron <d_baron(a)012.net.il>