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
I'm writing a library in ruby for dealing with audio data, and I'm faced
with a design decision.
For several reasons, the best thing to use in ruby for numerical data is
NArray[1] which is implemented in C for efficiency. So my code is
basically a wrapper around NArray which gives some more specific
functionality.
I want to support multichannel data, and this is where the design
decision comes. Most of the time I've seen code that handles
multichannel information in an interleaved fashion (each frame is
consecutive samples in the array), but I have once or twice seen
channels placed end-to-end or in different arrays altogether. It will of
course be possible to extract and/or merge channels to deal with
libraries (e.g. libsndfile, which I will also be wrapping) or existing
code that works one way or the other, but I wonder which should be the
internal format to use.
What are your thoughts? What is best practice on multichannel audio, or
is it always application-specific?
For a fluctuating peek (think CVS, although I use darcs) into what I'm
doing, check out http://hans.fugal.net/src/ruby-audio
1. http://www.ir.isas.ac.jp/~masa/ruby/index-e.html
--
Hans Fugal ; http://hans.fugal.net
There's nothing remarkable about it. All one has to do is hit the
right keys at the right time and the instrument plays itself.
-- Johann Sebastian Bach
Hi,
QjackCtl 0.2.19 has been released.
The Qt(cutie)-based GUI control panel for the JACK Audio Connection Kit
service has come of age. You can grab it right away from the "official"
home site:
http://qjackctl.sourceforge.net
Release notes as taken straight from the change-log:
- Connections widget views are now properly refreshed after renaming
client/ports (aliases).
- Disabled system tray and ALSA sequencer support on configure time,
whenever building for MacOSX as default.
- Fixed the major issues with selecting an audio interface on Mac OSX;
the button the right of the interface combo is now much better looking
than it was before; input/output channel counts are also updated
automatically now (thanks to Jesse Chappell for the patch).
- Prevent the setting of the coreaudio device id on the jackd command
line (-n) whenever the default interface is being selected.
- The connections and patchbay windows are now allowed to have a wider
connection lines frame panel; splitter width sizes are now persistent
across application sessions (thanks to Filipe Tomás for the hint).
- Activation toggling feedback on the patchbay widget has been fixed;
additionally and as found convenient, the most recently used patchbay
definitions can now be loaded immediately by selecting from a drop-down
list widget, which replaces the old static patchbay name status text,
and adds a lil'icon too :)
- All widget captions changed to include proper application title prefix.
- Attempt to bring those aging autoconf templates to date; sample SPEC
file for RPM build is now being included and generated at configure time.
- The current selected device is now shown with a checkmark on the
device selection menu(s), while on the settings dialog.
- Set to use QApplication::setMainWidget() instead of registering the
traditional lastWindowClosed() signal to quit() slot, just to let the
-geometry command line argument have some effect on X11.
Enjoy,
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
Hi!
I am working on a GUI designing tool for LADSPA/DSSI around Qt
designer. The idea is to extend the DSSI gui concept to LADSPA (OSC
control included) and provide a skinnable tool to manually design
GUIs. I plan also to include some user interaction enhancements.
You can see some fancy concept diagram here
http://flam.sourceforge.net/
There is some code behind it, too, but at the moment its structure is
fluctuating and no effort of autotoolization/sconification has been
done. There is a working skinnable slider and flamwizard is half
finished.
The skinnability will by provided by means of QStyle plugins. You can
have very minimalistic depictions of the UI gadgets or hardware panel
simulations.
The GUI viewer, called flammer, will allow for loading/saving presets
and load alternate GUI layouts for a given plugin at runtime.
Now I have a doubt about LADSPA_HINT_SAMPLE_RATE. To effectively
incorporate this hinting in the GUI, the host must have some means of
letting know the GUI what the current sample rate is. Is there any
standard procedure for achieving this?
Comments, ideas, please?
Cheers,
Luis