if i start jack bye qjackctl from normal user i receive this errors:
JACK: unable to mlock() port buffers: Cannot allocate memory
cannot use real-time scheduling (FIFO at priority 10) [for thread
-1236161616, from thread -1236161616] (1: Operation not permitted)
cannot use real-time scheduling (FIFO at priority 20) [for thread
-1227768912, from thread -1227768912] (1: Operation not permitted
the jack server starts, but then it tell me messages like this "****
alsa_pcm: xrun of at least 8.570 msec"
no problem if i run qjackctl from root.
there's something to fix in my configuration?
thank you all.
bye
bobo
I am still new to a lot of this stuff, and I searched back a bit
through the archives (manually, as I don't know of a search
functionality) to see if there was any discussion about it.
First question, /proc/sys/vm/swappiness. Is there an advantage to
setting this to anything than the default for my distribution, which
is 60? I have heard that settings of either 100 or 0 are good for
different reasons, but strictly thinking in terms of using my system
for music production, what would you recommend?
Second question, elevator=cfq. I am thinking that CFQ is not good for
music purposes. Would that be correct? I've read it speeds up general
desktop usage, but this might work against realtime-preemption,
wouldn't it?
Third question, ReiserFS vs Ext3 vs XFS vs JFS etc. Is there a
filesystem that should or shouldn't be used with realtime-preemption?
Fourth question, CONFIG_DEBUG_DEADLOCKS. DeMuDi has it enabled, but it
gives a warning when you boot up that it could introduce higher
latencies. Is it safe to turn off?
I'm sorry if these have been asked before, but I didn't see anything.
If you want to just link me, that's fine, I checked on Google and got
conflicting results, and not a lot specific to music production.
Thanks in advance.
Dana
James Courtier-Dutton, who wrote the ALSA snd-ca0106 driver, got the
Audigy 2 ZS PCMCIA working on Linux, and has contributed lots of other
code to ALSA, recently lost all his Linux machines to a power surge. He
estimates this will set his work on ALSA back 3-6 months.
I think it would be great if anyone who finds his code useful would make
a PayPal donation to help replace the lost hardware, to
james(a)superbug.co.uk.
Thanks,
Lee
I could ask this question a number of places, but I like you
folks. :^)
I'm in the market for a ~400W/ch @ 8 Ohms amp to replace my aged,
and now broken for the 4th or 5th time, JBL power amp.
I've got some experience with QSC amps in band practice settings,
and in live performance settings. All I can say is that they
never seem to be problematic, and always seem to do their job.
I haven't used one in a studio setting. I'd almost just go buy
a QSC today, unless someone here would warn me off. I do need
an amp quickly as I was just about to mix some ardour recorded
music. What advice do you people have?
Thanks....
--
Kevin
Hello audio users,
I'm working on JACK Rack 2 and would like to know how many of you are
using more than two channels and how important you consider more than
two.
Thanks,
Leslie
--
gpg --keyserver pgp.mit.edu --recv-keys 0x52D70289
Loki Davison:
>
> On 2/6/06, leslie.polzer(a)gmx.net <leslie.polzer(a)gmx.net> wrote:
>>
>> Hello Loki,
>>
>> On Mon, Feb 06, 2006 at 10:11:58AM +1100, Loki Davison wrote:
>>
>>> As i said originally, om is big and powerful with it's standard gui.
>>> The engine however is very light weight
>>
>> Also in terms of dependencies?
>>
>>> if it were lighter than jack rack and more stable.
>>
>> Don't forget that we are talking about a complete rewrite of JACK Rack 1
>> (which is quite stable in its own right).
>>
>> Leslie
>>
>> --
>> gpg --keyserver pgp.mit.edu --recv-keys 0x52D70289
>> http://nic-nac-project.de/~skypher/
>>
>>
>
>> From the om site.
>
> The Om engine (which can be built by itself) requires:
> Liblo 0.22 and above
> Jack 0.99 and above.
> And can optionally use:
> Alsa sequencer
> DSSI
> LADSPA
>
> It would also be great for overworked Dave to get some help ;-)
>
Sorry, thats not the complete truth. It also requires:
Gtkmm 2.4 and above.
LibGlademm 2.4 and above.
FlowCanvas
...which is only available on newer linux distributions. I once tried to
compile up gtk 2.4, but I was unable because my glibc was too old. I only
have rh8, and I don't think thats very uncommon.
Om has to work with older versions of gtk to get more users. Until then,
I don't think this software has really come out of the beta-stage yet.
Hi all,
I've just installed Ubuntustudio. It all works great, except after a few
minutes I get lots of these message from jack:
"delay of 27893.000 usecs exceeds estimated spare time of 21274.000;
restart ..." (where the number of usecs are varying).
After lots of fiddling and googling I discovered that acpi is probably
causing it, and it consequently happens only when acpi is enabled. When
acpi is disabled I can push latency down to 2.67 msecs without xrunning
nomatter how hard I try....so this is good ;)
I've done these tweakings with Breezy, and it happens with all of them:
http://ubuntustudio.com/wiki/index.php/Breezy:Vanilla_Kernel_With_Realtime_…http://ubuntustudio.com/wiki/index.php/Breezy:Rlimits-Aware_PAMhttp://ubuntustudio.com/wiki/index.php/Breezy:Enabling_Preemption
It also happened the same way in out-of-the-box Dapper. I'm now on
Breezy with the vanilla kernel with preempt patch.
My laptop is a Dell Inspiron 8600:
http://www.koeniglich.de/dell_8600.html
I use Alsa intel8x0 driver, and had no other problems. Jack also worked
fine with acpi on other distros like PCLinuxOS, even with the non-mm kernel.
I have no idea what to do next, if anyone could give me a clue it'd be
appreciated.
--
Ringheims Auto - Fri musikk for bilstereo!
http://ringheimsauto.1go.dk/
In JACK, if the number of Maximum Ports is increased, does JACK use more system resources? If not, is there a down side to having a high number of ports?
Ruben
>This has been in my /etc/modules from the start. For a while now, (most
>recent?) 2.6 kernels, this will not load "device not found". Since it did not
>seem to effect anything, I just let it be. (Note I have both a rtc.ko and
>rtcgen.ko in my kernel's modules.)
>Finally, an app kicked! Playing with the latest Dynebolic 1.4.1 running in
>Qemu (1.1 ran very nicely without complaint), I got a non-fatal error message
>unable to set rtc to some parameter 1024. It suggested running in a 2.6 host
>kernel (2.6.15 at your service!) or echoing 1024 into a file on some /proc
>subdirectory (I have no such subdirectory in /proc).
More ...
I started /etc/module-ing rtc for use with lmsensors. The kernel config file
lists this as a "USB watchdog card". Maybe just because it is listed in this
group. Genrtc is a "generic" rtc driver for one who lacks this hardware
capability. As rtc used to work (or at least modprobe), I apparently have it.
Saw something interestic in my logchecks:
kernel: Generic RTD Driver v1.07
If I take this one off, the "real" one will modprobe :-)
Question is, who is loading genrtc BEFORE /etc/modules gets referenced?
Actually, I tried commenting it there and ... the error message remains so
something, somewhere is trying to load BOTH of them!
Anyone know anything about this?
It's occured to me that installing the kernel from Demudi stable on
Debian might be a nice easy way to get all my kernel tweaks without even
needing to recompile. And thanks to the way the kernel and the userland
in Linux are so relatively version independant of one another (something
not so true on other UNIX flavors), that should be quite safe, too.
It made me wonder though -- since Demudi is built from Debian, what
would be the issues with inporting lots of other packages useful to
musicians as well, while still keeping the system essentially Debian?
Do a lot ("a lot" meaning a destabilizing amount) of non-music-related
packages from Debian get superceded by Demudi versions when you add the
Demudi Apt repositories to the sources.list of a sarge machine? Are any
of you currently doing something like that? Just wondering... I'm sure
that even as there have been many MIDI and recording apps in sarge that
surely would not have gotten there without Demudi, there are probably
still others that either never made it or have newer versions in Demudi
than what sarge gives you.
I just don't want to make my system unmaintainable by mixing
distributions like that on a really massive scale though... Once you
get newer versions of really critical things, it can be almost like
committing yourself to running sid/unstable -- no easy way back.
--
+ Brent A. Busby, UNIX Systems Admin + "It's like being +
+ James Franck / Enrico Fermi Institute + blindsided by a +
+ The University of Chicago + flying dwarf..." +