hi everyone!
lately there are a number of gmail users filling up the moderation
queues with "message has a suspicious header" bounces.
this is almost always due to people trying to send non-text/plain
content, which for a number of very good reasons is banned on linux-audio-*.
it seems that gmail has an unfortunate default setting that some people
are not aware of... gmail users, please fix your settings!
best,
jörn
Hi Lee
> 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.
I'm not sure what the "set_rtlimit problem" is here - I'm a little confused.
In terms of what set_rtlimits does, it seems to me that the watchdog thread
issue can be easily dealt with: define the max rtpriority value in
/etc/set_rtlimits to be X, knowing that the maximum jackd "-P" option value
one can use is X-10.
Certainly getrlimit()/setrlimit() (which set_rtlimit uses to do its thing)
seem to take the current rtpriority rlimit into account. The former
also returns the rlimit hard limit for the process, which I interpret
to be the "upper limit" mentioned in the original email.
In testing I've done during development, set_rtlimits seems to do the right
thing, based on my understanding of what the right thing is. If I've
misunderstood something though I'm happy to be corrected.
Regards
jonathan
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