Hi, Ron, I'm in your way too: "no interest in any application that isn't a jack client". Nevertheless, I have problems with recording via ReZound as jack client: after few minutes xruns take place. Have you any experience here? My enviroment is: linux 2.4.26, lck1 patch, ReZound and JACK are from current CVS, working as root. Andrew ======= On Saturday 01 May 2004 0:03, R Parker wrote: ======= Hi Derek, ... I have almost no interest in any application that isn't a jack client. Jack simply is the way I want to work. ron ... __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover

Ron, I have tried ardour and qarecord for recording without xruns. I know there are some problems in ReZound from this point of view (and Davy knows about them much better :-). I have hoped, you know some magic steps to configure something somewhere to eliminate the issue at current ReZound state :-) Well, may be it is offtopic for this thread, but another question is here: which (and where is it) kernel patch is most appropriate for jack-functioning for 2.4.26 (I have applied lck1 patch)? Andrew ======= On Saturday 01 May 2004 0:56, R Parker wrote: ======= Andrew, I think recording with Rezound as a jack client will be a tough order because, as I understand the issue, its threads aren't realtime safe. If your hardware is duplexing and you can do hardware monitoring then push jackd frames up 1024, 2048 and finally 4096. Actually, push the frames up reguardless of what your hardware is capable of. It's pretty tough to say read the documents for tuning your system because we know Rezound is problematic in the realtime realm. IOW, it probably wouldn't mater if your system is tuned. What other apps have your tried? Ardour is relatively simple to install these days. With Ardour you need to be careful because development is fast paced and the bugs come and go very quickly. The key is to find a version that reliably performs the tasks you need and back that version up before you upgrade. You might have to downgrade. ron --- Andrew Gaydenko <a(a)etver.com> wrote: __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover

Malcolm, Thank you very much for the lecture, I'd want more and more :-) I'm happy to see, almost all of the mentioned (except for bdflush) settings are more or less optimum. Moreover, I have tried stereo-recording with ardour (during about 10 minutes) while building something from source. xruns amount was zero(!). Let me recall my question: I think, there are more than one (lck1) possible kernel patches with the aim of solving lowlat/preempt/... issues. Which of them is the most appropriate for using with jack? I still use 2.4.26. Andrew ======= On Saturday 01 May 2004 3:42, Malcolm Baldridge wrote: ======= I will assume you're using a SCSI system, and/or have your IDE tuned to use -d1 -u1 -c1 -m16 appropriately, and have 80-pin cables to do full UDMA/100 (or better) performance. 7,200+ RPM drives are also a Good Thing(tm). One thing people forget in tuning their system, is configuring their VMM system to not postpone dirty buffer flushes to disk. Actually, if you CAN try to avoid using swap at all, or use a dedicated swap device on its own IDE channel (or use SCSI). Do not underestimate the logjams of contended I/O devices. Also, you'll want to keep a reign on dirty buffer highwater marks. System defaults are not tuned for deterministic latency, i.e., writes are delayed until there's a lot of them. To produce more even and distributed writes, you might want to try: Assuming an HZ=1000 kernel... echo "10 64 0 0 2000 15000 90 5 0" > /proc/sys/vm/bdflush Assuming stock HZ=100 kernel: echo "10 64 0 0 200 1500 90 5 0" > /proc/sys/vm/bdflush This means: wakeup bdflush() at 10% dirty buffer levels, issue 64 block writes maximum per pass, wake up every 2 seconds, don't let dirty buffers age more than 15 seconds. bdflush() can go into "panic mode" to use synchronous operations when dirty buffers reach 90%, and bdflush can stop waking up when dirty buffer levels get to 5%. Defaults provide for a more deferred bdflush interval, and much larger I/O requests [500 blocks], which can flood the device's request queue and block other writes from occurring. If you're using lck1, are you also performing a "echo 1 > /proc/sys/kernel/lowlatency" ? Try 'nice -10'ing your problematic process. Also, avoid using ext3 in its default mode, ordered writeback. Instead, mount it using writeback journalling mode. Large pending journal updates tank latency as a sizeable operation needs to be performed atomically. The mount options for ext3 (if you must use it) would be: -o journal=writeback,noatime /etc/fstab entry would be like: /dev/hdc1 /barad-dur ext3 noatime,journal=writeback Note: this mode still journals all meta-data writes, but data CONTENT is now write-ordered, so you might not have the data you expect in a kernel OOPS/crash scenario, but your filesystem structures won't be damaged. noatime turns off the potentially disruptive ACCESS time updates (needless write pollution if you're reading many files during the course of your sessions). Modification time updates are still performed of course. When the Lady Galadriel comes calling, be sure of your Quality, =MB= -- A focus on Quality.

By the way, most of the rants you read about ext3 being "bad" for deterministic latency no longer apply when you use journal=writeback mode. I suspect Reiserfs and/or XFS to still remain superior for large files-I/Os, however, but journal=writeback should eliminate the periodic spikes in file append turn-around times. I suspect the data ordering of journal=ordered is probably of little use in DAW applications for the simple reason that if you crash, you would probably toss your session file that was interrupted anyway. Some file formats are corrupted anyway if they are not "finalised" with proper closure. .WAV is one such format [which needs RIFF headers to be written with correct sample counts, etc]. Ash nazg durbatulûk, ash nazg gimbatul, ash nazg thrakatulûk, agh Quality-ishi krimpatul, =MB= -- A focus on Quality.

R Parker <rtp405(a)yahoo.com> writes: Davy recently distributed a tarball to test some improvements to his realtime thread handling. It worked noticeably better for me, though still not perfectly. I believe he still plans more rework, and that this code branch is not yet in any official release. The place to ask is on `rezound-users(a)lists.sourceforge.net'#39;. Agreed. It's a beautiful program. I look forward to it having a really solid JACK interface. -- joq

Hi Emiliano, Saturday 01 May 2004 00.28 skrev Emiliano Grilli: ecasound is pretty much as stable as you can get. I use it quite oftenly to "rip" casettes (that we record during rehearsal) directly to ogg via jack. Works perfectly. ecasound -i:jack -o:outfile.ogg (this commandline requires however that you set up the routing in jack manually) /Robert

Hi, After installing from src, I noticed the messages "using path '/usr/local/src/rezound-0.9.0beta/share' for share data directory". I did 'chown' on that. Afterwards, Rezound failed to start the gui but that could be attributable to having existing processes--'killall rezound'. With no existing processes and the chown, it asked which alsa_pcm:playback port I wanted twice and then the gui started. According to the documenation, it should ask twice. When the gui fails, it only asks once. Maybe there's something to my madness. I don't know but I'm happy to see it running. ron --- derek holzer <derek(a)x-i.net> wrote: __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover