Hello,
I am wondering what I should do in order to get a bit more performance
out of my system for using JACK and friends.
I currently have two systems, and they are relatively similar. My main
system is a Dell Optiplex, can't remember the model exactly right now,
but it is:
Intel P4 2.8GHz
512MB DDR
onboard video
Creative Audigy2 ZS
The other system is:
AMD AthlonXP 2800+
512MB DDR
NVIDIA GeForce4 Ti4200 128MB
Creative SoundBlaster Live! 5.1
I was considering buying a 2x512MB DDR kit for the P4, and dropping
the old 512MB from there into the Athlon system.
The RAM I am thinking about is:
http://canadacomputers.com/index.php?do=ShowProduct&cmd=pd&pid=003982&cid=R…
Would it be better to save up and invest in a CPU/mobo upgrade? Or
will a different sound card give me a performance boost (not sure how
it would be possible, but..)? Or maybe I should find a PCI video card
(NVIDIA or maybe there is something better?) to put into the Dell, if
onboard video causes issues? Or is RAM a pretty good upgrade at this
point?
I ask because I am new at using software (other than Audacity) for
multitrack recording, and when I get more than a couple apps up and
running, my system gets sluggish, and I can't even load the Titanic
SoundFont in Qsynth because it crashes (I presume due to lack of
memory).
Thanks in advance for any advice.
Dana
I read this in the jackit-devel list archives:
http://sourceforge.net/mailarchive/forum.php?thread_id=9639236&forum_id=3040
I have an Athlon 64-X2 machine, which I'd intended to use at the
main machine in my studio. I also have a Celeron machine, which
is still in use, having started out as my proof-of-concept for
a Linux studio box. One person commented that with their 64-X2
machine, that a larger period size, 256 versus 128, seems better.
This is generally true for avoiding xruns.
I'm wondering, is an even larger period size 1K or 2K going
to make a 64-X2 machine usable. I primarily use ardour,
rosegarden4, and audacity for my audio work. What factors impact
the timing problem that I might exploit to minimize it? I'm
not too adverse to trying newer versions of a kernel and jack.
Right now I'm running kernel 2.6.12 jackit 0.100.1. I remember
something about there being a pervasive udev change starting in
the 2.6.15 kernel. I'd like to stay under that rev., if that's
true.
Related to this is that I'd like to retire my 200MHz Pentium
I machine in our office - 10 years old this month. Would you
recommend avoiding the 64-X2 machine for now with my audio work
(OK, so it's play)? If so, then I'll keep using the Celeron for
music, and move the 64-X2 into the office. We'll be able to
compose emails faster than anyone on the block; sigh. It sounds
like I really just need to be patient and let the kernel & jack
development teams sort this all out. But, if I can make some
adjustments and get useful results, then I'd move that direction.
Thanks....
P.S.: If you think I should subscribe to jackit-devel and take
my question there, then I'll do that.
--
Kevin
Hello list,
I'm working on a new piece and I need a some intro. I was thinking of
doing something funky with a softsynth and a glissando. Think along the
lines of the beginning of "Threshold" from the Steve Miller Band (or the
opening of Jungle Love, also from Steve). I can't figure out how to do a
glissando in Rosegarden, so does anyone of yous out there know that
trick or some other way of making some weirdo sounds? Cheers,
Hans
Download from http://ccrma.stanford.edu/~kjetil/src/
*****************************************************
E-radium
--------
E-radium is Radium and a special version of E-UAE (with support for
realtime scheduling and alsa midi). Radium is a unique type of music
event editor made to be efficient and give all sorts of possibilities.
The user interface is inspired by trackers, but Radium is generally a lot
more versatile and can be used for all kind of genres.
http://www.notam02.no/radium/
Warning: E-radium does not seem to work on 64bit machines. :-(
Changes 0.61d->0.61e
--------------------
-Run XInitThreads(). Should fix e-radium in case you got xlib async
errors. (Fix for SMP machines)
****************************************************
Das_Watchdog
------------
Das_Watchdog is a general watchdog for the linux operating system that
should be run in the background at all times to ensure a realtime process
won't hang the machine.
Changes 0.1.2->0.2.0
---------------------
* Don't do anything if no process priorities are changed, when
watchdogging.
* Added the --force option, that sets the priority of all timer processes
to FIFO/99.
* Added the das_watchdog /etc/init.d script provided by Stefan Kersten.
(das_watchdog.rc)
* Added the --verbose option.
* Check that its the same process when setting back old priority.
* Don't set back to old priority if the priority has been changed in the
mean time.
* Added options for setting increasetime, checktime and waittime.
(--increasetime, --checktime and --waittime)
* Don't change the priority of any timer process when watchdogging.
* Smaller code cleanups.
>Well, I'm about to crack open a can of worms, but let me just say that
>I'm 100% not interested in starting any debates/fights/riots/states-of-
>emergency.
Well - I won't tear your head off, anyway. :D
>But, and this what it's all about, when it comes to my personal reason
>for living --- music --- I'm forced to admit that on technical merits
>alone, I have a hard time arguing for Linux. . . . . .
> But if you really need the best tool for the job, then I
>don't see the justification for using the open source solution.
That all depends on what the tools are that your require, and what your particular needs happen to be.
> I really, really want
>to get an album out --- and I also want it to be really, really good.
So do we - that's why we are using Linux and Ardour.
>I want to use the best tools for the job, and in my evaluation, those are
>proprietary tools.
>OTOH, with a little work, I think the LMMS + Ardour can actually be the
>best, or at least good enough.
Ardour is already on track to be the best, and in our opinion - and for our purposes - it already is.
> But I don't think I'm going to see
>anybody who's primary interest is making music --- although I'd love to
>be proved wrong, and I certainly think that things will be different in
>the future as the tools get better.
Well, you said you'd love to be proved wrong - so - you *are* wrong!
We are not developers, nor geeks.
Learning to use Linux for audio production has, in fact, proven to be quite a challenge for us.
We decided to do so, because we found that none of the proprietary solutions - Steinberg, etc, met our needs.
We were not happy with the results of any of them.
(I think it goes without saying that we were not happy with the cost either.)
We are serious musicians, and totally committed to making music - the best music we possibly can.
We are working hard on our next album, and it is precisely because of the extremely high standards we have set for the production quality, that we have committed ourselves to using Ardour - the only program we have ever found that has lived up to those standards.
There are little bugs, but we always find a way to work around them, and the developers just keep making it better and better.
Ardour meets our needs because of its transparency, its support for high resolution recording, and its simplicity, coupled with its power.
We don't use midi, we don't use plugins, we don't need a lot of gadgets, bells or whistles.
We just record acoustic and acoustic-electric instruments - and now vocals - and need the highest fidelity recordings we can achieve to preserve the integrity of the sound that we have worked so hard to create - and do justice to the music.
Ardour has enabled us to achieve this in a way that no other proprietary program ever has.
If you use a lot of software instrumentation, midi features, plugins, etc. and need a lot of gadgetry - then perhaps proprietary programs can offer you more for that type of production - but quite frankly, we are musical purists, and find that a lot of that kind of thing gets away from a focus on the music itself.
But to each their own.
Simply put: making music *is* our highest priority, and *why* we are using Linux and Ardour.
>i can hack ardour part time while i work. i can hack ardour full time
>while i live the rest of my life. but i know for sure that i definitely
>can't get into philosophical debates with the recently deceased while i
>work full time on ardour and live the rest of my life.
:D :D
-Maluvia
Hi!
So I finaly managed to record my old tracks I had only on audio
casettes, as I had no PC to dump to and no memory cards for my
first keyboard, a Korg M1, back in 1996/97.
All M1 made music in one category:
http://www.archive.org/search.php?query=creator%3A%22Thorsten%20Wilms%22%20…
A subset, guitar rock emulation tracks (I guess all guitar players
will cringe, but I had a lot of fun and think one can hear it :)
http://www.archive.org/search.php?query=creator%3A%22Thorsten%20Wilms%22%20…
One addition to the GEM_S3 collection, as that one floppy disc
got corrupted:
http://www.archive.org/details/sequencer_vibes
If you're like checking only one track, I would like to recommend:
http://www.archive.org/details/flashlight
All where recorded using Timemachine, edited with Sweep, send
through Jamin by means of Muse (for setting loops while adjusting
parameters). Thanks and respect to all the developers. New
music will be made with a bit more Linux software ;)
It's all Attribution-ShareAlike, no Noncommercial like before,
as that one is a pudding and I guess I don't need such protection.
Only having to retag and upload again all the files keeps me from
changing the license of the other tracks.
After all this time, there are many things I would do differently
now, but I would still like all kinds of feedback, be it here,
in private mail, or in reviews on the archive. The later is your
chance to give more visibility to my stuff if you think more people
should check it out (perhaps target them, not me).
Or to warn others :>
Cheers,
Thorsten Wilms
Hi all,
I have loaded some MIDI files from the web which contain sysex data.
Instead of playing them through a sequencer I'd like to extract the
sysex data via a shell or even simple GUI program. Is there any that
can do this?
I have looked into the files with a hex editor, but it seems that the
sysex data isn't stored as plain sysex in the midi file, otherwise I'd
be able to write a small app myself to extract the data.
Any hints?
Best regards
ce
We have been considering investing in an RME Fireface, only to find that there are no ALSA drivers at this time.
Does anyone have any idea if this could change in the near future, or does it look like RME has just decided to lock out this technology for Linux users?
(My apologies if this has already been answered elsewhere.)
-Maluvia
>Yep! Openbox here, just puts a nice window title, you have a root menu
>and four work spaces. Nothing more, fast as hell!
>
>If you're trying to get the lowest latency posible it's dumb having a
>desktop system that eats half your resources.
>
>Cordially, Ismael
>
>Use fbpanel + rox
>--
>cheers,
>
>tim hall
We're currently happy Blackbox users: Xvesa+minimalist Blackbox+aterm.
No xrun problems so far, even at 192khz.
Openbox sounds interesting as well, and I've been meaning to test out the Kdrive framebuffer server as well.
Thanks for the tip.
-Maluvia
Hi!
I'm using the Soundblaster Extigy USB-Soundcard and would like to get JACK
working.
AFAIK ALSA is working. But if I start qjackctl and after that ardour or
rosegarden4, the output is *really* noisy. I've attached the qjackctl output
messages and I'm using Debian/unstable with a compiled 2.6.14.3 kernel. I'd
like to provide you some more information, but I have no idea what the
problem is, so I don't know, what to post.
Thanks in advance to everyone who can help me...
Jakob Rohrhirsch
qjackctl output:
18:31:12.067 Patchbay deactivated.
18:31:12.106 Statistics reset.
18:31:12.165 Startup script...
18:31:12.165 artsshell -q terminate
18:31:12.181 MIDI connection graph change.
18:31:13.066 Startup script terminated with exit status=256.
18:31:13.107 JACK is starting...
18:31:13.108 /usr/bin/jackd -R -dalsa -dhw:0 -r44100 -p1024 -n2 -P -S
18:31:13.132 JACK was started with PID=5848 (0x16d8).
jackd 0.100.0
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with System V SHM support.
loading driver ..
apparent rate = 44100
creating alsa driver ... hw:0|-|1024|2|44100|0|0|nomon|swmeter|-|16bit
control device hw:0
configuring for 44100Hz, period = 1024 frames, buffer = 2 periods
nperiods = 2 for playback
cannot use real-time scheduling (FIFO at priority 20) [for thread -1228801104,
from thread -1228801104] (1: Operation not permitted)
cannot use real-time scheduling (FIFO at priority 10) [for thread -1237189712,
from thread -1237189712] (1: Operation not permitted)
18:31:13.334 MIDI connection change.
**** alsa_pcm: xrun of at least 32.720 msecs
18:31:15.400 Server configuration saved to "/home/jakob/.jackdrc".
18:31:15.402 Statistics reset.
18:31:15.514 Client activated.
18:31:15.514 Audio connection change.
18:31:15.517 Audio connection graph change.
subgraph starting at qjackctl-5845 timed out (subgraph_wait_fd=10, status = 0,
state = Triggered)
**** alsa_pcm: xrun of at least 25.410 msecs
cannot use real-time scheduling (FIFO at priority 9) [for thread -1225634896,
from thread -1225634896] (1: Die Operation ist nicht erlaubt)
18:31:15.592 XRUN callback (1).
18:31:35.818 XRUN callback (2).
delay of 26106.000 usecs exceeds estimated spare time of 21284.000;
restart ...
**** alsa_pcm: xrun of at least 16.877 msecs
18:31:35.901 XRUN callback (1 skipped).