Hi,
Just to let you know about this small-fix release on QjackCtl, that only
affects the MIDI connections (re)nomenclature:
- ALSA sequencer client/port name aliases are functional again; all
actual MIDI sequencer client/port numerical identifier prefixes are also
back in business.
Apparentely, this has been missed for quite a while, almost since
0.2.16. Only noticed this late week, thanks to Domenico Culturato.
You can pick it out from the usual place:
http://qjackctl.sourceforge.net
Enjoy,
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
Regret to report I am having problems loading firmware for my multiface
again. This time I have the pci card in a 32-bit system running FC4 with
a recent 2.6.12 kernel and alsa from 1.0.10rc1, including
alsa-tools-1.0.10rc1. The error is:
Hammerfall-DSP: wait for FIFO status <= 0 failed after 30 iterations
Hwdep ioctl error on card hw:1 : Input/output error.
--
Janina Sajka Phone: +1.202.494.7040
Partner, Capital Accessibility LLC http://www.CapitalAccessibility.Com
Chair, Accessibility Workgroup Free Standards Group (FSG)
janina(a)freestandards.org http://a11y.org
If Linux can't solve your computing problem, you need a different problem.
Hey,
I just noticed that the sys_get_priority_max and _min syscalls do not
take the RT priority rlimit into account. Since the watchdog thread
runs at the -P setting + 10 then if the rlimit is 50 and the user
specifies -P50 the watchdog thread will fail.
I believe sched_get_priority_max(SCHED_FIFO) needs to take the rlimit
into account - there's no other way to get the upper limit AFAICT.
Lee
Hello list,
well i try to understand the reason of xruns. when will they appear?
for me it's curious, that , while copy a big file (> 50MB ) or many small one,
there are xruns. so, it seems, that it has nothing to do with the soundcard
buffers.
any comments?
sizu c~
Hi,
in the course of LASH'ifying jack_convolve i stumbled across the
LASH_Terminal client flag which specifies to LASH that the client wants
to be run in its own terminal when the session is restored.
The code for this is in
liblash/loader.c:121
The problem i see is: when the client in the term exits (either by means
of LASH telling it to, or by sending i.e. a SIGINT), it just drops to a
bash prompt instead of exiting the terminal.
For reference i have included the code in question below. I also wonder
why it is necessary to start another bash anyways? I tried to remove the
extra bash call and use xterm -e command_buffer directly, but then the
program doesn't even start correctly.
Any other thought on this?
static void
loader_exec_program_in_xterm(int argc, char **argv)
{
size_t command_size;
char *command_buffer;
char *xterm_argv[6];
command_size = get_command_size(argc, argv);
command_buffer = lash_malloc(command_size);
create_command(command_buffer, argc, argv);
xterm_argv[0] = "xterm";
xterm_argv[1] = "-e";
xterm_argv[2] = "bash";
xterm_argv[3] = "-c";
xterm_argv[4] = command_buffer;
xterm_argv[5] = NULL;
/* execute it */
execvp("xterm", xterm_argv);
...
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
Hi everyone
I've recently moved a system over to Slackware 10.2 which utilises NPTL and
I'm aware of the issues NPTL has raised in the past. Based on a comment on
the Jack website though I sort of assumed that things were now in hand and
that Jack had a workaround in place for the issue.
Despite this I have found that jackd itself (when run using set_rtlimits)
gives an error (-11, EAGAIN) when "creating realtime thread". I have
already confirmed that set_rtlimits does operate correctly in the NPTL
environment; it appears that for some reason pthread_create flatly refuses
to create the RT thread even though the appropriate priority limits are set
for the process.
The LD_ASSUME_KERNEL hack does make jackd work; however, it would be nice
to know what's going on (or whether in fact the problems are still being
worked on). Are there any ideas?
Interestingly enough, jack applications (ardour for example) do NOT need
the LD_ASSUME_KERNEL hack - they start and operate fine without out. Only
jack itself appears to have issues.
Glibc is 2.3.5, getconf reports "NPTL 2.3.5" and kernel is 2.6.14 plus
2.6.14-rt13. 2.6.14-rc3-rt4 has the same issues. Oddly enough, it appears
that under 2.6.13 things work fine even for jackd, but I need to confirm
that tonight. Jack command line (from memory):
jackd -R -d alsa -d hw:0 -n 4 -p 512
Jackd compiled against 2.6.14 headers with gcc 3.3.6. Kernel compiled with
3.3.6 also.
Regards
jonathan
Linked from this article:
http://linux.slashdot.org/article.pl?sid=05/11/20/2255217
I found this paper from MontaVista. In addition to being a good high
level overview of how modern Linux kernels achieve low latency they give
special credit to the Linux audio developer community and Paul Davis's
open letter to the kernel developers for driving the evolution of Linux
2.6 into a viable soft RT platform.
http://linuxdevices.com/articles/AT9697872711.html
Lee
hello.
I've been trying to get SMDITools working between linux and an E-Mu
ESI4000. My sampler is being detected although on the wrong ID (the
sampler is set to 4 and it's being detected at 0 ). Whenver I try to
receive from or send to the sampler, I'm getting this:
*** Error : Out of range ***
as the README suggests, i made a symbolic link to /dev/sga from
/dev/scsi/host0/bus0/target4/lun4/generic (i've also got sg0 - sg8 in
/dev ... could it be looking at those first? ) the only scsi devices i
have on the system is the esi4000 and an iomega zip drive between the
computer and sampler. iomega drive is set to id 5 (scsi interface is at 7).
also, does anybody know of any linux programs that work with the esi4000
file system? it would be great to be able to generate programs/banks.
thanks.
-d
